Comment by kronin | Hacker News Reader

Comment by kronin | Hacker News Reader

Parent Full thread

My interview covers coding, data structures, algorithms, system design and data modeling. I attempt to tailor to the candidate, but there needs to be some level of standardization to be able to justify to the recruiters why a candidate didn't proceed.

Just because a candidate fails or falls short in one area doesn't mean they are cut, but it's a pretty large red flag if a candidate purports to know something, both on their resume and in person, yet can't answer some seemingly basic questions. If you state on your resume that you architected and implemented a system end to end, yet can't whiteboard the result and explain bottlenecks or failure conditions, I absolutely will assume you stretched the truth a bit. And if the candidate feels the need to do that to get the job, what will it be like to work with them? Could you trust their estimates? Would you be able to back them if something they delivered fails and you trusted them as a senior to deliver?

I ask follow-ups. I give hints. Honestly I'm dismayed at the skillset of purported "seniors" and "architects", and that's interviewing for small companies up to one of the FAANGs.

I've never counted but I must have done way more than 300 interviews. I have interviewed at 3/5 of the FAANG.

Coding: on a whiteboard or with someone watching over you has no correlation with performance on the job.

Data structures: questions usually end up so contrite that they have no bearing to real-world situations. That or based on luck of seeing an remembering the right one. Data structures usually go hand in hand with algorithms.

Algorithms: questions become more like trivia or reinventing something that has likely got research papers on it. Oh, you want me to invent an algorithm I've never heard of on a whiteboard with your clues?

System design and data modelling: the kind of thing you can do in an interview lacks real-world data. No empiricism. It's all about the trade-offs.

Tailoring to the candidate introduces inconsistency and unfairness/luck.

What if these "seniors" and "architects" are frauds?! How else could they hold down a job for 20 years and not be able to answer my questions? They must be really bad!

Lucky my interview process is really great and I always hire the good ones. I track every rejection and I have proof that they never amount to anything!

Do you allow candidates to use their normal workflow (which is dependent on access to Google, github and q&a sites) or are we putting people in an idealized workflow where the dev has to know everything? I think many developers and interviewers think using Google and StackOverflow is a sign of weakness. It may or may not be, but it is normal in many developers workflows.

Thoughts?

I tell the candidates that I will happily be their Google/stack overflow. Some candidates ask questions along that line, some don't.

I agree that we don't code in a vacuum. What I'm trying to ascertain in the interview is how someone thinks, how they approach a problem and work through the solution. The more they communicate the better, even if part of that communication is "is there a length property on the String class?"

I note, but don't give it too much weight, if there are minor syntax errors. I ask candidates to walk through their code with an example input, especially the ones that have errors. If they catch their errors and fix them, I note that. If they skip over their errors because they assume the code does what they wanted it to, I note that.

Ultimately, can you reason through the problem, come up with a solution, and talk about the tradeoffs you made in your implementation. Any senior should be able to handle that without any preparation.

I worked at a FAANG where in several loop debriefs I was challenged on the complexity of my question. One of the challengers asks a chutes and ladders question (given a random chutes and ladders board, where you can choose between 1-6 for every move, what is the minimum number of moves to get to the end).

It doesn't take a hard technical question to figure out whether someone knows how to think and work through problems.

Reply on news.ycombinator.com