Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coding interviews are stupid (ish)

darrenkopp.com

Post reply on HN
Print view View original

331–340 of 679 posts

Re: Coding interviews are stupid (ish)

#331

Post by Paul-Craft »

paulddraper wrote: post #285
xandrius wrote: post #257

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. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system struc…

> 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 differently than an IQ test?

Re: Coding interviews are stupid (ish)

#332

Post by scruple »

godelski wrote: post #310
xandrius wrote: post #257

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. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system struc…

> if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit…

I've only ever had a single whiteboard interview in my career, and it was a single interviewer who preferred them (I accepted the job), but I have also walked through the backdoor via recommendations for all but 1 of my employers in ~20 years in the industry. From embedded in radio and television broadcasting, to medical robotics, to AAA games, with some excursions into web development. Every other interview at a company I accepted an offer for was a conversation with engineers about my experience and some hypotheticals.

Re: Coding interviews are stupid (ish)

#333

Post by darrenkopp »

spankalee wrote: post #189
dilyevsky wrote: post #139

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. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

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…

Adding another comment here, because this is part of the reason why I wrote this article.

> These kind of articles make me sad because I (and many other interviewers I've worked with) try to make it clear that this isn't a test - we don't care so much about being "right" or "wrong", and there shouldn't be any tricks of "a ha" moments. > We explain the goals and what we're looking for right up front. And I would hope most interviewers do the same, but I guess not. So there's this persistent myth among both interviewers and candidates that coding questions are about getting a right answer.

I understand all of those things. I've written the same before[1]. However, as clear as your instructions are and as well meaning you may be, it may not help. I can logically understand every word you say, but as soon as that question rolls out, I will now be dealing with stress hormones and 30 years of learned behaviors from thousands of experiences, whether I choose to or not.

So while I applaud your methodology and wholeheartedly agree, just telling people that doesn't guarantee that it's not still an issue because humans are complex organisms.

[1]: https://darrenkopp.com/posts/2016/02/25/always-learn-somethi...

Re: Coding interviews are stupid (ish)

#334

Post by mewpmewp2 »

josephg wrote: post #327
mewpmewp2 wrote: post #325

Earlier quoted context omitted.

I would be scared you are overengineering and optimising things though. I have seen people implementing complex paradigms and weird optimisations instead of writing simple code just to make sure they are perfectly optimising. E.g. optimising client side code where N is likely never to be above 300, but instead of few simple lines, write a complicated solution to make sure it can scale to billions and beyond. I would…

Skill gives you the gift of choice. You know how to write it either way around and it’s up to you to decide. Being able to correctly decide when to hack something inefficient together and when to optimise is another skill issue. It’d make a good interview question, that.

Yeah, but leetcode does not necessarily give you that skill or even prove it. And a talented problem solver would be able to find optimal and practical solutions when they are required and are not premature even without doing leetcode.

You might get false positives as well. E.g. you get people who are tunnel visioned on leet code, cracking the coding interview and other common system design books, they know all the answers, but then they completely lack common sense day to day and it can be hard to test for that if you are solely focusing on leetcode.

Re: Coding interviews are stupid (ish)

#335

Post by surfingdino »

xandrius wrote: post #282
surfingdino wrote: post #77

I have 30+ years of experience on my CV and I still am being asked to do coding interviews... I flatly refuse every time, because they have no connection to the actual job. The hiring process disregards experience and treats everyone in the same way. Ours is a stupid industry.

What phrasing would you use to refuse? I'm curious :D

"I just don't do online coding exercises. They typically bear no relevance to the project and if you expect me to be solving basic problem in CS while being watched and judged in real time when I join then I don't think I want to join. Also, if you cannot judge my experience based on my CV then I don't think you know who you are looking for."

Re: Coding interviews are stupid (ish)

#336

Post by Paul-Craft »

paulddraper wrote: post #298
davidw wrote: post #296

Earlier quoted context omitted.

> Think about React. It's a JS framework, yet to invent it one needs to understand at least compiler and graph. Are you hiring people to create new JS frameworks, or to use an existing one?

To use an existing one. And tools are best used when they are understood.

I don't know anything about quantum mechanics. Does that mean I don't understand how computers work?

Re: Coding interviews are stupid (ish)

#337

Post by darrenkopp »

ok123456 wrote: post #52

I've found that asking them to review some obviously bad code with glaring errors and problems is more informative than asking them to solve some random DSA problem. Candidates who can code well can point out code that has obvious problems. Just ask if this is good or bad, and if it is bad, how they could improve it. This demonstrates competency and doesn't make the interview seem like a grind but instead more like a…

This is pretty interesting, I hadn't heard of this approach before. I'll have to give it a try some time.

Re: Coding interviews are stupid (ish)

#338

Post by Paul-Craft »

blindriver wrote: post #299
hintymad wrote: post #239

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…

> 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 there's any signal behind it anymore.

Where can I find the data on this?

Re: Coding interviews are stupid (ish)

#339

Post by godelski »

markwkw wrote: post #328
godelski wrote: post #310

Earlier quoted context omitted.

> if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. This is why I've always been so confused. Why is the software engineering interview wildly different from the traditional engineering interview (seniors sit down with candidates and discuss how to solve a relevant proxy problem the team is currently undergoing (has the side benefit…

Mechanical engineering interviews seem to do the same as software: "Engineers always ask about beam bending, stress strain curves, and conservation of work. Know the theory and any technical questions are easy." Basically an equivalent of simple algorithmic questions. Not "real" because it's impossible to share enough context of a real problem in an interview to make it practical. Short, testing principles, but most…

> Mechanical engineering interviews seem to do the same as software:

I've been an engineer in the past (physics undergrad -> aerospace job -> grad school/ml). I have never seen or heard of an engineer being expected to solve math equations on a whiteboard during an interview. It is expected that you already know these things. Honestly, it is expected that you have a reference to these equations and you'll have memorized what you do most.

As an example, I got a call when I was finishing my undergrad for a job from Raytheon. I was supposedly the only undergrad being interviewed but first interview was a phone interview. I got asked an optics question and I said to the interviewer "you mind if I grab my book? I have it right next to me and I bookmarked that equation thinking you might ask and I'm blanking on the coefficients (explain form of equation while opening book)". He was super cool with that and at the end of the interview said I was on his short list.

I see no problem with this method. We live in the age of the internet. You shouldn't be memorizing a bunch of stuff purposefully, you should be memorizing by accident (aka through routine usage). You should know the abstractions and core concepts but the details are not worth knowing off the top of your head (obviously you should have known at some point) unless you are actively using them.

Re: Coding interviews are stupid (ish)

#340

Post by darrenkopp »

majormajor wrote: post #211
ChrisMarshallNY wrote: post #144

This was an interesting observation: > What I do know, however, is that for every 1-hour interview where I evaluated if someone knew their data structures, I could have just taught them. I don't really hear much about training. I doubt it's because we don't do it, but maybe it's not an interesting topic for discussion.

Training and teaching is hard. "One hour of interviewing could be avoided with one hour of training" is wildly optimistic. It also ignores the breadth of knowledge you likely want a candidate to have (and are just trying to sample at through a short few interviews). How many hours of training are you willing to sign up for? How confident are you that the knowledge will "stick" for any given candidate? Are you going t…

I don't think it's wildly optimistic, but perhaps we are thinking about it in different ways. I don't think I could teach someone how to implement each data structure in an hour, but I could easily go over maps/queues/stacks/hashtables and tell you when to use each in an hour. I know this because I do that very thing in less than an hour in code reviews.

I do agree that the "stickiness" is iffy, but it usually sticks pretty well. You then have a second problem that can be described as "when you have a hammer, everything is a nail" as they use their new fancy hashtable everywhere.

Post reply on HN