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

71–80 of 391 posts

Re: In defense of coding interviews

#71

Post by makeitdouble »

zach_garwood wrote: post #35
ma2rten wrote: post #20

Earlier quoted context omitted.

But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.

Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.

They are out there, but usually in a 3~4 step process they get filtered out before the coding interview.

I did a bunch of really quick 15~20 min pre-interviews to check if the person was entering the right process before we both wasted hours of our time. Some who were supposed to have coded and deployed whole applications didn’t know how their versioning system worked. Or they reviewed PR/MRs a lot and tweaked a few lines here and there but had little practical knowledge of issues you’d regularly hit when developing, and only heard of popular tools and resources by name.

We could still had them onboard and give them time to get up to speed, but it’s harder to do when they weren’t upfront about it and you’re there trying to guess what else they’re bulshitting on their resume.

Re: In defense of coding interviews

#72

Post by weatherlite »

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 an offer without being able to solve (unless it's some kind of a diversity hire).

Re: In defense of coding interviews

#73

Post by jsnk »

angarg12 wrote: post #29

Before we criticize the current interview format and propose alternatives, we need to understand how we got here first. This is my understanding of what happened (I wasn't there for most of this!). Leetcode-style interviews became popular in the mid 00s, primarily because they were used by hot tech companies of the time. The thing to understand is that at that time, the idea of asking people to write code during an i…

This is probably the best take in the entire comment section.

I see whole bunch of people complaining about Leetcode (LC) style coding questions, but I don't really see any alternative that is as good as LC. LC interviews solve all the following criteria better than other interview formats in aggregate.

- Objectivity: can you evaluate candidates as objectively as possible as opposed to subjectivity?

- Scalability: can you evaluate many candidates fast with high throughput?

- Accuracy: can you filter out bad candidates? Yes, the filter is often restrictive to the point where good candidates also get filtered out unfortunately.

- Meritocratic: can you make sure the process is assessed based on the merit of solving LC questions well as opposed to having connection to someone you know at the company or having gone to some prestigious school or other companies?

Leetcode format does good in all criteria above, or at least better than other formats below in aggregate.

1. Take home assignments.

- Objectivity: bad

- Scalability: bad. Once the question leaks, it's harder to come up with another question easily. Also doesn't scale for candidate side either. As a rule of thumb, I always decline interviews that require take home because it's useless to try hard as this is not applicable to interview at other companies. ROI is extremely low for candidates.

- Accuracy: good.

- Meritocratic: good

2. Coding questions with heavy emphasis on practicality (Stripe & Square)

I was pretty impressed with questions from Stripe and Square. They created problems that are heavily related to string, array, hashmap manipulation, searching, replacing etc using regex and such. If you are not into LC questions, you might prefer this, but I actually found some of these questions harder than dynamic programming questions I got from Google.

- Objectivity: good

- Scalability: bad. Once the question leaks, it's harder to come up with another question easily.

- Accuracy: good.

- Meritocratic: good

3. Knowledge / Trivia questions about programming language or framework

This might make sense a bit if you are specifically looking for iOS, Android or web developer but it still will need to be paired with LC questions.

- Objectivity: good

- Scalability: good

- Accuracy: bad. Candidates can memorize and recite these answers to the questions. Also too many good candidates actually do not memorize the details about programming language or framework. Also it can easily obtained from just Googling so people can cheat easily.

- Meritocratic: good

4. Pure behavioral

- Objectivity: bad

- Scalability: good

- Accuracy: bad

- Meritocratic: bad

5. Ex-coworker

- Objectivity: bad

- Scalability: bad

- Accuracy: good. If you've worked with the candidate before, you'll have a pretty good grasp of whether or not he/she can do the job well.

- Meritocratic: bad

Re: In defense of coding interviews

#74

Post by d--b »

t-writescode wrote: post #66
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…

Statements like this make me distinctly angry because I do everything I can to remove myself from the interview, of sorts. If they come up with, or start walking with an interesting solution, I listen to them. Tabs and spaces don't matter. I actively work against the biases of "whether I like the person or not" because I'm aware of that as a factor. We can absolutely minimize all of those peripherals when we explicit…

Well I didn’t mean to offend anyone. I guess that just makes you a better technical interviewer than most.

But to be perfectly unbiased, the process would have to double blind. And I don’t know anyone who likes to hire people (or anyone who wants to be hired) following a double blind process.

So at least there is _some_ non-technical bias that gets in the process.

Re: In defense of coding interviews

#75

Post by nogridbag »

Apocryphon wrote: post #11
drewrv wrote: post #6

It is nice to hear a defense of this style since there’s often so much complaining about it, and the tips to mitigate the downsides are useful. Personally I don’t mind a whiteboard session or two during a loop but what’s wild to me is how, especially at big companies, you’re expected to do four or five of these to get an offer. How often do these companies decide “well they understand when to use DFS and they can mer…

The problem is that these problems are not even whiteboard problems anymore. They’re often strictly timed coding exercises on Coderpad or Karat with actual mock IDEs and REPLs expecting running code under strict expectations. The more casual, flexible, subjective coding interview described by the OP is not the prevalent form of whiteboarding interviews, which has been superseded by the weeder version.

Do you have any suggestions for a simple online coding portal? I know some companies have used a simple Google Doc for this reason, but that seems far from ideal.

Re: In defense of coding interviews

#76

Post by jfoutz »

I've been asked to interview. I'm not a great interviewer, but maybe OK. I try to figure out if they can work the tools. I'm pretty lax - interviews are stressful and missing a comma can take a minute, I don't like people twisting in the wind over a syntax error and will point it out if I'm pretty sure they'd get there. I try to decide if I can work with this person. I try to figure out if they'd be ok with how things work at my current employer.

I have two very memorable no's. They were for pretty senior/advanced IC roles. Juniors would get far more slack. I usually ask an expression evaluator question.

One person, used eval(string). Brilliant, absolutely brilliant. full points for answering, but how do we make sure the string is safe to eval? Long frustrating discussion around regexes that that maybe a junior dev is responsible for maintaining. Man, just write the parser. I know you can do it. Give me something that's something that's not _crazy_ to put into prod. Give me something that won't be a bug tarpit. Sorry man, I loved your answer. I hated your response to how this can be operationalized. Clearly super smart. Maybe I should have given the green light, but the response to criticism was so bad. There are lots of people I disagree with, that I'm happy to work with. I think I made the right choice, but I wonder from time to time.

Another person I absolutely would have loved to work with, and would have learned a ton. Very into formal methods, or slightly relaxed versions of verifying reliability. My organization at the time was pretty fast and loose. I believed they would be miserable. In the interview I told them I'd give them the green light, but they'd have a huge uphill battle.

it's so hard to tell. People are adaptable, small mismatches can be papered over, but big mismatches - it's so tough to say. Relaxing and being vulnerable on both sides is so hard to do well. Maybe I was just a jerk. I think I made the right calls, but it haunts me.

Re: In defense of coding interviews

#77

Post by inlined »

zach_garwood wrote: post #35
ma2rten wrote: post #20

Earlier quoted context omitted.

But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.

Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.

I interviewed a while ago at a well rated (but not MANGA) company. I was livid when the interviewer decided to move to an easier question and was skeptical when I “solved” in-order traversal of a binary tree without thinking. “Oh, you’ve seen this problem before?” “Yeah; a few weeks into college…”

I’m a staff engineer and tech lead at a MANGA company. I code in up to 5 languages a day. I’ve written Network stacks, compression software, virtualization software, and the backbone of multiple PaaS platforms. And they were focused on whether I knew niche algorithms (apparently based on EXT3) and other stupid stuff.

Re: In defense of coding interviews

#78

Post by weatherlite »

adam_arthur wrote: post #2

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody with strong theoretical foundations, while most are well served by somebody who can pump out high quality code quickly. Yet most companies interview as if they are inventing novel storage/processing mechanisms. Theory is important to understand which tools to le…

This. I don't get why it's so hard to create this type of interviews...

Re: In defense of coding interviews

#79

Post by quacker »

vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

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 shitty leetcode questions and the interviewers are hostile or hung up on unimportant details - move on to another company.

Re: In defense of coding interviews

#80

Post by Apocryphon »

quacker wrote: post #79
vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

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.
Post reply on HN