Thread by @danluu

I'm starting to wonder if design interviews are not only useless, but actually contributors to poor design.

I'm still thinking through this, by my reasoning for this is:

There've been times where I've reduced the implementation effort of something by 100x to 1000x, producing in 1 day something that replaced ~1 year of work (proposed or actual).

This has never been with "design interview" reasoning, it's always been domain knowledge.

This doesn't mean you have to be a deep domain expert, in the two most extreme cases, it was something I came to pretty soon after starting work in a new (to me) field.

But it was still after much more time than you get in a design interview.

Interviewers sometimes try to get around this by saying you should questions assumptions, etc., but I don't think this would have worked in either case.

In one case, the solution resolved something that had been an open problem in IR for decades, that's not interview material.

In the other case, the solution was to relax an unnecessary constraint. I think it would've been v. difficult to successfully challenge such a fundamental assumption in an interview, it's probably faster to just build the thing (which is what I did), but not feasible in interview

For my most recent design interview my answers to "how would you scale M up to limit A?" were, in descending order of preference (the interviewers thankfully didn't fail me for this):

1. Buy a solution from N that's known to scale up to 100x A

2. Talk to expert O, who has solved this problem before, ask for other experts to talk to and see what they have to say
3. Read the relevant bits on LWN and LKML, understand how the open source implementation of M by company P works
4. Run experiments, profile, read code, etc.

5. The usual design interview nonsense, boxes and arrows, Fermi estimates, say "pubsub" a few times, etc.

The interviewers very patiently explained to me that solutions 1-4 were invalid and kindly didn't fail me for those (I think most would've), but what's the point of this?

I see a lot of systems that look like they were designed by skipping straight to step (5).

Of course I can't prove a causal link from design interviews, but it seems plausible that design interviews train people to design real systems without understanding the problem domain.

People say these interviews "measure how you think", but @hillelogram has looked into the history for other kinds of interview questions, he found "how you think" was a post hoc rationalization for questions that were originally asked for other reasons.

Likely same here.

But even without looking at the historical record, "how you think" seems bogus

To answer a Fermi estimation question, you just need to know how to play the Fermi estimation game. Make up numbers, multiply them together, and then you pass.

Basically ditto for design interviews. "Sure," said the interviewer. After a moment, I said, "nineteen". He looked confused.
"How did you get that answer?" he asked. I looked confused.
"I counted."
Presumably he hadn't been expecting to interview someone who grew up in Manhattan, went to school in the Bronx, and spent a lot of time driving around New York with her dad.
I didn't get the job. Apparently, they were looking for people who used some process other than arithmetic to figure out how many gas stations there were in Manhattan." src="/images/1px.png" data-src="https://pbs.twimg.com/media/EY_bv8YVAAACvsK.png">