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

161–170 of 391 posts

Re: In defense of coding interviews

#161

Post by em-bee »

RavingGoat wrote: post #28
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…

I've found that coding interviews just prove that you can write rushed, crappy code to solve a problem.

some people can't even do that.

Re: In defense of coding interviews

#162

Post by arethuza »

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.

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

Re: In defense of coding interviews

#163

Post by aulin »

leeoniya wrote: post #115
thaneross wrote: post #111

Earlier quoted context omitted.

Yes, a regular for loop is a bit faster at iterating over a large list of elements than foreach in Javascript, but why on earth would you care about that kind of optimization minutia in a coding interview? The question you're asking involves 10k * 3 * 30 = 900,000 data points. If a candidate wants to simply loop over all of them multiple times a second, I'd say that's a much bigger problem.

> If a candidate want to simply loop over all of them multiple times a second, I'd say that's a much bigger problem. unless the task is to animate them in a rAF loop (which runs at ~60Hz), right? the task matters. in some cases the question is stupid & irrelevant, and in the other case it means getting the job done, or not. the difference between the brain-dead way and the fast way is literally 30x (53ms vs 1.8ms on…

Not sure it proves anything in interview context though. It's a language specific trivia you'll quickly learn either from experience or from a good mentor. Proves nothing about your ability to code or to be a successful member in the team. Unless you're actively looking for a candidate that knows all those JS optimization tricks.

Re: In defense of coding interviews

#164

Post by ipaddr »

koonsolo wrote: post #150
pkolaczk wrote: post #127

Earlier quoted context omitted.

It's is also easy to bullshit a coding interview. The problems solved at interviews are just too small to verify code organization skills.

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?

Re: In defense of coding interviews

#165

Post by aulin »

zepolen wrote: post #157
drewrv wrote: post #133

Earlier quoted context omitted.

It’s unrealistic to expect this level of optimization in a generalist whiteboard session. For a specialist, maybe. I’m not specialized in this area. For an array of 5-10 items the performance hit of foreach is worth it for readability. Maybe an interesting discussion could occur about when to sacrifice readability for performance but you won’t get that by grilling people about minutiae.

> For an array of 5-10 items the performance hit of foreach is worth it for readability As always it depends, maybe that component is being called 500 times on the page making it actually 5,000 invocations. I'd FULLY expect a candidate to understand the difference and would ask in a whiteboard session. There is a lot of bloated slow javascript libraries out there and they almost always stem from the fact that most de…

one could argue that it's a job for the compiler to make sure two equivalent language constructs (map and for loop) perform similarly...

Re: In defense of coding interviews

#166

Post by ozim »

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…

Fun part is that it can work like ideal world when you have 1-2 devs per year to hire and as a small company you get 20-30 CVs a month.

Once you get into scale where you need to hire 20 devs a year and get 100s of CVs per week it all breaks down.

Re: In defense of coding interviews

#167

Post by ipaddr »

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.

It's about speed of solving medium leetcode not coding skills.

Re: In defense of coding interviews

#168

Post by Jensson »

amitport wrote: post #140
Jensson wrote: post #92

Earlier quoted context omitted.

A simple test: Do they hire like Google but manage their programmers like a sweatshop (ie Scrum)? Then they are just cargo culting. Companies like Google at least gives its engineers a lot of responsibility and freedom you'd never get in an Agile shop.

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 even to senior developers.

So to me the time I've spent working on Scrum projects feels like a sweatshop compared to how I could plan and structure development at Google. At Google I am free to collaborate with stakeholders, build prototypes and get feedback etc, as I see fit to complete the project. Or not do it when I don't feel it is needed, the important part isn't how I run the project but that I run it well. If you don't give your developers that level of autonomy then I'm not sure why you'd care much about developer competence at all. (I quit Google a few years ago though due to how the company was changing, but I'll never join a Scrum development team again)

Re: In defense of coding interviews

#169

Post by ipaddr »

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…

It's 10x the worst not average developer so it becomes 2x the average.

Besides a 10x developer cannot be uncovered through a leetcode test or a coding test. A 10x developer pushes back on requirements, bridges gaps.. identifies issues early.. it's about making things happen not typing faster or knowing the stack well

Re: In defense of coding interviews

#170

Post by freyr »

vorpalhex wrote: post #89
peterhunt wrote: post #82

Earlier quoted context omitted.

What’s the alternative?

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.

So instead of selecting people who can do algorithmic problem solving well (under pressure), you’re selecting people who can bullshit well (under pressure).

I’m not convinced it’s really an improvement. I’ve worked with too many people who are great bullshitters but terrible engineers, who sailed through on their charisma.

But that’s why most companies have a mix of technical and behavioral interviews.

Post reply on HN