Live data from Hacker News

Coding interviews are stupid (ish)

darrenkopp.com

521–530 of 679 posts

Re: Coding interviews are stupid (ish)

#521

Maaaaaybe, but I’m not ditching them. When I’m interviewing someone, I try to set them at ease. I’m not here to spot typos. I’m trying trying to trick you. I want to see how you think about problem solving, and I’m cheering for tou . I want you to be The One! At a prior job I was the person who asked candidates to write fizzbuzz, and it was much more of a filter than I ever would have suspected. One senior engineer,…

It's worth pointing out that there are all kinds or reasons why competent people may perform poorly at a given interview.

Re: Coding interviews are stupid (ish)

#523

Eh, if you hate coding interviews such much you can try something else like welding. Oh wait, welders have to prove they can weld before they get hired? [1] --- The general issue with coding interviews is most companies don't validate that the interview is actually correlated with job performance. Of course a process where the blind leads the blind is going to have issues. [1]: https://www.reddit.com/r/Welding/commen…

> The general issue with coding interviews is most companies don't validate that the interview is actually correlated with job performance. Of course a process where the blind leads the blind is going to have issues.

Yes, I was looking for someone to finally say this!

Without the feedback, the process is much more like an initiation ceremony to "legitimise" the hiring of the new employee. You put them through an fairly arbitrary ordeal so they can finally be crowned as a proper employee.

Re: Coding interviews are stupid (ish)

#524
I wonder if an interview process more like academic science would help.

It usually goes like this:

Candidates are roughly screened by their CV. A handful (in my experience roughly 6) are invited to hang out at the lab for most of the day.

They usually give a presentation on previous projects, and then chat with each member of the lab in turn, hearing about their work and asking questions etc.

Then you all go and have lunch together (usually without the boss). Later the candidate has a more formal panel interview with the group leader and some other faculty.

A few days later, they are told the outcome of the interview.

It may seem like a long process, but it all happens in one hit. The advantage is you get a much better feel of the candidate over this continuous process, than you would with shorter interview tasks.

Re: Coding interviews are stupid (ish)

#525
The way I handled interviews during my short stint as a manager was to just ask questions related to the task the person was going to do. No general "coding questions", no need for that, the specific topic they'll be working on.

"Have you heard of X? How would you deal with Y in situation Z? Your CV says you worked on A, have you also looked into B? Any guess why we went with B instead of A for C?"

They didn't need to give the exact answer we wanted, the questions they asked in response often told us more than the straight answers.

Everyone I hired is still at the company and one of them sped up our tool by an order of magnitude. No coding challenges needed.

Re: Coding interviews are stupid (ish)

#526
post #203

Earlier quoted context omitted.

Exactly this. In the interviews I give I care about whether the candidate can write code, yes, but also talk and think about code. The conversation is the most important part of the interview, and the thinking (and communication) is the most important thing I'm trying to judge after basic skills. Like you said, you can get a good sense within the first few lines of pseudocode if someone's at least competent at writin…

Coding tests are an awful place to test someone’s conversational skills. I don’t talk while I code. You don’t either. Honestly I can’t even remember the last time I talked to anyone about the code itself outside of a PR. People talk about architecture and database migrations and why their containers aren’t behaving locally. Nobody ever tests for that stuff.

I consider taking while I code to be a somewhat useful skill. I’m totally capable of verbalizing my thought process as I work through a problem

Re: Coding interviews are stupid (ish)

#528

Earlier quoted context omitted.

> But if you ever want to go deeper, you’ve gotta understand data structures and algorithms. I don't think this is quite right. I think it's more like: If you ever want to go deeper, you've gotta be able to recognize when the problem you're solving fits a pattern for which good data structures and/or algorithms exist, and you've gotta be able to find, understand, and apply good reference material. Solving this "knowi…

Yeah I think that’s what I mean by “understand data structures and algorithms”. Or, I think your description is exactly what a useful working understanding looks like. You should know broadly what’s out there so if a problem comes up, you know where to look. (Would a hash table help? A priority queue? etc). And you should be skilled enough such that if you decide to use a red-black tree, you can find a good library o…

I agree that I think this is what most experienced people mean when they think of understanding data structures and algorithms.

The problem is that this kind of understanding is very rarely what coding interviews check for. They either don't check for this at all - instead just making sure people can write simple code while reasoning through a simple problems under time pressure - or they check for whether people memorized a textbook, looking for a specific non-obvious data structure and algorithm.

What I try to do, because I think it almost ticks all the boxes without asking for memorization, is ask questions that start with the simple "can you program at all" part, with follow up parts that end up in a place where we can have a conversation (without implementation) about how different tradeoffs could be improved, which often leads to discussing what useful prior art might exist.

Unfortunately I think this still has very high false negative issues. I've worked with people who prove to be perfectly capable of noticing when an appropriate data structure will make a big difference in their actual work, without that coming out in their interview.

Re: Coding interviews are stupid (ish)

#529
post #505

My attitude towards code interviews is to politely decline them and encourage people best of luck hiring a junior developer; because that's obviously what they are looking for. I'm closing in on 50, so not that junior anymore. If anyone has any doubts about my coding abilities after reading my CV, browsing my Github repos, and talking to me, then it's not going to work and we can both save ourselves some time. I've s…

I totally understand your point of view, but looking at it from the other side it’s not as simple. We had candidates with 10+ years of experience in their resume, talking to them it seemed they know what they’re doing, they showed some of the code they’ve supposedly written. Then they got hired and it turned out they can’t code - their PRs are below junior level, constant bugs, communication is abysmal, they overshoo…

So have the candidate do a small project and submit a PR.

Re: Coding interviews are stupid (ish)

#530
post #484

Earlier quoted context omitted.

>Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. What about the lad who develops homebrew who got rejected from Google because he wasn't able to invert a binary tree on the spot? Many Googlers use his software internally and externally. If the purpose of the interview is to make sure he can code why did…

Why does "Many Googlers use his software internally and externally" mean he would be a good hire for Google? From all his public complaining about failing an interview it seems Google did the right thing not hiring him, he has a massive ego and it's very possible that "writing homebrew" is less useful to google than "inverting a binary tree"

Here's another way of phrasing it -- if Linus Torvalds went for an interview with Google would he have to invert a binary tree and if he failed to do so (maybe he misconstrues the question and messes up or him being Linus and just refusing) would that be a good reason to reject him? Linus also can be equally or far more egotistical than Max Howell.
Post reply on HN