It's kind of funny, we bought these TVs because they were "smart" (when they first came out) but they were so clunky and unreliable we disconnected them and used either PS or Apple TV for other things. Now we wouldn't connect our TVs to the internet for anything, and only use PS5s for specific things. We mostly just use our Apple TV.

Made me feel like I was going a bit crazy TBQH. Surely I didn't misremember?

Annoyed because it was a convenient file storage solution and now they have proven themselves untrustworthy so I have to set up my own thing. My fault for trusting to begin with, I suppose.

1. The team making the design system needs to be really passionate about making a design system specifically

2. Everyone on the design system (DS) team needs to be pretty far in their careers, and have a few failed or quasi-successful attempts in their past experience.

3. Everyone's skills should overlap but each individual should bring their own depth/area of expertise.

4. I've never seen a "contributing back" model work, really. There can be some collaboration, or specific asks, but when you have a really cohesive DS team, they took the time to become that cohesive and it shows.

5. No matter how good the docs are, there will always be people who don't read the docs. I'm tempted to go as far as to say that I think there should be an onboarding course on how to use the design system that teams have to take before they can use it. (I legit don't know how else to reasonably solve this issue).

6. Make it compliant with accessibility requirements (at least bare minimum WCAG Success Criteria). I've seen that alone drive adoption for design systems.

I've been creating for web for 25+ years now, and I've only seen 1 or 2 successful design systems. It's so easy to get it completely wrong, or get off track.

Stale docs are worse than no docs. IME (at non-FAANG, non-tech darling companies) docs *always* go stale pretty quickly. No one wants to take on the thankless, unbudgeted task of keeping the docs up-to-date, or browbeating all the other devs to update the docs when they make changes.

The only docs I push for are stuff like swagger where the documentation is also living code. Otherwise I say just put it in the readme, and every repo has a clear owner responsible for keeping that readme up-to-date as necessary.

The OWD team writes technical documentation on APIs, HTML, and JS. OWD also works on information architecture and browser compatibility data. They contribute mainly to https://github.com/mdn/content/ and https://github.com/mdn/browser-compat-data/.

Mozilla, not OWD, is responsible for Yari, the platform behind MDN Web Docs (https://github.com/mdn/yari). The MDN blog, ads, AI and design, the MDN infrastructure, are fully owned and controlled by Mozilla.

I know some folks who work on this content and TBH it’s the folks we’d want working on this content.

- What's your mechanism for bias self-check?

- If someone gives you specs and you notice that something is off, what do you do?

- If you have to solve a problem you haven't solved before, how do you approach it?

- What's your take on accessibility on the web?

- What's your process like for deciding that you're at the point in your career where you can mentor others?

- What do you prefer to do when you see someone else getting nit-picked?

- You're just about to finish a feature and have a great idea for improving it. What do you do?

For all of these things, people will likely give different answers but those answers will tell me a lot about whether or not they would end up being really useful for the kinds of teams I build.

- What's your mechanism for bias self-check?

Debate. I like debating, I have to admit. It's a great way to sharpen one's logic. But, one has to careful to not get labeled as "argumentative".

- If someone gives you specs and you notice that something is off, what do you do?

I always have suggestions or questions on any non-trivial spec. I list them up and email them out to the project manager. I do try to be polite in my criticism, though. Example: "I'm concerned that X may confuse users. Here's an alternative to consider."

- If you have to solve a problem you haven't solved before, how do you approach it?

I try to ponder such longer than normal rather than go with the first approach that pops into my head. I may work on something else while the idea dances around in the back of my head. Sometimes I dream up solutions at night. It sounds cliche, but it's true.

- What's your take on accessibility on the web?

Managers and users often like fancy UI's that may run into accessibility problems. It's a tricky thing to balance. Eye-candy does "sell" a UI, and accessibility often hampers that. Sometimes I try to find ways to spruce up a UI that don't harm accessibility, such as improving logos or including interesting "side" graphics that don't interfere with the primary function.

- What's your process like for deciding that you're at the point in your career where you can mentor others?

If I feel I can help somebody without offending them, I will often just jump in and do task-specific mentoring. But I wouldn't want to do such full time.

- What do you prefer to do when you see someone else getting nit-picked?

I will defend them if their ideas or work have merit. If not, there's probably a reason they create team friction, and to be frank, they probably should change careers into something that's a better fit for them. Often times such people are not "bad", rather just in the wrong field.

- You're just about to finish a feature and have a great idea for improving it. What do you do?

I'll check with my supervisor. If I'm enthusiastic about the better variation, he or she will typically allow me to go with the better one once they know me. If time is tight, it may have to wait until the next version. I will work extra hours if I feel it's a compelling feature.

The purpose of the interview for the interviewer: deciding between "no, don't hire this person", "maybe, we'll decide later with more data or after comparing with another person", and "yes, hire".

The purpose of the interview for the interviewee: deciding "yes/no, I want to continue with this company" and conditionally if yes trying their best to get the interviewer into the "yes, hire" state.

I'm only going to pick on one of these questions, but they all have the same problem in that they're not (to me) very effective means at fulfilling the purpose since they'll select for candidates most capable of reading your mind, not actually really useful candidates. When you ask "what's your take on accessibility on the web?", the candidate is thinking many things at once. Here are some: 1) do I have a take and what is it? 2) what's the answer the interviewer wants to hear? 3) if my answer is wrong does that make it impossible to get into the "no, don't hire" state? 4) will I know once I answer?

Maybe you want a take that says accessibility is important despite the added costs, because humanism or whatever. If they say accessibility isn't important, because the costs don't justify it, you put them in the "no" bucket. Or perhaps it's vice versa, or you analyze the issue through some other framework. Maybe you really just want to see if they can converse about it at all, and will devil's-advocate the opposite of what they say, and only put them in the "no" bucket if they can't converse or start screaming at you.

In any case, I don't think you're being fair to the candidate and you're likely wasting time. If you just want to test ability to converse, and don't actually care what they personally believe, state that in the question and don't ask for their actual belief: "I'd like to have a sort of philosophical discussion with you about accessibility on the web. Let's imagine I ask you ... and you feel ..." If you actually have a specific range of answers in mind that can put someone in the "no" bucket, put that information in the job description requirements. "Expected to design with accessibility in mind." fits the first of my maybes, "Expected to move fast and not spend time on non-MVP work like accessibility." fits the vice-versa. Presto, no mind games, no wasted time for everyone because it wasn't clear until you asked your question that you hold opposite views and thus this is a "no". Maybe you're worried about liars, which you have to be anyway since plenty of people apply to coding positions without being able to code, so you might ask a more specific question (like we do by asking them to code something) around accessibility that makes clear what conclusion you expect (it matches the job description) and that you're looking for some sort of reasoning for why that conclusion is such in their mind.

Maybe since you're mentioning "end up being really useful" (as opposed to just useful) you don't weigh answers to these questions as hard "yes" or "no" filters, but just "maybes" that you can subjectively reflect upon later (e.g. by adding up a bunch of "maybes" you've recast to point-weighted soft yes/nos that can cancel each other). Fine, you can still put "Bonus:" in the job description, rather than "Required:", so that candidates know ahead of time that if they can only get to the "maybe" state the presence/absence of those certain "Bonus" attributes will influence their chances of moving from "maybe" to "yes". If they're already uncertain about "yes", and see a lack of "bonus" attributes on top of that, they're likely to not bother, again saving everyone's time.

It's fine to distinguish between "really useful" and "useful". Questions that can distinguish between degrees of "maybe" between candidates aren't bad, but they should be back-loaded as much as possible, and only used when the front-loaded yes/no questions have been asked and you're still in a state of uncertainty about which candidate would really be better, lamenting that you only have the budget for one of them. How many of those do you get?

Disclaimer: This is just my personal experience.

For starters, if you're asked a question that is directly relevant to your future work (e.g. "What's your take on accessibility on the web" for a Web developer), you're best served to state your honest opinion.

Do not try to "figure out the right answer." The right answer is the one you believe and you can defend. If that means your answer is "I don't know, I've never had to deal with it, but I know its important," say that and it helps improve the overall signal of the interview.

You might think of this as wasting time, but the interviewer is asking you the same questions that you'll be asked in your new job, but in a simplified form. Just be honest and try to treat the interviewer like a coworker as much as possible.

As I always tell my candidates, "there are no right or wrong answers in this interview."

(Once again, YMMV depending on who is interviewing you or what type of job you want.)

Yea, I've heard that one before.

At least at large companies, with complex (and sometimes written) culture, there are right answers to cultural fit questions. This is where it helps to know someone inside the company who can coach you on the specifics of the culture and help you to learn the right answers. At different companies, the culturally "fit" answer to "What do you prefer to do when you see someone else getting nit-picked?" can be very different! At one company, the better answer could be "coach the nit-picker on effective feedback" and at another, the better answer might be "help the nit recipient with their coding skills." Figure out the right answer for the company you're interviewing with and how to defend it in a way the interviewer expects, given your knowledge of their cultural norms.

Maybe I'm being overly pragmatic but as a candidate, your goal is to get the offer and if possible get the offer at their competitor, too. You're already facing a massive power imbalance. More offers translates into more choices and leverage as a candidate.

I like that you called out that culture fit questions often have right answers. I failed to mention that but it's definitely true. Ironically, the more "cultural" a question is, the more likely it has right and wrong answers.

(As a little background, I'm usually involved in the tech-eval stages of the interview. The "culture fit" is evaluated by other people at our company. So, I don't have a lot of experience with that, unfortunately.)

There's not really a good general solution here, and you might guess in a way that really screws you up. It's easy for the interviewer to tell if the candidate is attempting a "just feed me what I want to hear" strategy, if the candidate has guessed wrong about what I actually want to hear, and now the candidate appears deceitful, a double-whammy. If they have guessed right, though, it's much harder for the interviewer to pick up on it -- which is why for hiring programmers at least it's common (even if rife with its own pitfalls) to do more objective things like asking for a demonstration of basic coding capabilities, because sometimes some people who must really want the job and have Masters degrees and can talk somebody's ear off in a confident enough way to get this far still somehow can't seem to program when asked, the primary activity we need them to do.

Life's not about maximizing the chances of getting a particular job, though. I like ethical policies of being maximally honest, even if you shoot yourself in the foot by revealing you're a bit crazy about homoiconicity or whatever... And generally speaking it's not a terrible guess to assume the interviewer just wants an honest answer primarily even if secondarily the content of the answer isn't what they were hoping for. It's also easy to execute on that guess, since it's usually easy to come off as honest if you're being honest. If the interviewer asks a question that does seem job related (like this accessibility example), honesty is also helpful in that even if your honest answer differs from the interviewer's expected answer, and you don't get hired like you wanted, you might have dodged a bullet by at least surfacing that the difference in opinion or expectations was apparently a big deal there before actually taking the job. Wasteful interviews are wasteful, but it's even more wasteful to take a job, start going through onboarding, and only then you and/or the employer beginning to realize things probably won't work out.

Though if the interviewer asks a loaded question, i.e. one which is well known to be a topic of contention in the industry, it's worth re-evaluating your guess and to respond accordingly. I wouldn't suggest ever outright lying, but the honest, direct answer might not be your friend and as with any adversarial conversation (interviews are not casual chats at a meetup with industry peers, even if they can sometimes feel structurally similar) giving too much information can be detrimental.

Example, the interviewer might toss out "So, tabs or spaces?" Maybe you honestly believe spaces, and maybe you also honestly believe this is something worth flaming about and are ready to go at it if the interviewer dares claim for tabs. You might reveal the basic answer of "Spaces", I wouldn't advise revealing the latter information. Here's an opportunity to guess the intent though, maybe the interviewer just wants to see if you'll try to be funny about the answer rather than answer directly. Ideally the interviewer would guide the interview so that whatever their intention is will be clear.

> "there are no right or wrong answers in this interview."

It's good to tell the candidates something about what your expectations are, that's my whole point! Though I might rework this one a bit. Some personalities would be instantly alarmed by such a phrase... For myself, I'd ignore it and proceed as normal, though part of me would want to ask "So you've already decided on yes/no? Want to regain the hour?"

I'm a developer but was previously a practicing attorney. If you think developer interviews are bad, you should try interviewing for a law firm. Outside of the objective but course metrics like law school rank and class rank, it's almost impossible to tell if a candidate will be a good lawyer or a bad one. Most interviews I was on and administered, we just chatted. The purpose of the interview was to determine if you could hold a normal conversation.

Fun anecdote about this. The morning before a law firm interview I cut myself shaving. It dried and the initial interview went well. But then we went to lunch, and when I wiped my face with a napkin, the cut opened up. I started bleeding all over the place, soaking my napkin in red. The people interviewing me told me to feel free to go to the bathroom and take care of it, but I said "no, I'm fine", and continued to literally make a bloody mess. That was the wrong answer. The right one was to be cool but handle it. I didn't get that job.

I try to tell my candidates something like: "During this interview, my main goal is to understand what it's like to work with you as a coworker. We're not looking for specific right or wrong answers, but more to work together as allies to find the best design." (Background: My interviews usually take the form of pair programming or design discussion).

I'd be curious if you have any recommendations for how I could improve that. I definitely don't want to alarm anybody, if anything my goal is that you can relax and try to treat me like a coworker (to the greatest degree possible in an otherwise stressful setting).

edit: Random tip, although you probably know this already: If the interviewer asks "tabs or spaces?" the correct answer is usually "Whatever the existing code/linter uses." That's one of those questions that there is definitely a right and wrong answer for, because it's basically a culture question not a technical question, so it's one of those questions I always avoid asking :)

I don't have an issue with your approach (I think interviewers who think about the issue at all and occasionally tweak things are going to do better than those who don't) and the fuller version makes it pretty clear that the goal is to create a feeling of getting along well. For many companies the candidate is also interested in that information, but at other companies it doesn't really matter because if hired the two won't actually work with each other, or it will be brief as the new hire changes teams.

I don't do pairing in my interviews but I've thought about it. Before doing it for real I'd want to pair with a coworker on a problem neither of us have solved before, which will happen naturally if pairing is part of the company culture, then pair with them later on a problem I had previously solved but they had not, and see what differences in my own behavior (if any) appear when I have one of the possible solutions in mind. That's my main concern with doing it with a candidate, that the balance on one side of the pair for driving things is just not natural to the usual setting.

You could eliminate that concern by always using a novel problem to yourself (I've got a handful of problems I know something about but have never tried to solve, I do think it'd be fun to try and solve them with a candidate) but then there's the secondary concern in that by the end of it do you really have anything you can say besides "I do/do not get along with them and think we'd work well together"? I like to be able to say a little bit more than that, and also to create the opportunity to say "I like both of these candidates, can't say which one more, they both passed the threshold of solving the problem's basic case, but this one's code covered an extra edge case without me pointing it out." It happens that sometimes I can't even say that, of course, and multiple candidates are equivalent on the criteria I measured. But sometimes it's fine, you just care about some basic threshold, and you can just extend the offer to the first person that satisfies. I think this is probably the case more than many companies big and small want to admit.

> "Example, the interviewer might toss out "So, tabs or spaces?" ...and maybe you also honestly believe this is something worth flaming about ... I wouldn't advise revealing the latter information. Here's an opportunity to guess the intent though."

To me, this reads as "if you want the job then you [should/are entitled to] misrepresent yourself to bypass the filtering mechanism". If that's the case, then your whole reply reads as a complaint about how hard it is to cheat when anti-cheating tactics are in place.

Am I misunderstanding?

> this reads as "if you want the job then you [should/are entitled to] misrepresent yourself to bypass the filtering mechanism".

I don't think so... it's more like, if you have a deeply held viewpoint, can you effectively work with others who have different viewpoints? If you can strike a compromise or convince them to change, that's the best. If you can bury your differences, that's not ideal but at least workable.

Given the spaces/tabs example, if you are sincerely passionate about using spaces instead of tabs, and you're able to convince a tab-user to switch to spaces without upsetting them, that's the best, demonstrating leadership. Almost as good, is if you can explain how much you like spaces but have happily worked together with tab users (tabbers?). Finally, if you say you like spaces but you're happy to keep silent about it (or if you don't mention it at all), that's not as good as the others, but probably fine too.

Any company that values innovation should encourage differing viewpoints to be raised, but not to the point that it becomes a distraction and hinders overall productivity.

You're answering like a person who doesn't hold strong beliefs to a question designed to identify strong beliefs, knowing that you are a person who holds those strong beliefs. Is that not misrepresentation to bypass the filtering mechanism?

We might be talking about slightly different things - if you have a strong belief then I agree you should try sell it, and doing so would demonstrate leadership qualities.

In your example, yes, you would be misrepresenting yourself. But the OP's example is different. Anyone who believes strongly in "spaces over tabs" would/should also know how many silly unproductive flame wars they've started, and also how there may be reasonable arguments on either side. If you do indeed believe strongly in something, then by all means go ahead and say it. But you'd better be able to talk about it intelligently and have considered both sides of the argument. If you're not as educated on the subject, then it's probably not the best idea to wade into the subject during an interview.

That's all this is. Just know your own positions relative to others.

My complaint is with interviewers and their wasteful, unfair hidden criteria. You could phrase it as a complaint that interviewers make use of filtering mechanisms that are impossible to know about without the ability to read minds. There's not necessarily anything wrong with certain filters per se, but it's important the candidate be aware what they are, as early as possible -- if it's in the job description this allows for candidate self-filtering, even.

My advice to interviewees who nevertheless have to deal with such hidden criteria isn't "just always be honest!" but "since you can't mind-read, you have to guess at the hidden criteria, sorry."

I'd suggest being honest as the default, especially if you have no good guess what the real criteria is, or if you're not even presented with anything that gives you a whiff of a hidden criteria being present. But you can be honest without also going into details about grandpa's barn incident. Sometimes you do have a good guess into the interviewer's mind, though, or at least a sense of "reading the atmosphere". (Some interviewers explicitly use hidden criteria but drop more and more hints throughout the interview to eventually reveal it, hoping the candidate notices on their own first.) It might indicate that you should answer the question with a silly meme that came to mind, instead of directly. Or hey, maybe now you realize those details about the barn would be helpful to elaborate on after all. You might also want to adjust your posture if you're getting the sense that they don't appreciate slouchers here, which would be a hidden criteria applied to the interaction itself rather than a particular question.

I wouldn't advocate misrepresenting yourself, but it's standard advice to represent yourself in the best light you can.

The Guess What I'm Thinking strategy to dating, err, job hunting.

More fun than the brogrammer Mensa puzzle bar-raiser hazing ritual.

But whatcha gonna do? We still have to play the game.

My last crash and burn was in response to "Give us an example of a disagreement and how you handled it." So I did. I'm honest to a fault.

[Non-programming manager specified a buzzword compliant "architecture" that simply didn't work. We tried, but every JMS we tried failed under load testing, and the upstream wouldn't accept our PR. And we had run out of time. So I came up with something super simple which just worked, as-in couldn't fail. And it flew and was easy to debug and turned out great, a major selling point. But I kinda didn't actually tell the manager we didn't use JMS, at the time. Who cares? It's internal (non-customer facing). Further, the manager was an erratic maintenance alcoholic, and I just wasn't up for another food fight.]

These two interviewers lost their minds. Incredulous. Couldn't let this go. Repeatedly hammered me on this point. The shift in mood was dramatic.

Definitely not in the "better to ask for forgiveness" camp.

Weird, for a startup.

So while both party thought the other insane, I think the interview questions worked as needed, preventing us from working together.

This is an important point, and it can be difficult as an interviewer to prevent your own self bias to select candidates that respond how you would personally respond.

That being said, I don't think this criticism applies to all the suggested questions. "If you have to solve a problem you haven't solved before, how do you approach it?" seems like a fairly easy one to identify learning methods and response to new problems. Although, a variation of this question was in the original linked article as well (#3).

But as quoted, "If you have to solve a problem you haven't solved before, how do you approach it?" -- my beef with this is it requires mind reading to hit the range of good (to the interviewer) answers. Sure they're asking it to "identify learning methods" or whatever, but that's not a criteria, that's the information they hope to gain, which can have a range of values some good and some bad. What values are good, what values are bad?

At least with technical problem solving challenges, even if the interviewer uses questionable hidden criteria ("ahh, you didn't put the { on the line I wanted you to!"), there's one very visible criteria no one can disagree on, which is whether the problem was solved or not.

If I answer the non-technical version (possibly the same way I might answer the submission's #3, "ok let me tell you about this one problem for which I was initially out of my depth...") but never once mention "ask for help", is that a good sign or a bad sign? I don't know. In some interviewers' eyes, that's an instant-no, for a variety of plausible sounding cultural fit reasons. ("Egotistical", "Not A Team Player", "Hubris.") In others', they might not care if that came up or not. There are lots of alternatives here.

If I say or don't say "Google for how others approached it", good or bad? "I start trying to model it with TLA+..." -- maybe good/bad because of formal methods, maybe good/bad because of unknown (to the interviewer) technology, maybe good/bad because immediately attacking the problem? Reasonable people can believe any of those positions, I don't know without mind reading what the interviewer believes and whether if I believe opposite that's going to scuttle my chances and make everyone regret the sunk time so far. "I grab the nearest whiteboard and start drawing/chatting out the unknowns with another engineer or PM", "I try writing some unit tests"... how big of a problem are we talking about anyway? How unfamiliar is it, anyway? Have I solved something similar even if not exactly the same? What category does the problem naturally fall under? ("I think back through my Polya and try to apply it here..") Maybe the question is really just thrown out to see if I'll answer the question with a question? (Might be good or bad.) Maybe the intent is kind but not executed well, and what I say doesn't matter in the slightest with the question only meant to break the ice, get me talking, and hopefully get past any initial nervousness. (Resume questions are better for that though.)

#3 in the submission is kind enough to point out that companies usually have a hidden criteria for this question:

> The actual problem they describe is unimportant; what matters is how they approached it and how that attitude aligns with your company's values. Some companies stress the importance of teamwork and asking for help, while other companies encourage independent troubleshooting and initiative. Make sure that your candidate can fulfill the job's responsibilities by using the resources available.

Ok, as the candidate, how am I supposed to know without reading the interviewer's mind that the actual problem I bring up is unimportant (some companies actually might want to hear about a cool problem and reject you if you haven't solved anything cool enough -- some hiring processes includes giving a whole presentation on some project you did) and how much it will hurt me if my answer doesn't match their view on the relative value of teamwork vs going it alone? The hint is in the final sentence: make explicit the company's preference, whatever it is, in the "Requirements:" or "Responsibilities:" section of the job posting.

I'm not against culture fit questions in general -- it's important to like the people you work with and reasonable people can very strongly hold that "team player personality" is a hire/no-hire criteria even if I disagree -- I'm against making the criteria of the fit hidden in the interviewer's mind. If there's sufficient context (this paragraph is also acting as a reply to the sibling comment) like the nature of the company¹ or the requirements/expectations laid out in the job posting or relevant "about our company" materials, then even these questions asked as-is can be ok, because the prepared candidate can easily infer what the expected response should be instead of having to read minds. Somewhat fruitless though, since then you're really only testing candidate preparedness; people who would give you "bad" answers would have already filtered themselves out and not had anyone's time wasted. But I would never ask the questions as-is even with the context of a job posting. Were I to ask similar ones, I'd instead rephrase them in a way that the context is explicit in the question, the real criteria and what I'm hoping to hear about is revealed. This also makes it safe in the common case of disconnect between the interviewers and whoever wrote the job posting.

¹Though I have no idea what Bain Capital is about I would not be hasty concluding one way or another about an employee's feelings on web accessibility. I'll note that their home page loads and renders great in Links.

Why doesn't the question work?