Hacker News Reader

Comment by sdo72 | Hacker News Reader

Not sure why this is offended, but I actually think he may have some chances failing the interview if he goes through. I do think he's definitely capable and knowledgeable of doing a principal/fellow engineer job.

I went through a few interviews myself recently and I got very puzzled with the interview process. It's quite brutal. And I just went through a 5 technical rounds after passing the first 2 rounds (1 technical and 1 behavioral) for a senior position. The 5 rounds include: architecture design, model/object algo design, refactoring/optimization, build a complete CRUD api with tests. I know how to build these things and I would take time to do it, but I couldn't do it with the very fast speed that I was limited to during the interview.

View on HN

Even if we accept CS101-styled timed coding questions as a necessary evil to weed out the fakers, having recently been on the receiving end of some of the "system design" questions recently, I must say it's a really really bad idea to (1) having these subject to a tight time limit, and/or (2) treat this as if it's a standardized test.

The worst offenders (according to myself):

- Expected me to "design a xxxxx-ing system" (topic redacted but it's really broad) in 25 minutes. This is barely enough to get to narrow down the scope and clarify the requirements.

- Presented me with a specific problem using almost exclusively domain-specific jargon, without explaining any of it. Time limit is 30 min. Not wanting to "waste" all my time budget clarifying, but apparently (1) they did not like anything about what I hacked up (2) wouldn't give any feedback on why they didn't like it either. Ended up really awkward.

- Presented me with a more normal, self-contained design problem (finally!). Time limit is 45 min (seemed reasonable?). So I proceeded normally. However after the interview I was informed that during this 45 min I did not cover a certain topics "A, B, or even C", and therefore scored really low. Apparently, lack of a signal for them is an anti-signal.

The list can go on and on; point being, while the coding questions have been thoroughly calibrated, esp. w.r.t. what is a reasonable time to solve each question, more likely than not a "system design question" is poorly designed. Even from an employer's perspective, I'd be confused about what kind of signal these interviews are designed to extract. Yet, our industry as a whole is increasingly more keen on gatekeeping "Senior+" positions with them (alongside with other draconian measures).

My take on how they can be improved, if not abolished altogether:

1. Relaxing the time limit to say 75 minutes; better to have some people "finish" early;

2. Train the interviewers to help with setting expectations on the pace

3. Either have the interviewer nudge the candidate when the open-ended question receives an unexpected take, or be ready to evaluate them fairly.

These kinds of questions aren't bad per se, but they should be used as a basis for an open-ended discussion with the candidate. Kind of like conversation starters: "Let's discuss how you would approach designing a simple solution that does X, Y and Z".

Asking the candidate to write down a system design on a whiteboard, or even worse, defining the API, is terrible. No one does that in a vacuum, and if they are forced to do it, it's pretty much random whether the person managed to tick all the boxes that the interviewer (or whoever wrote the test) considers important.

> whether the person managed to tick all the boxes that the interviewer (or whoever wrote the test) considers important

Exactly, and "API design" is one of the MANY boxes expected to be ticked early on. Just watch one of these "system design interview how-to" videos online.

> it's pretty much random

That is an accurate summary of most whiteboard interviews.

This might not be truly universal, but by and large coding interviews can be and has been made more or less a standardized test, whiteboard or online collab (e.g. HackerRank, CoderPad, ...) alike. Like any standardized test, you can practice to become more or less consistent.

It's true that some interviewers might hand out whacky and/or ill-defined problems, but my experience on both sides of the interview indicates that the average difficulty of problems has converged onto what is now known as "LeetCode Medium". The problem will be random, but the difficulty won't. Why this benefits interviewers is left as an exercise for the reader.

> That is an accurate summary of most interviews.

FTFY.

System design interviews aren't about system design. They are about demonstrating you are a particular kind of person. They are the vague, undefined, "culture fit" interviews that tech companies pretend they don't conduct.

> Expected me to "design a xxxxx-ing system" (topic redacted but it's really broad) in 25 minutes. This is barely enough to get to narrow down the scope and clarify the requirements.

Tech company? Probably a track-ing system. ;-(

Crash/trash-ing system would also be realistic.

>>I know how to build these things and I would take time to do it, but I couldn't do it with the very fast speed that I was limited to during the interview.

I've been rejected even after doing all these things. I didn't read the interviewer's favorite paper from Google, therefore the feedback given was I wasn't a passionate engineer.

On the other hand almost anywhere I hear people getting hired often(The ones who jump jobs and get placed often) have struggle staying and building even trivial stuff.

As it turns people who get jobs, are good at interviews aren't all that good at doing their job.

Reply on news.ycombinator.com