Live data from Hacker News

Coding interviews are stupid (ish)

darrenkopp.com

431–440 of 679 posts

Re: Coding interviews are stupid (ish)

#431

Earlier quoted context omitted.

>I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. I've also had to work with hash tables directly, and with memory caching layers. I really should learn…

> I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. How many times did you have to write tree balancing code with no reference materials?

The exact same number of times I've been asked that during an interview: 0!

I do ask tree traversal questions when interviewing because I've had to traverse a lot of trees so I think being able to do an in order traversal of an already sorted binary tree (which is only a handful of lines of code) is fair game.

Re: Coding interviews are stupid (ish)

#432
post #214
post #197

Earlier quoted context omitted.

15 hours! You're hiring contractors not interviewing.

this seems completely reasonable compared to endless whiteboarding?

Adding up all the overhead and stuff that comes before and after, we're talking about an interview process that's 3 full work days. That seems a lot, even when you're paying people. People will either have to take days off their job or sacrifice weekends.

Re: Coding interviews are stupid (ish)

#433

Assuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a matter of minutes, there is actually a different way to do coding interview: just give a high-level description of a sophisticated enough algorithm to a candidate and ask the candidate to turn that into code. I think it strikes a good balance between depth in C…

I have a different take on this. I ask a fairly simple coding question and have them write code. No fancy algorithms to memorize or competition style coding.

I want to see if they can think in code. If they can translate something simple to written code. There's always a chance to have a conversation as well to probe different aspects of their understanding.

A few of those by a few people and I think you get a pretty good read.

Mix in some questions about their work and/or some general knowledge. I've also given people code to read (real world code) and explain to me.

For Algorithms and Data Structures I can look at their grades if they're fresh out of school. But we all know most of our work is not that (someone's gonna show up on the thread and say differently - I'm sure ;) ). If you can think in code and have the right mental models implementing an algorithm from a book isn't hard if you really have to.

Re: Coding interviews are stupid (ish)

#434

Earlier quoted context omitted.

> I've had to work on tree traversal stuff multiple times in my life, anything low level GUI related will work with trees a ton. How many times did you have to write tree balancing code with no reference materials?

Bingo. You forgot to add "with someone literally looking over your shoulder," though. I've written AVL trees, B-trees, red black trees, and a bunch of other things people have named here. But, right now, without looking at any references, I couldn't even tell you how to balance an AVL tree, much less sit down and write out code for it.

That's why these interviews select for recent grads. Or leet code studiers.

Yes we've all done this in university. We've learned the theory. We had to write an implementation of this or that algorithm in whatever language the university made us use.

And we also know that great minds took a long time to come up with these in the first place. These "basic algorithms" are not something you think up in 5 minutes after first learning that computers exist or that some problem exists.

Bin packing algorithms are another such thing. Sure ask me interview "questions" like "please prove whether P=NP".

Eff off Mr. or Mrs. interviewer!

Re: Coding interviews are stupid (ish)

#435
post #262

Earlier quoted context omitted.

I, personally, cannot _think_ and _talk_ at the same time. It's just a stream of half-sentences, many of which my brain has already moved on from because what I originally thought won't work. After writing this article it became very apparent to me that I'm complete garbage at interviews, but I'll outperform and exceed at the actual job function.

In my work, if you literally cannot write any code while also discussing the code, and if you literally cannot express thoughts while also thinking them, then you actually wont exceed at the actual job function, at all. You're not the only programmer on the team. I don't know why people think communication skills are not required for programmers. You won't be coding the correct thing unless you can talk about what yo…

>I don't know why people think communication skills are not required for programmers

That so significantly fails to resemble the claims being made that it strains credulity that it could be a good faith interpretation of the conversation.

>You won't be coding the correct thing unless you can talk about what you're doing.

Maybe, but that has no bearing on whether they need to be done at the same time, which they do not in just about work environment. I guess there's probably somewhere that does mandatory pair programming for everything, but I've certainly never seen it.

Re: Coding interviews are stupid (ish)

#436

Assuming that a company does not look for candidates who are naturally good at ICPC-type of questions or geniuses who can come up with amazing algorithms in a matter of minutes, there is actually a different way to do coding interview: just give a high-level description of a sophisticated enough algorithm to a candidate and ask the candidate to turn that into code. I think it strikes a good balance between depth in C…

Unless you have data to show that your "different way" produces better results, your idea sounds exactly the same as every other idea, which is basically garbage. Lots of people have lots of ideas on what makes a great interview question, but none of them are backed by data. LeetCode-style algo questions USED to be an indicator of intelligence as per Google's investigation, but now it's so heavily gamed that I doubt…

Don't discard good anecdotal evidence because there's no proper randomly controlled trial. If you're experienced/senior in the industry you probably worked with dozens of developers closely, with hundreds less closely, you've seen many projects and designs, you've interviewed and was involved in the hiring of dozens of people.

This random controlled trial you're talking about is so hard to do because there are infinite confounders. How do you even measure success? After how long? How do you separate politics from technical ability?

In reality people above a certain bar are able to make some contribution to most projects. You can't and don't need to staff every project with superstars. The superstars are rare but are not hard to identify. They'll have the track record, reputation and the skills.

Another thing to consider is that the best outcome of interviews depends on the quality of the pipeline into those interviews. If you can't get good employees to apply you won't get good employees hired. Pay well and build a company that people want to work for, and then your hiring is going to be easier.

Re: Coding interviews are stupid (ish)

#437

Earlier quoted context omitted.

> I still don't get why such questions are even asked The thesis is not that these exercises are representative of work but rather predictive of performance. Sales has a similar phenomenon with sports. While there is no athleticism involved in selling, many believe history in competitive sports to be a positive predictor of sales success. --- You can reasonably argue whether leetcode accomplishes this well or poorly,…

> Sales has a similar phenomenon with sports. While there is no athleticism involved in selling, many believe history in competitive sports to be a positive predictor of sales success. This is interesting. I had never heard this before. Is there any research on this? For that matter, is there any actual research showing that leetcode-style interviews actually do predict performance? If so, do they do so any better or…

I recall reading that leetcode style questions are basically just a standin for an IQ test, except with plausible deniability for being directly applicable to the job.

Re: Coding interviews are stupid (ish)

#438

Earlier quoted context omitted.

> Unless you have data to show that your "different way" produces better results, your idea sounds exactly the same as every other idea, which is basically garbage. Do you have evidence that the standard coding interview works? (There's evidence that it doesn't) I'm with you that the claim might be too strong to say "this is the way" but that's because I'm of the (very strong) opinion that interviewing is an extremel…

> Do you have evidence that the standard coding interview works? No, I think that they are all garbage. The only way to really hire is by having a vibe check to see if they are someone the team wants to work with, making sure that the person seems competent and has a reasonable chance of being very productive, and then hiring them quick. Give them a month and if they don't seem like a good fit, then fire them, with 2…

But we're talking about "seems competent and has a reasonable chance of being very productive". That's why you're interviewing in the first place. If you don't ask them to demonstrate their competence in any way how do you know they're competent? If they can't "produce" anything during an interview (even something trivial) how do you know they'll be productive? Assuming a complete stranger with no references you can trust.

A month might be too short of a time for certain roles. I think people would be hesitant to take a risk with you if they know this is your policy. I'd would say that at any point where someone is clearly not a fit they should be let go. You might know after a month (if they're terrible), you might know after 6 months, they might progress initially but stall. I think e.g. with new grads it's going to take a little longer in general since they have a pretty long growth trajectory.

Re: Coding interviews are stupid (ish)

#439
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 don’t talk while I code. You don’t either.

Speak for yourself

Post reply on HN