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

291–300 of 391 posts

Re: In defense of coding interviews

#291

Post by dagmx »

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.

It's not a boolean can/cannot code. It's a cannot code at the level expected of the seniority.

I interview tons of software engineering candidates (pre pandemic it was at least one or two a week). At least half of my senior candidates fail basic phone screener questions.

These are questions that reflect something they'd be doing day to day in the role, but also are incredibly standard in our field.

The issue in most of them is that they've taken their support network for granted. The tons of developers before them who laid groundwork, and the others currently who take care of many tasks they consider junior.

Well that leaves them in a weird spot where they've not actually done a lot of the foundational work their predecessors set up for them, and they've let a lot of their skills atrophy by delegating to juniors. They'll even say as much and say "oh so and so does that, or they had it set up and it's great"

But then what am I hiring them for? Certainly they're not bringing a wealth of programming ability over, so maybe soft skills? That's hard to hedge bets on for a SWE, maybe as an product manager or something.

Re: In defense of coding interviews

#292

Post by ThrowawayR2 »

zach_garwood wrote: post #245
ThrowawayR2 wrote: post #53

Earlier quoted context omitted.

I have. Supposedly an experienced fellow but put out code that would embarrass an intern (and a bad intern at that).

So, they could code, just not up to your standard.

The resulting code didn't build either so, no.

Re: In defense of coding interviews

#293

Post by prakhar897 »

sitkack wrote: post #109
weatherlite wrote: post #72

Earlier quoted context omitted.

> 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 ar…

> 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.

Because you asked them question out of syllabus. Was the person informed that the interview wouldn't involve Leetcode?

The person spent months prepping Leetcode just to get into BigTech and then you come out of woodwork with your "special" interviewing material. Imagine prepping for a calculus test for months and then the teacher comes out and takes a "simple" test on trignometry. Would you be able to do it? Not only that, all his/her friends got a normal calculus test which they passed with flying colors.

Re: In defense of coding interviews

#294

Post by lapcat »

kansface wrote: post #281
lapcat wrote: post #254

Earlier quoted context omitted.

> But firing is always such a big decision. Isn't that why managers get paid the big dollars, to make the big decisions? The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.

Have you ever worked with a really bad hire? Someone totally incompetent at doing the job? In my personal experience, that person completely tanks the productivity and moral of the entire team. I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Bad hires are disastrous.

> In my personal experience, that person completely tanks the productivity and moral of the entire team.

A bad manager completely tanks the productivity and morale of the entire team too. And you can't fire your boss, you can only quit your job.

> I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that).

Not sure how it's relevant whether you're doing the incompetent person a favor or not? Hiring isn't about favors, it's an exchange of money for work. If there's no useful work, then the money has to stop.

> Bad hires are disastrous.

Seems a bit overstated to me. Do you have any examples of companies put out of business by a bad programmer hire?

Coders come and go. Is it a "disaster" if your best coder leaves for another job? We're treating hiring as if it were like marriage and divorce, but it's not. When you hire someone, it's not "til death do us part". Breakups are expected.

Too many companies make hiring much more difficult than it needs to be. They overthink it, and also waste way too much time on it. Find someone who seems right for the job, and hire them. If they don't work out, get rid of them and hire someone else. You might get unlucky at times with a bad hire, but you might also get lucky with an unexpectedly great hire. If you can't correct your mistakes quickly, that's a problem with your company's culture, not a problem with job candidates. I would argue that it's not a bad hire that demoralizes a team but rather a bad company culture that's incapable of correcting mistakes.

Re: In defense of coding interviews

#295

Post by dlkf »

BlargMcLarg wrote: post #286
dlkf wrote: post #282

Earlier quoted context omitted.

> For such a bold claim, one would expect evidence to be readily available. The only way to provide this evidence would be to to conduct an RCT in which you hire some percentage of people who fail the test as a control group. The nascent psychologist in me loves this idea, but it seems unethical, and presumably this is why nobody does it. But I disagree that we need ”evidence.” It’s flat out obvious. If you give your…

>If you give your job candidates a discrete math problem orders more difficult than the usual ticket, you minimize the risk of hiring someone who can’t do the job. You're also maximizing the odds they will get bored and feel baited. With all due respect, you could have picked a better example to illustrate your point. This is exactly why you can't make such bold claims. You're looking at this from one perspective wit…

> You're also maximizing the odds they will get bored and feel baited.

I like this point. This is an especially big problem in my area (data science), in which people think they are being hired to do deep representation learning, and are subsequently mortified to learn that the job is principally about transpiling ”product manager” to ”SQL”. The cure is to be up front with job candidates. Tell them the job involves no deep learning. Explain that you give hard interview problems because you need to know that they can reason about eg asymptotic complexity on the rare times where it arises.

> So far, the best correlator to job performance is giving people work corresponding to what they will be doing at the work place.

I don’t necessarily disagree, but I believe you want to optimize for the hardest day rather than the average day. If your team is optimized for who can best solve an average problem, you will eventually have a problem that nobody can solve, and the business will suffer greatly as a result. Hence the discrete math problems.

Re: In defense of coding interviews

#297

Post by [deleted] »

arethuza wrote: post #162
vkou wrote: post #144

Earlier quoted context omitted.

If you can't give me the o(n) performance of the algorithm that you just wrote, this is a pretty serious red flag about your ability to understand what you are writing.

What would you do if a candidate said with a smile "I'm pretty sure it is O(n!)"?

[deleted]

Re: In defense of coding interviews

#298

Post by lapcat »

dlkf wrote: post #287
fumeux_fume wrote: post #280

Earlier quoted context omitted.

Maybe you're the enlightened one here or maybe you're just rationalizing an awful and lazy part of the hiring process for many companies.

If anyone actually believed this they wouldn’t complain about it on HackerNews. If it were true that Google, Microsoft, Apple, etc don’t know how to hire programmers effectively, this would be an incredibly powerful observation which you would want to keep top secret while silently beating the hiring market and building the most successful tech company of all time. We’re all waiting. The reason people are upset by th…

> If it were true that Google, Microsoft, Apple, etc don’t know how to hire programmers effectively, this would be an incredibly powerful observation which you would want to keep top secret while silently beating the hiring market and building the most successful tech company of all time.

Well, I'd like to have a word with the Apple Mac Mail app team. And the Disk Utility team. And some others...

Re: In defense of coding interviews

#299

Post by leeoniya »

light_hue_1 wrote: post #267
leeoniya wrote: post #81

Earlier quoted context omitted.

> This ridiculously untrue. at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes. i profile and optimize a lot of JS/TS code that handles datasets with millions of datapoints at my day job. but you don't need to take my word for it; this claim is not exactly difficult to verify. > Do you just play along or begin to explain how incredibly wrong they are? in this case, i…

> at least for JS VMs, this is true today. this answer will certainly vary for other languages/runtimes. Total nonsense. It is not true of JS today, not has it ever been true. No modern web app's or website's performance is dominated by the performance of what loops you choose. It isn't even remotely meaningfully impacted by that; by this I mean, any differences are totally unmeasurable beyond some 3 line micro-bench…

No post body was provided.

Re: In defense of coding interviews

#300

Post by gunfighthacksaw »

manuelabeledo wrote: post #221
gunfighthacksaw wrote: post #10

Perhaps I’m biased as someone with a better than average sense of algorithms and discrete math, but I think such interview questions have a lot of utility, provided the job will require some analysis of algorithms, eg you’re working on the platform, or a solver/optimizer. Obviously it’s pants on head stupid to do that if you want a web dev to make a pretty app, tie frameworks together and liaise with 3rd party integr…

> However, I think many employers want the crème of such devs who are also good at algos. Which is not going to work for the vast majority of devs and jobs. Most devs either don’t care or need to care about algorithms, and the few devs who do, spend most days not using them. This would be akin to asking a civil engineer to build a wooden road bridge. Having the skills is great, but how often is the company going to n…

I am not a civil engineer, but I can imagine a situation where a wooden bridge could be used as a stopgap to pull off a more tricky construction.

Maybe not in the 21st century however, and I don’t think your analogy is perfect.

It might be more like wanting to hire an architect who is also great at civil eng. The skills definitely synergize and can help prune the architect’s search space of good designs, but such a candidate is probably just going to go for an engi job, and lean on their architecture skills there: for example an algo dev that can do mock-ups.

Post reply on HN