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

151–160 of 391 posts

Re: In defense of coding interviews

#151

Post by hiyer »

andreygrehov wrote: post #36

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me. Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicate…

> what's more important is how dedicated you are when it comes to reaching a goal.

That may sound good in theory, but in practice I've been rejected quite a few times for not delivering the correct or most optimal solution despite trying my best.

Re: In defense of coding interviews

#152

Post by sailingparrot »

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.

Except for the fact that using foreach instead of for has no impact on your O(n) performance.

Re: In defense of coding interviews

#153

Post by implmentor »

koonsolo wrote: post #134
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…

I do a lot of interviews with potential candidates, and worked with plenty of those we hired (and unfortunately some we fired afterwards). If you have a better way on how to assess a software developer, I would love to hear it.

Not OP, but I would love to share some: I relate strongly to the anxiety induced descriptions in OPs text and thus try to avoid these when I interview devs as an engineering manager. Of all the candidates I have interviewed over the years I have never done a live coding interview because it is essentially worthless for me as an interviewer and only serves to discards potentially very clever people whose thought process does not work this way.

Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time, so I can review what kind of solution they will actually deliver once hired. We then go through the solution with them and do a code review as they would go through if they got hired. You then see both the problem-solving skills as well as how they take feedback.

I would recommend checking out DuckDuckGo's excellent "How we hire" guide[0] which describes some of the best hiring process I have come across (albeit it may be too extensive to do in full for some companies).

[0] https://duckduckgo.com/assets/hiring/how_we_hire.pdf

Re: In defense of coding interviews

#154

Post by onion2k »

leeoniya wrote: post #132
onion2k wrote: post #126

Earlier quoted context omitted.

If someone suggested that I ought to be able to solve a problem like that in an interview, rather than solving it over the course of several years with a team of developers (like Grafana did) then I'd stop the interview and remove myself from the hiring process. No doubt there are situations where hugely optimized code is necessary. An interview isn't one of them unless you're hiring someone to write exactly that cod…

> No doubt there are situations where hugely optimized code is necessary. An interview isn't one of them unless you're hiring someone to write exactly that code. Most companies aren't. knowing the difference, and consciously deciding that it doesn't matter for a given task is often a strong positive signal. hopefully a good interviewer will not actually ask you this question if it doesnt matter for the given task.

I don't agree. If someone brought that up in an interview I'd just think "oh, they know a bit of JS trivia that won't impact any of the code they'd write here." and ignore it. It's not a signal at all, let alone a strong one.

If they mentioned the fact that React 18 batches updates in concurrent mode which would greatly improve the responsiveness of a dashboard app that's updating lots of small components frequently, or if they suggested the graphs might be better written using GLSL shaders to move the rendering to the GPU so JS only needs to update a uniform array, then I'd pay attention. Potential new ways to approach a problem or changes to architecture to avoid the problem entirely rather than micro-optimizations are much more interesting signals about someone's deeper knowledge of building things.

Re: In defense of coding interviews

#156

Post by hawaiianbrah »

amitport wrote: post #145

The real reason there are these coding things: A) SWEs are shit behavioral interviewers in any other way. You are not about to chnage that even if you are google. B) It is crucial that newcomers be hired by their peers and by their direct manager. This has solid research. People hate it when they get an hire and they hadn't a meaningful part in the decision... The new hire is more likely to fail. A+B means it is bett…

Mind sharing the solid researching on that hiring by the team comment? My company is switching to pooled hiring and it irks me, so I’d love to read up…

Re: In defense of coding interviews

#157

Post by zepolen »

drewrv wrote: post #133
leeoniya wrote: post #115

Earlier quoted context omitted.

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

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 devs don't realize how much overhead function calls introduce.

For the interview, there is no discussion necessary, the correct answer is simply:

"I used a foreach for readability, because performance doesn't matter in this case because X."

or

"I used a for because performance matters in this case because Y"

End of story.

Re: In defense of coding interviews

#159

Post by em-bee »

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…

i do sort of pair programming with candidates specifically to evaluate the interaction. i let them drive and navigate, acting more like a passenger with the occasional input. that way i can see coding skills and ability to communicate.

of course i interview for my specific situation. the candidate will be working with me directly, so they should at least be able to interact with me. if i don't like them then that's almost a showstopper, but if the candidate otherwise qualifies i should try to figure out what my problem is, and see if i can get over it.

Re: In defense of coding interviews

#160

Post by vletal »

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…

I've just interviewed for Google and Meta. In total I went through 8 individual coding interviews.

With an exception of one, which was a bit too much like a puzzle, I think the assignments were completely fair examples of what I might experience on daily basis. Not at all tailored to people doing competition style programming, which was what I expected after being exposed to HN for years.

I have to say I enjoyed both preparing for the interview as well as the interviews themselves. And I believe that overall the interviewers were able to grasp how I would code.

Post reply on HN