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:
-
Show this thread
-
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.
2 replies 3 retweets 61 likesShow this thread -
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.
2 replies 1 retweet 13 likesShow this thread -
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.
2 replies 0 retweets 8 likesShow this thread -
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
2 replies 0 retweets 13 likesShow this thread -
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
1 reply 2 retweets 31 likesShow this thread -
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.
1 reply 0 retweets 28 likesShow this thread -
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?
3 replies 0 retweets 13 likesShow this thread -
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.
3 replies 3 retweets 38 likesShow this thread
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.pic.twitter.com/zoOU85g5ac
6 replies 14 retweets 85 likesShow this threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.