Live data from Hacker News

Coding interviews are stupid (ish)

darrenkopp.com

591–600 of 679 posts

Re: Coding interviews are stupid (ish)

#591

Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

Yes. I've filtered out countless candidates who can't code like this. It's amazing how people will fire off applications to jobs they can't do. You might doubt this because you wouldn't do it, but just wait until you get to sift through a fresh wave of applicants. Has everyone I hired got "perfect marks" on the test? Of course not! It's not about that. It's about seeing how they react to a problem, watching them brea…

Yes, unless you’re in a niche area or only hiring through a network, you’re going to sift through mountains of unqualified candidates because those are mostly the ones on the market (see Market for Lemons[0])

[0] - https://en.m.wikipedia.org/wiki/The_Market_for_Lemons

Re: Coding interviews are stupid (ish)

#592
post #475

Earlier quoted context omitted.

The official estimate of software developer positions in the United States was 1,656,880 in 2023.[1] 10% of that would be a high estimate of FAANG software developers in all countries. And most in those companies make less. [1] https://www.bls.gov/oes/current/oes151252.htm

A high estimate? Google alone stands at 180k employees. I'd imagine at least a half of those are technical positions.

Technical positions is more than software engineers. 60,000 software engineers was the most I saw. And most other technical positions pay less.

Re: Coding interviews are stupid (ish)

#594
post #590

Maaaaaybe, but I’m not ditching them. When I’m interviewing someone, I try to set them at ease. I’m not here to spot typos. I’m trying trying to trick you. I want to see how you think about problem solving, and I’m cheering for tou . I want you to be The One! At a prior job I was the person who asked candidates to write fizzbuzz, and it was much more of a filter than I ever would have suspected. One senior engineer,…

[flagged]

I truly don't understand how you got that from what I wrote. I want the interviewee to succeed, so I'm a jerk?

Re: Coding interviews are stupid (ish)

#595

Earlier quoted context omitted.

I still don't get why such questions are even asked as most jobs I've ever had not even remotely touched those and I've touched quite a few industries, technologies and types of companies. To me, the value of a software engineer is to ask questions, make hypotheses and be able to iterate quickly. Balancing trees, leetcode and other algorithmic stuff on the spot sounds like bringing the dreadful education system struc…

> Also if a senior person can't in 30/45 min of talking with someone figure out the general experience level then the problem is them, really. Actually most of them, including the really inexperienced juniors have 'figured' you out in less that 15 minutes, or at least they have decided whether to hire you or not in 15 minutes. But they have to put on a charade of being fair. Also a 'white' older male is the least pre…

> Also a 'white' older male is the least preferred even if he is smarter compared to all females and the minorities that are being interviewed as long as they are not terrible. Biases galore.

I will agree that ageism is a thing, but 90% of all of my coworkers (who were software engineers) have been white males, so I cannot at all agree with this take otherwise.

Re: Coding interviews are stupid (ish)

#596
post #375

Classic mistake of overthinking it and failing to realize what interviewer really wants - which is to make sure the candidate can actually write code, like at all. The question itself doesn't really matter as much as it's just a pretext. I actually asked a variation of this question for many years at Google and it was clear within first 5 mins who has been writing code day-to-day and who's been mostly "brining key st…

I disagree, I think it's a failure of recruiting if you got someone into an interview who can't code "at all". That must mean nobody at the company is technical "at all" either then, if you are getting people that far along without having any clue if they even write code at all. I don't have this problem - I can easily tell who is good and who is not good by looking at their stuff online, which repos they are contrib…

No way to know for sure, but I'd guess the number of employed developers writing blogs and having personal projects is in the single digits. For developers with more than 20 years experience, I'd be surprised if it's even 1%. I've got more experience than that, which means I have an extensive network of former colleagues at a similar experience level and I don't know one single person who blogs about tech or works on personal projects. We all have busy family lives and plenty of money so absolutely no need to spend any personal time doing work related stuff.

Re: Coding interviews are stupid (ish)

#597
post #555

Earlier quoted context omitted.

In my experience, whether this is top of mind has a lot more to do with what people work on and with what tools than with level of understanding. For instance, in your example: > For example a report that took over half an hour to generate, I made a one-line change and cut the time to a few minutes In essentially all the work I've done in my career, this would be the result of expertise in SQL and the relational mode…

In my case the processing was happening in our backend. I can't remember exactly why it couldn't be SQL, actually it's possible it could have been sql. But changing it to sql would have been a bigger change and this wasn't really the task I was working on, I just happened across it while doing something else. I have also seen and fixed similar travesties where someone iterates through a huge list making one query per…

Unsurprisingly we've now reached the perennial "is premature optimization actually premature" of it all :)

Would it have been better for the person who originally wrote that just-iterate-the-list implementation to have been thinking about data structures and algorithms that would perform better? Opinions on this vary, but I tend to come down on the side of: Optimize for human productivity (for both the writer and the many future readers) first, then profile, then optimize any bottlenecks.

My assumption when I come across something that turns out to be a performance bottleneck that is easy to fix with a better data structure or algorithm, is that the person who wrote that was consciously doing a simple implementation to start, in lieu of profiling to see where the actual bottlenecks are.

But I also understand the perspective of "just do simple performance enhancements up front and you won't have to spend so much time profiling to find bottlenecks down the line". I think both philosophies are valid. (But from time to time I do come across unnecessarily complicated implementations of things in code paths that have absolutely no performance implications, and wish people wouldn't have done that.)

Re: Coding interviews are stupid (ish)

#600

Earlier quoted context omitted.

I think you're completely ignoring the reality of frauds. Jeff Atwood was writing about this over a decade ago with "FizzBuzz". There are many people who spend more effort creating the illusion of competence on paper and on the job, getting harder to detect the higher they go. We as a profession (software engineers) have continually resisted broad unified certification like other engineers which could be a replacemen…

> There are many people who spend more effort creating the illusion of competence on paper and on the job, getting harder to detect the higher they go. If you can navigate a software engineering position, purely undetected, by bullshitting it, I would say you can be a very good manager. You can probably handle high level concepts without knowing the implementation details.

...which is completely unhelpful if you're not looking to fill a manager position.
Post reply on HN