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

111–120 of 391 posts

Re: In defense of coding interviews

#111

Post by thaneross »

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 :)

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.

Re: In defense of coding interviews

#112

Post by quacker »

tombert wrote: post #13

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

Not that this would apply in your case (I don't know you), but in general there are plenty of well-credentialed people that are poor engineers (imo), or who are a good engineer but a poor fit for that company/team/position. And there are people that simply lie on their resume.

If it is standard at the company to give all candidates that same question, this is actually a good way to reduce bias in hiring decisions. Otherwise, you might bias toward hiring, say, people with college degrees or people who worked at large corporations, for example. And this might unintentionally bias against certain demographics that obtain college degrees at lower rates (for example).

Re: In defense of coding interviews

#113

Post by rektide »

neilv wrote: post #96
rektide wrote: post #87

Earlier quoted context omitted.

The thing is, the practical field is littered with countless different technologies & endless subjective opinions. We'd need 3,000 different tests to test everyone's practical knowledge, to let them pick between. Oh, you use Go and SolidJS, here's a test for you... and who is going to be able to properly give you a score other than works/doesn't work? This person likes functional style but this person is more OO... t…

The earlier comment suggested that Leetcode was a litmus test for whether someone has will power beyond CS curriculum, and that's what I was responding to. Are you arguing a different motivation?

That was my first post in this thread.

I think computational thinking is a good objective measure, and is learnable. That comes first to me. I also think acquiring & practicing computational thinking demonstrates will power, a willingness & capacity to tackle something, and that that something is valuable. And it's an objective, common, topical, & agreed upon/expectable test, one that doesn't rely on socially convincing someone in 5 minutes you indeed have willpower.

If you only think of this as trying to get good at Leetcode, I think you risk ignoring the actual lessons. Leetcode is an ok practicing grounds, but what's being tested relies on a mix of computer science and problem solving, and just going to leetcode & trying to get good there will probably eventually work out, but you'll miss the computer science that would actually be helping you.

Re: In defense of coding interviews

#114

Post by weatherlite »

sitkack wrote: post #109
weatherlite wrote: post #72

Earlier quoted context omitted.

> 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 Not in FAANG or famous startups it's not. You're either gonna solve 3-6 medium hard Leetcode questions perfectly or you're out. Sure, liking you will help you better not come off as a douche - but you're not gonna get a…

Interview technical folks at a FAANG and I don't asking leetcode questions. It isn't a SWE role but people should be SWE material. I do ask them to * read code * extend some working code with a new feature * parse some semi-structured text into a data structure Programming interviews suck for everyone, even the interviewer. I feel absolutely horrible when someone locks up, or fails really hard. The questions I ask ar…

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

Re: In defense of coding interviews

#115

Post by leeoniya »

thaneross wrote: post #111
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 :)

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 my machine): https://jsfiddle.net/3ho6f5k1/

Re: In defense of coding interviews

#116

Post by sitkack »

weatherlite wrote: post #114
sitkack wrote: post #109

Earlier quoted context omitted.

Interview technical folks at a FAANG and I don't asking leetcode questions. It isn't a SWE role but people should be SWE material. I do ask them to * read code * extend some working code with a new feature * parse some semi-structured text into a data structure Programming interviews suck for everyone, even the interviewer. I feel absolutely horrible when someone locks up, or fails really hard. The questions I ask ar…

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

Re: In defense of coding interviews

#117

Post by colinmhayes »

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.

I mean that's what we do, right?

Re: In defense of coding interviews

#118

Post by peterhunt »

vorpalhex wrote: post #106
peterhunt wrote: post #93

Earlier quoted context omitted.

Isn’t that going to result in a highly biased interview process? I suspect extroverts will do disproportionately better than introverts, and those who are comfortable in technologies the interviewer is not will do worse than those who share a similar technical background. I also think the skill cap on this sort of question is super low. (I’d put design questions in a different category though)

What process do you think introverts are going to have an equal footing at that isn't take home homework? And yes, people who know technology will do better.. in a technology interview. I suppose I could ask about gardening but that doesn't help much does it?

Algorithmic interviews are huge equalizers. Anyone regardless of their social skills or technical background can show their talent.

I’m not talking about people who know technology generally. I’m talking about people who know different technology. The process you’ve proposed, if implemented at, say, PHP shop, will rule out plenty of great .NET developers since the interviewer won’t have the context.

Re: In defense of coding interviews

#119

Post by zainhoda »

Software development is really weirdly unique in the way we interview candidates. In no other profession does a job candidate with work experience have to “study” or “practice” for an interview other than reading up about the company. Unless they’re interviewing for their first job, talk to candidates about their experience and dig in to what they actually accomplished.

Re: In defense of coding interviews

#120

Post by nowherebeen »

Jensson wrote: post #105
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?

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