Live data from Hacker News

Follow-up to “The dystopian world of software engineering interviews”

jarednelsen.dev

121–130 of 538 posts

Re: Follow-up to “The dystopian world of software engineering interviews”

#121

Is it really that rare that companies have legitimate hiring processes and realistic interviews? Take this with a grain of salt, because my experience may differ from many here (never worked at FAANG, I spent a lot of time at smaller startups in Boulder and am currently in Miami) but I have only been put in front of a whiteboard one time during many dozens of interviews and it was a generic logic puzzle to see how I…

Without necessarily accepting the premise of "legitimate and realistic", yes, in some markets it's very rare. I've personally never had an interview without a whiteboard problem.

Re: Follow-up to “The dystopian world of software engineering interviews”

#122

I got to the last thread too late for a comment to make a difference, but I'm exactly the person most of you want to talk to or hate. I'm an interviewer at a FAANG company with >500 interviews in the last 5 years, I teach multiple internal courses on interviewing, and I think the system makes a lot of sense for companies at our scale. Ask Me Anything :) I currently have a toddler on my lap, but I'll edit this post la…

Do you have a shortage of good candidates or not, wrt your company's staffing requirements ?

Re: Follow-up to “The dystopian world of software engineering interviews”

#124

There's significant ladder pulling. Tons of engineers work at places with interview processes they could never pass.

Also the closely related phenomenon of holding candidates unfamiliar with the codebase to the same standards as the interviewer, who wrote half of it.

Yea, if I had also been working on this particular code for the past two years I'd be able to breeze through these problems too.

Re: Follow-up to “The dystopian world of software engineering interviews”

#125

Earlier quoted context omitted.

It has been done, I've seen the numbers and they work. Other companies have probably done the same. Of course this isn't popular, instead people up-vote anecdotes from people who say that they once had an algorithm wiz who performed badly, or how some stellar performers were rejected by this kind of interview.

> Of course this isn't popular, instead people up-vote anecdotes from people who say that they once had an algorithm wiz who performed badly, or how some stellar performers were rejected by this kind of interview. That's kind of reductionist. I upvote answers that at least attempt to propose alternatives to the current status quo. The employer side isn't the only relevant one, which is likely a stronger reason why a…

Right, if you pay significantly less than top companies you probably don't want to filter using their metrics since then you will just get their leftovers. Instead you should try to find the good candidates they miss. However there is really no reason for top companies to change their interviews.

Re: Follow-up to “The dystopian world of software engineering interviews”

#126

Earlier quoted context omitted.

Okay, let's start with the obvious one-- why do you believe focusing on excruciatingly difficult algorithmic problems totally unrelated to the work you do is a good way of finding people?

Not OP, but it's often not about seeing you get a perfect solution straight away, they're judging your problem solving skills - how do you approach something you've probably never seen before. Do you choke? Do you break the problem up into smaller sub-problems?

People who say "oh, I just want to see how you approach the super-hard problem" are often the first to comment on threads like this, but the experiences of OP and others seem to indicate that most interviewers expect you to actually finish or GTFO.

Re: Follow-up to “The dystopian world of software engineering interviews”

#127

Earlier quoted context omitted.

In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can’t over allocate or reallocate an existing engineer for it. Like refactoring existing code. Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It’s a great way to get them familiar with the code base and train them up. I haven’t see…

How would a junior no what to refactor and not make it worse? In my experience it’s harder to refactor existing code than to start with green field development.

You give them tasks with frames of reference. Not all refactored are monsters. It does require some guidance though that’s kind of the point.

These are just some things I’ve been apart of. I’ve gladly been apart of this before.

You can as I said also have them write tests or as others noted have them write smaller features or other things in isolation.

Also how green are we talking is another question entirely. Some tasks are better fit for people with maybe practical experience in another tech stack but need to get up to speed in a new language etc.

My overall point which may not have been clear is that there is always a way to get an engineer up to speed without killing velocity. It’s a management failure to say you can’t hire junior engineers.

It’s one thing to need someone that’s a domain expert, but often I see “senior engineer” === “No ramp time” and I think that’s just a lie management tells themselves to justify not coming up with a good on-ramp plan for new engineers

Re: Follow-up to “The dystopian world of software engineering interviews”

#128
I don't know, hiring seems inherently broken.

Not just the algorithmic part, even the part leading up to it.

You have to impress a recruiter or an HR drone by listing all the buzzwords that are currently trendy.

Then, even after the algorithmic questions and interviews where you prove you can DO the job, you get rejected.

Every company I've worked for had trouble hiring.

I'm working for a company that also has trouble hiring right now. Last week, the person interviewing our latest candidate told me that despite the candidate doing perfectly fine, he couldn't come up with something that he felt excited about doing in his current job, which was a red flag for him.

I tried explaining that perhaps that's something you shouldn't expect from someone who's at that point switching jobs. We're still discussing how hard it is to find good people.

Most of the companies I've interviewed for also have trouble hiring, yet I've been rejected for the most asinine reasons. These companies have the same positions open years later and not due to growth.

All this rant is to say, we're mostly doing this to ourselves.

I don't have a better way of doing things, but I can't just blame a handful of big corps for this, as if their technical interviews weren't designed by technical folks themselves.

Re: Follow-up to “The dystopian world of software engineering interviews”

#129

Earlier quoted context omitted.

> Of course this isn't popular, instead people up-vote anecdotes from people who say that they once had an algorithm wiz who performed badly, or how some stellar performers were rejected by this kind of interview. That's kind of reductionist. I upvote answers that at least attempt to propose alternatives to the current status quo. The employer side isn't the only relevant one, which is likely a stronger reason why a…

Right, if you pay significantly less than top companies you probably don't want to filter using their metrics since then you will just get their leftovers. Instead you should try to find the good candidates they miss. However there is really no reason for top companies to change their interviews.

> Right, if you pay significantly less than top companies you probably don't want to filter using their metrics since then you will just get their leftovers.

Not sure where you read "less pay" into my comment but fine, let's go with that and just ignore that quite a few companies immitate FAANG style hiring these days.

> Instead you should try to find the good candidates they miss. However there is really no reason for top companies to change their interviews.

Yeah, I feel like we're arguing two completely different things here, there's plenty of reasons for companies to change processes even if they work on some metric. When a large number of experienced participants in the fields you are hiring for are offering critique on your process it should be at least reason enough to talk about it, which is the whole point of discussions like these.

Re: Follow-up to “The dystopian world of software engineering interviews”

#130

Earlier quoted context omitted.

I'm actually rather unconvinced that these interviews are positively good at minimizing risk (false positives). This whole 'whiteboarding' thing has degenerated into 100% pointless trivia, with many elements of a popularity contest - I just don't see any reason why we should trust this to yield 'safe' candidates. Even sticking to the pure 'trivia' aspect, there's just so much of it that people are missing altogether.…

> This whole 'whiteboarding' thing has degenerated into 100% pointless trivia, with many elements of a popularity contest - I just don't see any reason why we should trust this to yield 'safe' candidates. People blindly and dumbly implementing any practice is going to yield bad results. I've interviewed for Google, for a small company with a crappy pipeline and a low need for talent, and for my current job, which nee…

> I also rejected a candidate on the basis of failing the simple whiteboard problems

OK, but this topic is not about "simple" whiteboard problems. (People can of course disagree wrt. what's 'simple', but a rule of thumb is that anything where the average dev would need to train and memorize whiteboard trivia for an extended period in order to perform satisfactorily is far from simple.)

Post reply on HN