DEV Community

System Design is More Important Than You Think

David Zhang on February 07, 2024

This past month, I've been going all in on system design. After face-planting badly in one of my interviews (Temper your imposter syndrome by readi...

Read full post

Velda Kiara • Feb 8

I really enjoyed reading your article Zhang.

I played the quiz game on your site, I would be happy to be part of the people you ask for feedback incase you want to add more features or games.

Thank you 😃😊.

squidbe • Feb 14

That's because most of the problems you'll be solving [in interviews] aren't things you'll encounter in your actual job.

(My response to this is looong, so the tl;dr is there's little to no evidence that algo solving correlates to on-the-job success, so why not test candidates on something that reflects what their day-to-day experience will be?)

Long version:
As someone who has been on both sides of the interview table more times than I can remember, I find what you pointed out to be endlessly frustrating. Given that interviews are such an important process for any company, it's baffling that there's so little science backing up the ways many companies choose to conduct interviews. Frankly, there's a lot of lemming behavior. "FAANG does it, so it must be right."

In interviews, we're sometimes asked, "Tell me about a time you used data to make a decision." I'd like to ask interviewers, "How do you use data to determine how you conduct technical interviews?" I've actually asked some colleagues this question (I haven't been brave enough to ask it of an interviewer when I was the interviewee, though I've often wanted to 😊). I haven't received a single answer that wasn't some variation on anecdotal evidence, and that's not surprising because correlating interview performance with job performance is a highly qualitative assessment, and a difficult one at that.

But given the lack of quantitative data on the subject, doesn't it make sense to ask engineers to do something that reflects what they'll be spending most of their time doing on the job? (That's a rhetorical question 😊.)

The last time I was in a position where I was interviewing candidates a lot, I came up with a mini app for them to build which included a variety of assessments including algorithmic, experiential, research methods/approach, language knowledge, and time management among other things.

The last one (time management) was important in that the app was purposely designed to be impossible to finish in the allotted 45 minutes – I told them they were not expected to completely finish it, and they were free to use Google or any other online resource for help. The point of this was to have a better metric to compare candidates. If everyone finished the exercise, then the assessment would be entirely qualitative and, hence, less insightful. The goal was to come up with the most complete app experience possible in the time allotted. Giving candidates more work than could be completed showed how they prioritized tasks and managed time/pressure.

My team agreed this approach gave us more insight into candidates than just doing some leetcode algo(s). What's weird is that this approach was hardly revolutionary. In fact, it's how most technical interviews were conducted years ago. Why companies became obsessed with algo solving as THE technical interview metric is a mystery to me.

David Zhang • Feb 14

Hey! Thanks for reading and I appreciate the input here.

I can definitely relate to being frustrated with contrived interview formats. To be fair, algo interviews are a super quick way to screen out a lot of applicants which, in practical terms, makes sense for FAANG who get hundreds of thousands of people applying every day. But like you mentioned, it kind of went too far when other companies started following suit, eventually over-relying on these kinds of questions to gauge a candidate's technical skills.

The good news is that in recent times I've seen a lot of pushback against traditional "Leetcode" interviews. Virtually all the startups I interviewed with recently asked me relevant questions that were representative of the day to day work. And none of those ever felt like interrogations - they were collaborative experiences that tried to simulate working with a coworker as opposed to working with an audience.