Coding questions are a waste of time. A better interview technique is asking about a problem they solved and drill down on it. This actually is better and allows for a conversation and discussion. I know you can program so don't need to trick you up on it. If you can't then you'll quickly be found out on the job.
In defense of coding interviews
21–30 of 391 posts
Re: In defense of coding interviews
#22Instead of endlessly rehashing the controversy of coding interviews, has anyone considered just how engineers are expected to be able to understand the material on the interviews? Should it be from university CS programs? Which are supposed not to be vocational? And would discriminate against those who are not degree holders? Should it be from internships, which are nowadays subject to the same Leetcode examinations…
> has anyone considered just how engineers are expected to be able to understand the material on the interviews? I am confused - how is this question materially different from asking how engineers are expected to know what they will need in order to properly do their jobs? Just how are engineers expected to know programming languages, or domain-specific languages, or standard libraries, or platform apis? Is this what…
You are unintentionally correct, most engineers don't really know their programming language, standard libraries or basic APIs. They find _some_ solution on the internet that's good enough and run with it. Sometimes that is fine, sometimes it is not.
Re: In defense of coding interviews
#23Please provide proof that a coding interview makes a statistically significant effect on predicting success in a position, all other things being equal.
If I'm not mistaken, Google has a paper on this, in which there is a statistical confirmation of coding interviews being a predictor of success.
Re: In defense of coding interviews
#24Please provide proof that a coding interview makes a statistically significant effect on predicting success in a position, all other things being equal.
How could you reasonably prove this? “All other things being equal” seems harder to evaluate than a coding interview.
Drive, experience, intelligence, communication skills, teamwork, emotional intelligence, grit, curiosity, physical health, mental stamina, family/home situation, and dozens of other factors play into job performance, many of which you can’t even ask about to generate your test dataset. Many of these traits are what you’re trying to measure the effects of in the interview.
Re: In defense of coding interviews
#25Instead of endlessly rehashing the controversy of coding interviews, has anyone considered just how engineers are expected to be able to understand the material on the interviews? Should it be from university CS programs? Which are supposed not to be vocational? And would discriminate against those who are not degree holders? Should it be from internships, which are nowadays subject to the same Leetcode examinations…
> has anyone considered just how engineers are expected to be able to understand the material on the interviews? I am confused - how is this question materially different from asking how engineers are expected to know what they will need in order to properly do their jobs? Just how are engineers expected to know programming languages, or domain-specific languages, or standard libraries, or platform apis? Is this what…
I am indeed asking that as well, given the completely unorganized and nonstandardized state of the industry.
Re: In defense of coding interviews
#26If I have my Jr. Dev a hard problem to work on and they said "breathe over my shoulder for 30 minutes and I'll have the answer for you" I would be having a serious corrective chat with them at our next meeting. No one works that way. Coding interviews are 10 percent about coding and 90 anxiety management... Which to be clear is important, but let's be honest about what we're filtering for in these things.
Re: In defense of coding interviews
#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 is sufficiently capable to actually analyze code, and writing code with an audience is absolutely a stupid anxiety inducing high stress situation that makes candidates into babbling children who can't define an array - EVEN IF THE CANDIDATE CAN IN FACT PROGRAM JUST FINE. Add in one idiot on the interview panel who can't stop "tsk"-ing or asking obnoxious questions ("Why did you use a foreach and not a for loop?") and you have an hour long anxiety sandwich where the only thing you are getting from the candidate is whether or not they can dance in front of a sufficiently hostile crowd on demand.
Re: In defense of coding interviews
#28The 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.
Re: In defense of coding interviews
#29Before 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 interview what sort of revolutionary. Prior to that interviews had little structure. It wasn't unusual for the hiring manager to make the decision, some times based on credentials, recommendations, or trivial-like questions.
This type of interview became wildly popular because it allowed budding unicorns to hire programmers of high quality at scale. The process was less biased than the alternative, reproducible and scalable. Here you have two blog posts [1][2] that show the line of thought at the time.
The reality is that big tech has elevated leetcode type interview to an art. They have reached a near local optimal through years of experiments and refinements. It is working well for them so they don't have the need to take big risks such as completely revamping their hiring process.
I love the topic of hiring and interviewing and I'd love to truly get at the bottom of which method works best. I like this article because it explicitly calls out shortcomings with typical alternatives that are not usually mentioned. I hope in the future a new crop of unicorns can take these practices to the next level and do a fair comparison.
[1] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... [2] https://sites.google.com/site/steveyegge2/five-essential-pho...
Re: In defense of coding interviews
#30I upvoted this because it's well written, even though I disagree with the conclusions. I'm not sure the suggested alternative coding challenges are any better. The text preview one starts ok, but introducing HTML raises the complexity through the roof!
I wrote about my own experiences with coding challenges during my recent job search on my blog at https://blog.urth.org/2022/04/19/software-job-search-2022-re...
I'll summarize my conclusion about live coding challenges, which is that I'm not convinced that my performance on these challenges reflected any abstract skill I have. Instead, they mostly reflected the fact that the problems I was given were either nearly identical to work I've done in the past, or were similar enough to things I'd done recently that they felt pretty easy.
I guess there's _some_ signal in that, but I don't know if it really says anything about how good I am at coding in general.