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

131–140 of 391 posts

Re: In defense of coding interviews

#131

Post by ldjkfkdsjnv »

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…

Literally had the same thing. I've lead large scale software projects for a critical service at a FAANG, and the interviewer will just nit pick on some random detail. Very odd feeling failing an interview like that and then going into work on Monday and banging out software on a highly competitive team

Re: In defense of coding interviews

#132

Post by leeoniya »

onion2k wrote: post #126
leeoniya wrote: post #102

Earlier quoted context omitted.

try rendering a dynamic React dashboard with 30 line, scatter, and heatmap charts, each containing 3 series of 10k points each, several times per second. welcome to what Grafana can do :)

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.

Re: In defense of coding interviews

#133

Post by drewrv »

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…

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.

Re: In defense of coding interviews

#134

Post by koonsolo »

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.

Re: In defense of coding interviews

#135

Post by koonsolo »

vorpalhex wrote: post #97
leeoniya wrote: post #58

Earlier quoted context omitted.

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's not an absurd ask. perf characteristics of different iteration styles are often significant to the task at hand.

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

For me it wouldn't be about performance but about readability.

Re: In defense of coding interviews

#136

Post by lordnacho »

sokoloff wrote: post #47
vorpalhex wrote: post #33

Earlier quoted context omitted.

How do you actually measure 2x or 10x workload while keeping quality the same? It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem. If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of ma…

I think everyone who has been in tech for 7 years has a short list of people they’d want on their 4-person tech team and a longer list of people they wouldn’t. That I can’t tell you to two decimal places exactly how much better the first list is than the second doesn’t mean I can’t tell who’s on which list with high fidelity/repeatability.

But those are people you've actually worked with day to day, right? They've had the long form of the interview with you and passed.

I know a bunch of people like that, but I've only worked with so many people. A startup would exhaust their friends pretty fast and be back to interviewing strangers.

Re: In defense of coding interviews

#137

Post by koonsolo »

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.

Lots of people can bullshit their way out of this. They just repeat stuff they heard their teammates say.

Talking about higher level stuff doesn't mean you can comprehend certain development problems.

Re: In defense of coding interviews

#138

Post by leeoniya »

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

100% agree. my point is more about OP's example being used to prove that dumb questions get asked. if it's being asked by a good interviewer, it's usually relevant.

Re: In defense of coding interviews

#139

Post by itronitron »

mountainriver wrote: post #62
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…

Yup this is true for the most part, although someone bad will be harder to justify. It’s hilarious listening to people review candidates on third coding interviews. Usually it’s “this person didn’t know this one thing I think makes me really smart”. This is why I lean so heavy in OSS to review candidates. I can see how they interact with people, and whether they are actually able to build software that _people want_…

https://people.wku.edu/sally.kuhlenschmidt/whimsy/oss/ossstr...

Re: In defense of coding interviews

#140

Post by amitport »

Jensson wrote: post #92
Apocryphon wrote: post #80

Earlier quoted context omitted.

The problem is when a significant number of companies all cargo cult the same process- that way you can’t even write them off as a one-off bad place.

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.
Post reply on HN