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

191–200 of 391 posts

Re: In defense of coding interviews

#191

Post by bluepizza »

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.

I would care about the reading optimization. So if someone tells me "I chose a forEach instead of a for because it provides almost the same performance, but is more readable, and my code does not need the index", that's a very good sign of someone making conscious choices.

Re: In defense of coding interviews

#192

Post by Jensson »

amitport wrote: post #179
Jensson wrote: post #168

Earlier quoted context omitted.

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

"And if you aren't working like that then you aren't doing Scrum" I kindly disagree. You seem to have worked at a very stressfull place. In my experience that has nothing to do with it being "true scrum TM" or not. In any case, happy for you that you got out.

Always this "if you have any complaints about Scrum then you aren't doing it correctly" with no explanation how you'd fix the problems I talked about.

Also the leetcode interview is cargo-culted from big tech companies like Google and Scrum is cargo-culted from big tech consultants. They don't fit well together, having both means your company just picked the most popular/simple way to do each part without considering why Google uses that interview or tech consultants uses Scrum. If you want your engineers to work on problems similar to at Google then you wouldn't use Scrum, and if you want your engineers to work on similar problems as big tech consultants then you wouldn't use the leetcode interview.

Re: In defense of coding interviews

#193

Post by alok-g »

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…

I'll multiply that reasoning by a few orders of magnitude to show what's wrong with it. Would they hire Olympics winners for these positions?

Re: In defense of coding interviews

#194

Post by barrkel »

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…

Foreach with functions being passed being slower is an implementation detail. You don't see it in Rust, where the block body is inlined like a generic, and it's perfectly feasible for a dynamic runtime to specialize the pattern and inline based on it being a common practice, never mind polymorphic inline caches which in principle permit inlining in this case.

Re: In defense of coding interviews

#195

Post by slifin »

vletal wrote: post #160
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

Re: In defense of coding interviews

#196

Post by barrkel »

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…

Constant factors don't normally matter in an interview algorithm context. Focus on them often results in ugly code and can be a distraction against bigger improvements.

Re: In defense of coding interviews

#197

Post by zrail »

Izkata wrote: post #175
inlined wrote: post #77

Earlier quoted context omitted.

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…

> a MANGA company That's a new one to me, what's it made of? (All that's coming to mind is I presume totally unrelated: https://en.wikipedia.org/wiki/Manga )

It's FAANG but rearranged and using Meta's new name instead of Facebook.

Re: In defense of coding interviews

#198

Post by amitport »

Jensson wrote: post #192
amitport wrote: post #179

Earlier quoted context omitted.

"And if you aren't working like that then you aren't doing Scrum" I kindly disagree. You seem to have worked at a very stressfull place. In my experience that has nothing to do with it being "true scrum TM" or not. In any case, happy for you that you got out.

Always this "if you have any complaints about Scrum then you aren't doing it correctly" with no explanation how you'd fix the problems I talked about. Also the leetcode interview is cargo-culted from big tech companies like Google and Scrum is cargo-culted from big tech consultants. They don't fit well together, having both means your company just picked the most popular/simple way to do each part without considering…

Scrum does not mean "no freedom" or "no autonomy" it just says lets think about what we're going to do and try to follow a plan for the next week or two. Of course the individual software developer should be the one responsible to forming, adapting, and updating this plan (and it definitely should contain " collaborate with stakeholders, build prototypes and get feedback etc,") (of course, there is some level of 'commitment'. As in other project management systems, you should try and do what you said you'll do).

If as you say, you had no autonomy/freedom, this has nothing to with scrum, that's just regular bad management.

Re: In defense of coding interviews

#199

Post by Dayshine »

pkolaczk wrote: post #122
light_hue_1 wrote: post #64

Earlier quoted context omitted.

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

Even in java/c#: what kind of application has its performance dominated by a control structure? If you're doing so little work inside the loop then you should probably look at using fancy cpu instructions like SIMD

Re: In defense of coding interviews

#200

Post by higeorge13 »

jsnk wrote: post #73
angarg12 wrote: post #29

Before we criticize the current interview format and propose alternatives, we need to understand how we got here first. This is my understanding of what happened (I wasn't there for most of this!). Leetcode-style interviews became popular in the mid 00s, primarily because they were used by hot tech companies of the time. The thing to understand is that at that time, the idea of asking people to write code during an i…

This is probably the best take in the entire comment section. I see whole bunch of people complaining about Leetcode (LC) style coding questions, but I don't really see any alternative that is as good as LC. LC interviews solve all the following criteria better than other interview formats in aggregate. - Objectivity: can you evaluate candidates as objectively as possible as opposed to subjectivity? - Scalability: ca…

You miss an important criterion though which is “does my interview has anything to do with the actual work?”, and lc fails miserably. And this one criterion probably classifies lc even lower than take home test or coding questions.
Post reply on HN