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

171–180 of 391 posts

Re: In defense of coding interviews

#171

Post by aulin »

1270018080 wrote: post #85
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…

> The dirty secret is that it’s never about the coding skills. If you don't answer the 2 leetcode mediums in optimal complexity within 45 minutes then you don't pass. It's about coding skills.

leetcode is not coding

Re: In defense of coding interviews

#172

Post by arethuza »

adam_arthur wrote: post #9
xkqd wrote: post #7

Earlier quoted context omitted.

Not for nothing but we have plenty of slow coders that are “low volume” but some of the most diligent and edge case counting engineer’s I’ve ever met. Even then, if the business doesn’t depend on everyone working like a banshee, my team may as well take their time. Even as their manager it’s not my job to lead a death march.

Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on com…

"have an endless bucket of work"

A long time ago I managed a developer who was a genius at finding and fixing bugs - so I thought I would reward him by writing a new module we needed from scratch. He could not do it - when faced with a complex mess of existing code he was perfectly happy and could dive in and fix stuff, faced with a blank sheet of paper he froze and didn't know where to start.

Developers are people and all people are different - we all have our strengths and weaknesses.

Re: In defense of coding interviews

#173

Post by ownagefool »

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…

The false negative is the obvious downside of the coding interview, but I wouldn't say that it means there's no merit to the excercise.

Take for example the "can't define an array" crowd. Are there people virtually sitting in front of me who just forget the basic syntax? Absolutly, but given we a) tell them that correct syntax isn't dreafully important, and b) let them pick the language, a [] would probably suffice, I don't think it's a completely unreasonble ask.

Moreso, when we added a prestep of basic questions that one can google, the "can't define an array" crowd mostly disappeared. Sure, there may be some other causation there, but it's hard to hire a coder that you know, can't demonstrate coding.

Finally, anecdata, since we started coding interviews, the quality of developer is simply better. We have had internal debates about this, but the truth is, everyone is overall happier with what we're doing, and I'm a lot happier that false positives are way down.

I'm sure there's other ways of course. :)

Re: In defense of coding interviews

#174

Post by krainboltgreene »

vkou wrote: post #144
vorpalhex wrote: post #97

Earlier quoted context omitted.

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

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.

I'm going to blow your mind but a ton of important software was written by people who have a hard time explaining these things.

Re: In defense of coding interviews

#175

Post by Izkata »

inlined wrote: post #77
zach_garwood wrote: post #35

Earlier quoted context omitted.

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, co…

> a MANGA company

That's a new one to me, what's it made of?

(All that's coming to mind is I presume totally unrelated: https://en.wikipedia.org/wiki/Manga )

Re: In defense of coding interviews

#177

Post by Jensson »

nowherebeen wrote: post #120
Jensson wrote: post #105

Earlier quoted context omitted.

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…

Reread a) and b) from another perspective because never did I say they were lying to themselves.

I agree with b) and c). A is a bit forced though as tobacco companies faked studies to show that what they sell is healthy even though they knew it was horribly bad for you, I don't see how Google is anything like that with respect to hiring processes. If they talked about ads or search then the likeness would make sense, but I don't see it for hiring.

But I agree that Google is different than most companies. There the main thing is ads and search and infrastructure to run both of those. They can always use more developers to help optimize the profits of those algorithms or reduce runtime costs, the ROI on that is extremely high so that is what their hiring process is optimized for. Some of their other projects might have done better with a different process, but they don't have much weight compared to the revenue generating projects.

Re: In defense of coding interviews

#178

Post by ipaddr »

ta988 wrote: post #55
jackblemming wrote: post #41

Earlier quoted context omitted.

Maybe I’d prefer to not dance like a monkey for employment.

Some people are ready to trade dancing for a lot of money and a resume that will open them the doors of where you really want to be.

Are they the people you want to hire?

Re: In defense of coding interviews

#179

Post by amitport »

Jensson wrote: post #168
amitport wrote: post #140

Earlier quoted context omitted.

a) plenty of agile shops give you more freedom than Google does. Following Agile methodology really doesn't mean what you think it means; and b) please don't casually "ie sweatshops" when talking about something that is clearly not that.

Do your developers have to work in 2 week sprints and forced to work on tasks split into sub 1-day part so they never have any real autonomy? Then you aren't giving your developers more freedom than Google. And if you aren't working like that then you aren't doing Scrum. Google gives even junior developers multi month projects to own, manage and complete. No Scrum shop gives developers that level of autonomy, not eve…

"And if you aren't working like that then you aren't doing Scrum"

I kindly disagree. You seem to have worked at a very stressfull place. In my experience that has nothing to do with it being "true scrum TM" or not. In any case, happy for you that you got out.

Re: In defense of coding interviews

#180

Post by koonsolo »

ipaddr wrote: post #164
koonsolo wrote: post #150

Earlier quoted context omitted.

I suppose you never did any interviews yourself. You can't imagine how many people can't even do or know the basics.

Yet they are able to do the job. Something doesn't lineup with your testing methods vs outcome. If these people are finding work elsewhere and doing productive work for years what does it say about your process?

Do you think they are looking for a job because they were fired somewhere else?

Or do you think companies never fire people?

We already fired plenty of people that we hired. So yes, our hiring process is not perfect. But if you're a JavaScript developer and can't explain the difference between var, let and const, I'm not going to hire you. If you claim these people are great developers, you are free to hire them.

Let me know the details of your company. Whenever we find a candidate that doesn't satisfy our requirements (which is around 90% of them), I'll send them to you so you can hire them.

Post reply on HN