Comment by srich36 | Hacker News Reader

Comment by srich36 | Hacker News Reader

New graduate here who has this admittedly been on only one side of the interview process. In my interviews I got mostly white boarding problems and one take home. The author was mostly correct in discussing the advantages and disadvantages of both (namely the extra-time for take home assignments and archaic algorithms for white boarding) but I feel there are a couple points I can add.

First, I actually believe white boarding questions (at least the automated kind) are assigned more indiscriminately than take home assignments. Many companies just send you online timed hackerrank or leetcode questions as a preliminary filter.

Second, the entire interview process rewards people who study for the interviews rather than those who like to build projects. Unfortunately I believe companies miss out on a lot of qualified candidates, albeit reducing their false-positives from obscure algorithm-type problems. With so many applicants, reducing false-positives ensures quality hires so it works on the company’s end.

Overall, my opinion is the interview process is relatively broken. Take-home assignments offer more insight into actual development skill, while whiteboard questions filter out a large portion of people (many who would be just as good, if not better, at actual implementations.) But it works for the interviewers so change seems unlikely. This is just my experience for new graduate interviews; perhaps it is different at higher levels.

> Second, the entire interview process rewards people who study for the interviews rather than those who like to build projects. Unfortunately I believe companies miss out on a lot of qualified candidates, albeit reducing their false-positives from obscure algorithm-type problems. With so many applicants, reducing false-positives ensures quality hires so it works on the company’s end.

There's still quite a lot of signal for an interviewer in someone being ready to do the extra work to achieve the goal (e.g. study for interview) vs. someone how doesn't want to invest time into studying and just wants to throw stuff together. This is especially important for junior developers (since as a company you'll want to train them up long-term to be promoted into higher level), but still remains important for senior developers (since being stuck with someone who refuses to learn new skills is a long-term problem for the company).

> There's still quite a lot of signal for an interviewer in someone being ready to do the extra work to achieve the goal (e.g. study for interview) vs. someone how doesn't want to invest time into studying and just wants to throw stuff together.

There's still quite a lot of signal for an interviewer in someone being ready to do the extra work to achieve the goal (e.g. write a real application) vs. someone how doesn't want to invest time into writing a real application and just wants to play with little algorithms and exercises.

Now if you smell a straw man or false dichotomy (hint: writing software instead of cramming leetcode doesn't mean you're not learning new skills; and vice versa) in this, you're on the right track.

The other thing is, what exactly is this signal? What does it tell the interviewer? They have their prejudice, so the signal tells them what they want to hear.

Maybe the actual signal is "I'm bored and desperate and don't have real skills and can't think of anything creative to do so I'll just cram leetcode until some unfortunate company thinks I'm leet and hires me. Because someone on the internet told me that's how you get a job."

This is why I'm not very keen to hand wave about "signal" if there's no way to give it an unambiguous interpretation. In these hiring discussions, I've seen so many examples of "signal" that can be interpreted any number of ways but someone thought they came up with a clever interviewing method so their interpretation of the signal must be right... right?

If it's a hazing ritual and lots of jumping through hoops, the only signal you have is that a person is willing to go through a hazing ritual and jump through hoops. Don't assume anything else. In particular, don't assume it says anything about the skills or capabilities of those who are not willing to go through it.

I can't speak for others, but for my "senior" level interviews, I do not study. I am coming into these interviews proclaiming a certain number of years of experience in my domain(s). If I have to study, then either I don't know my alleged domain as well as I have claimed, or the questions being asked are irrelevant to said domain.

It could reward those people because it exemplifies following a spec and completing to spec. The whole thing, studying and showing you will do things you don’t want to do (and do them well), and complete a really absurd set of requirements that have seemingly no value.

However, you will stand out if you ask “why did you choose those questions?” Or “how did you come up with those problems?”

Even the best interview that fits in all the check boxes trumps a similar candidate who shows they give a shit.

Wouldn't this be fixed by presenting a on-site assignments? For example a small project, with test suites, where a feature or two needs to be completed and tests updated?

(Disclosure: We did this at a company I worked at).

Reply on news.ycombinator.com