Faking Software Design

Posted in Interview

I’ve been having a back-and-forth with a friend on getting a software developer job in Japan. Cultural differences aside – and there are quite a few – we reached an impasse in debating how to approach a software engineering design question within the context of an interview. To summarize, he wants to find the right study materials to academically understand the problems and solutions, whereas I encouraged a more hands-on approach with self-driven project work.

Now, I’ve written about software development interviews before, and I’ve done enough (on both sides!) to have a good idea of how these things go and what interviewers are looking for. The engineering design question is tricky, both because of the additional space in exploring the solution, and because good engineering is about trade-offs and making informed judgement calls, which lack the resolute certainty of compilable, runnable code1.

I insist that design interviews are hard to fake. Whereas there can be some preparation for expected technical questions, it’s pretty hard to study-cram the design of software systems as there’s just so many facets to discuss, and the ability to dig deeper into any part of the system trips up candidates who only superficially understand how the entire thing works. In fact, the best interviewees for design interviews are relate the systems discussed to those they’ve built and used, and can point to the various nuances which have much wider implications.

As the interviewer, one thing to keep aware is that we have a natural bias in discussing systems that we have built, and using those systems as the subject of discussion may trigger those biases when rendering judgement. We shouldn’t discount a solution because it wasn’t what we ourselves have built; after all, we had more than 5 minutes to think about how to design it, and they may be making different tradeoffs or actually be building something better! I’m starting to avoid using my own work as the question for this reason, even if it means having to do more work to understand another one.

Back to interview preparation, the one caveat about working on personal projects is that they may never hit the scale or feature set that would coincide with typical design areas: scaling, storage, caching, client/server interactions, user interfaces2. My only suggestion here is to be honest about your design ability and experience, and that it’s okay to admit to not having built systems with these concerns but still have meaningful discussion about its engineering.

  1. I personally find that asking expansive, go-anywhere-you-want questions make for more interesting conversation, but that makes grading the interviewee all-the-more difficult

  2. For front-end and mobile client folks.