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

In defense of coding interviews

biggestfish.substack.com

Post reply on HN
Print view View original

101–110 of 391 posts

Re: In defense of coding interviews

#101

Post by quacker »

Apocryphon wrote: post #80
quacker wrote: post #79

Earlier quoted context omitted.

One thing to realize is that interviews are a two-way street. Do you think you want to work with the interviewers? Do you like the interview process? If the interview process is poor, what other kind of hiring decisions is the company making? Are you going to want to work with the people they end up hiring? You learn a bit about the company during the interview, and if that bit is bad, then move on. If they ask shitt…

The problem is when a significant number of companies all cargo cult the same process- that way you can’t even write them off as a one-off bad place.

Do they cargo cult the same process? I do see similarities in the interview process, so maybe that's somewhat true, but in my experience there's a ton of variety. Different companies have different formats, different questions, focus on different aspects of my responses, and I'm sure make hiring decisions wildly differently.

Some places have phone screens, and some don't. One company gave an easy leetcode problem as part of the phone screen, while in another case, one person actually spoke characters over the phone to me ("LinkedList", "left angle bracket", "String", "right angle bracket"). Some give take home questions. Some do a code review interview. Some dig into my resume during an interview, and some don't. Some companies had multiple interview sessions where I was asked the same question about my resume in each session by different people (wasting time). And so on.

So in general, I can and have passed over companies based on their hiring process.

Re: In defense of coding interviews

#102

Post by leeoniya »

vorpalhex wrote: post #97
leeoniya wrote: post #58

Earlier quoted context omitted.

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's not an absurd ask. perf characteristics of different iteration styles are often significant to the task at hand.

Your problem has gone off the rails if that level of performance difference is important.

try rendering a dynamic React dashboard with 30 line, scatter, and heatmap charts, each containing 3 series of 10k points each, several times per second. welcome to what Grafana can do :)

Re: In defense of coding interviews

#103

Post by vorpalhex »

bryanrasmussen wrote: post #99
vorpalhex wrote: post #86

Earlier quoted context omitted.

You can still write off cargo-culting companies who cargo-cult bad processes off. I give you permission.

Every company cargo-cults or should we say - follows best practices or industry wide processes - in something. No company has thought through every little bit of their system and processes because no company has the time to be completely original, just like no human idea only has ideas that they thought up themselves instead of borrowing a bunch of ideas from school, books, and overheard conversation because they sou…

It is better to not know and explore than adopt a bad process because you overheard it in a coffee shop.

It's ok to not have an answer.

Re: In defense of coding interviews

#104

Post by ankurdhama »

Programming interviews are really important but the questions should not be those about tricky data structure or based on obsecure mathematical trick. IMO the question should be presented in terms of real world concepts so that the candidate can be tested on what data structure they use to model the data related to the problem statement and the problem statement should be simple enough that you can easily come up with a very high level approach yet the implementation would require understadning concepts of conditionals/iteration/recursion. And you should also check how the candidate break the problem into smaller problems (instead of writing a single big function)

Re: In defense of coding interviews

#105

Post by Jensson »

nowherebeen wrote: post #38
andreygrehov wrote: post #23

Earlier quoted context omitted.

If I'm not mistaken, Google has a paper on this, in which there is a statistical confirmation of coding interviews being a predictor of success.

3 problems I can see with this a) Its like saying a Tobacco company has a paper saying smoking is healthy b) Google measures things that matter to them. The operate on a scale that 99% of companies aren't. Their predictor of success only applies to companies of their scale. c) What is their definition of success? And how does it apply to smaller companies less than 1000 employees?

Google isn't selling its interview process. The one who is hurt if it doesn't work is Google itself, they have no reason to lie to themselves here. And I really doubt that someone tricked Larry Page into adopting this with faulty statistics, he cared so much about hiring that he personally reviewed every single hire until the company grew to over ten thousand employees. The hiring process changed many times over the years, and what Google runs now is what they ended up with.

Re: In defense of coding interviews

#106

Post by vorpalhex »

peterhunt wrote: post #93
vorpalhex wrote: post #89

Earlier quoted context omitted.

You can just ask them to talk about code. You can ask them to compare and contrast some frameworks or languages of their choosing. You can ask them to do design tasks, or just talk about the work the company does and let them ask questions. One of the things I like to do, especially when a candidate is super anxious, is just ask them to talk about a recent project they've done that they like and why they like it.

Isn’t that going to result in a highly biased interview process? I suspect extroverts will do disproportionately better than introverts, and those who are comfortable in technologies the interviewer is not will do worse than those who share a similar technical background. I also think the skill cap on this sort of question is super low. (I’d put design questions in a different category though)

What process do you think introverts are going to have an equal footing at that isn't take home homework?

And yes, people who know technology will do better.. in a technology interview. I suppose I could ask about gardening but that doesn't help much does it?

Re: In defense of coding interviews

#107

Post by Cd00d »

andreygrehov wrote: post #36

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…

So, they're actually testing to see if you have commitments outside of work.

"Great" filtering for parents or people caring for ailing family or any other non-work commitment.

I guess it's not ageism at all, right?

Re: In defense of coding interviews

#108

Post by rektide »

qz_kb wrote: post #60
andreygrehov wrote: post #36

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…

How dedicated you are to do a task with no intrinsic value besides getting hired at companies with leetcode-style interviews. I don't think google is better off when everyone they hire has wasted hundreds of hours on a fundamentally useless skill rather than having used that time to learn different skills or just enjoy time with family and minimize the chance they burn out on the job at a later date. There's other wa…

Yes, leetcode skills don't help every day. But I definitely enjoy & respect more fellow coders who have computational thinking skills, who can break down problems, who understand costs.

That this isn't the bulk of what we do doesn't change the fact that these challenges do test computational thinking acuity. Having the ability to see & speak computationally is a good skill, one that connects our day-to-day abstract practice with actual real processes. Being able to break down problems & analyze how to tackle them shows an objective ability to assess & work through problems. I want to work with people who can be clear, who can model & explain & step through situations.

And these skills are, generally, learnable, and relatively quickly. I disagree that these abilities fade, but yes, some re-familiarizing & re-training is probably important, especially because, as you point out, the sample size is indeed often N=1, and that's pretty wild.

Re: In defense of coding interviews

#109

Post by sitkack »

weatherlite wrote: post #72
d--b wrote: post #56

The dirty secret is that it’s never about the coding skills. It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not. And I think it’s fine. You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. What really mat…

> It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not Not in FAANG or famous startups it's not. You're either gonna solve 3-6 medium hard Leetcode questions perfectly or you're out. Sure, liking you will help you better not come off as a douche - but you're not gonna get a…

Interview technical folks at a FAANG and I don't asking leetcode questions. It isn't a SWE role but people should be SWE material. I do ask them to

    * read code
    * extend some working code with a new feature
    * parse some semi-structured text into a data structure
Programming interviews suck for everyone, even the interviewer. I feel absolutely horrible when someone locks up, or fails really hard. The questions I ask aren't hard but half don't pass.

What folks should do is practice coding in front of someone. Writing little exploratory snippets and understand the base library of the language they claim to know. I don't even ask people to vocalize while they are working on the problem. And I solve it at the same time they are and if they get stuck, I show them some of my code.

I had one person start crying they put so much pressure on themselves, I had to take a two week break from interviewing after that.

Re: In defense of coding interviews

#110

Post by rvz »

nowherebeen wrote: post #38
andreygrehov wrote: post #23

Earlier quoted context omitted.

If I'm not mistaken, Google has a paper on this, in which there is a statistical confirmation of coding interviews being a predictor of success.

3 problems I can see with this a) Its like saying a Tobacco company has a paper saying smoking is healthy b) Google measures things that matter to them. The operate on a scale that 99% of companies aren't. Their predictor of success only applies to companies of their scale. c) What is their definition of success? And how does it apply to smaller companies less than 1000 employees?

Precisely. Especially with (b) and (c)

What works for Google does not mean it will also work for the 99% of companies that are NOT Google or any other FAANMG company.

This only shows that we have an incessant coding interview cargo-cult around how FAANMG companies interview candidates and several startups taking that to the extreme and thinking they are working on complex Google scale problems.

To these interviewers at these startups still under this delusion and for the 900th time as many have previously said for years as a wake up call:

You are NOT Google.

Post reply on HN