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

121–130 of 391 posts

Re: In defense of coding interviews

#121

Post by weatherlite »

sitkack wrote: post #116
weatherlite wrote: post #114

Earlier quoted context omitted.

I was referring to SWE roles, as is this article I believe.

They aren't technically SWEs but they would be at any other company. I have been a SWE at three other FAANGs

> I have been a SWE at three other FAANGs

Good for you.

Now seriously I'm not sure what you're arguing for - you're saying FAANGS don't do Leetcode style questions? I get it that YOU don't do it to candidates in those roles, but the reality is for SWE roles this is how it is. People who aren't very good in Leetcode will not succeed. There's hundreds, maybe thousands of candidates for these roles and some of them can do the Leetcode thing - they are the ones who get hired. I'm not advocating for this method because I'm not particularly good at it or like solving these things on my spare time, nor do I think this method is particularly useful - but that's reality.

Re: In defense of coding interviews

#122

Post by pkolaczk »

light_hue_1 wrote: post #64
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.

> perf characteristics of different iteration styles are often significant to the task at hand. This ridiculously untrue. It's also a great example of how dumb current interviews are. Someone like this poster could easily interview you, and now what? Do you just play along or begin to explain how incredibly wrong they are?

This is untrue in languages with proper optimizing compilers, designed for performance, e.g. C++, Rust, Zig. A functional iterator transformation chain is often just the same performance as a "traditional" for loop.

But try that in Java and you'll often see a 3x-10x difference, especially if you run into problems with boxing. Streams are known to be notoriously slower than for loops with index. I once have even doubled the speed of a for loop by unrolling it manually (Java 8). Not all compilers are equally strong at optimization.

Anyway, asking such questions in an interview for a junior/regular developer is just a distraction.

Re: In defense of coding interviews

#123

Post by Jensson »

weatherlite wrote: post #121
sitkack wrote: post #116

Earlier quoted context omitted.

They aren't technically SWEs but they would be at any other company. I have been a SWE at three other FAANGs

> I have been a SWE at three other FAANGs Good for you. Now seriously I'm not sure what you're arguing for - you're saying FAANGS don't do Leetcode style questions? I get it that YOU don't do it to candidates in those roles, but the reality is for SWE roles this is how it is. People who aren't very good in Leetcode will not succeed. There's hundreds, maybe thousands of candidates for these roles and some of them can…

I know Google has some tech support engineering roles where they ask such simple questions to candidates. They aren't software engineers and generally don' get to contribute to the main codebase, but they help customers fix problems with how they use Google API's etc so they need to know a bit about how to code.

Re: In defense of coding interviews

#125

Post by nunez »

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.

i definitely 150% have

there are a lot of them

Re: In defense of coding interviews

#126

Post by onion2k »

leeoniya wrote: post #102
vorpalhex wrote: post #97

Earlier quoted context omitted.

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

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 code. Most companies aren't.

Re: In defense of coding interviews

#127

Post by pkolaczk »

quickthrower2 wrote: post #70
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…

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

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

Re: In defense of coding interviews

#128

Post by rvz »

qz_kb wrote: post #60
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…

How dedicated you are to do a task with no intrinsic value besides getting hired at companies with leetcode-style interviews. I don't think google is better off when everyone they hire has wasted hundreds of hours on a fundamentally useless skill rather than having used that time to learn different skills or just enjoy time with family and minimize the chance they burn out on the job at a later date. There's other wa…

> How many people if asked to do this on a job rather than an interview a year later would then go and implement it from memory without double checking they didn't forget some edge case on stackoverflow?

An excellent question.

If the interviewer is to ask such algorithms questions looked up on leetcode, etc, then they must be prepared for when the candidate asks if they also use it themselves on the job. If the interviewer admits they don't use it, then they also admitted that they don't know what they are looking for and really are wasting the candidate's time.

If it were me, I would look at open-source contributions (no hello-world or demo projects) where that is enough proof for me to evaluate an entry-level candidate and cut through the algorithms nonsense and ask questions to the candidate based on that which will save everyone time.

Re: In defense of coding interviews

#129

Post by nowherebeen »

rvz wrote: post #110
nowherebeen wrote: post #38

Earlier quoted context omitted.

3 problems I can see with this a) Its like saying a Tobacco company has a paper saying smoking is healthy b) Google measures things that matter to them. The operate on a scale that 99% of companies aren't. Their predictor of success only applies to companies of their scale. c) What is their definition of success? And how does it apply to smaller companies less than 1000 employees?

Precisely. Especially with (b) and (c) What works for Google does not mean it will also work for the 99% of companies that are NOT Google or any other FAANMG company. This only shows that we have an incessant coding interview cargo-cult around how FAANMG companies interview candidates and several startups taking that to the extreme and thinking they are working on complex Google scale problems. To these interviewers…

A wake up call is coming to theses startups because the money has stopped flowing. I suspect a lot of these startups replicating Google in both interview style and architecture are going together fail fast.

Read up on HN post on Fast. Someone was commenting one how they failed the interview because the HM wanted someone that wasn't a cowboy. They wanted someone that build microservices like Google. Being a cowboy is what you need to find PM fit. Focusing on microservices when you don't even have enough customers is a huge waste of money and detrimental to your company because of operational complexity. Any changes that should take 5 mins, now takes 3 hours. Fast had so little customers that an engineer suggested that they run the system under a single AWS monolith and was quickly shot down.

Re: In defense of coding interviews

#130

Post by [deleted] »

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…

[deleted]
Post reply on HN