Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

161–170 of 340 posts

Re: Ten years of experience, still failing phone screens

#161

Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. In the last 4 months of job searching I've gone from barely being able to get past the question (reading under time pressure stresses me out), to convincingly passing about half of my recent phone screens. All I've done is one LeetCode per day and interviewed a couple of times per week. I'm not fundam…

> Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. That is a feature. You look at what they worked on before to see if they are senior material. Then you do leetcode and system design to see if they are smart. A smart person would most likely learn whatever tech and problems they worked on, so if they do well on leetcode you just assume they did wel…

As a former director of engineering who has hired many great developers and many terrible ones, I can safely say that grinding leetcode isn't a valid signal for smart, just for conformity, ego, and time. Some of the worst developers I know could crush leetcode all day.

Yes, it's an easy signal, it makes an unpredictable and messy process feel neat and binary. However, it is a false signal, and no amount of personal comfort changes that it has about as much effect on future employee productivity as hiring by height or favorite color.

Unfortunately, software productivity is never going to be measurable. Therefore we will never ever have a reliable metric to even prove to ourselves that we are more or less productive than our coworkers, much less worth hiring. This fact should sober our prideful arrogance about hiring and introduce some humility. Our best practices are a farce with absolutely zero data to back up their validity. Ask yourselves where are the studies that prove candidates who crush leetcode perform better than those who couldn't? Where is the double blind research?

We need a heaping dose of recognition that most of our best practices are there to validate the egos of the interviewers and give a neat binary decision without any mess. We have a toxic fraternity hazing ritual to make candidates bend the knee, with exactly zero evidence it works.

We have the gall to call ourselves scientists, and we don't even measure a single thing.

Re: Ten years of experience, still failing phone screens

#162
post #150

> ” I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.” That’s exactly what happens to me. The thing is, I am not as fast or experienc…

It’s hard to find those places because they’re usually small companies outside the valley without name recognition.

I work for one of those places and am the lead technical interviewer (no “a” lead, “the” lead, that’s how small we are).

We do have a very easy take home code challenge that’s very related to the kind of work we do. But we only specify the language to use because that’s what 99% of our code is written in. We don’t care anything else about structure of the project and you do it on your own time (it’s really only an hour or two of work - or at least it should be)

I’m not sure of the rate of people returning the challenge to us (I hear that it’s a bit less than 50%). I interview all of the folks who return code. And pass about 2/3 of those on to the full day interview. (No-pass is usually code that doesn’t compile or gets the wrong answer on the test case that we provide - we give them the correct answer for the test case, so they know what they’re aiming for). And we hire a pretty high percentage of the folks who do the full day. Granted, we’re in a bit of a niche field and we don’t have big-tech name recognition so we don’t have the volume of applicants that other places have to deal with.

I always try to be respectful in the interview and we only talk big picture stuff. There are no quizzes or gotcha questions, we talk about the code and just have a conversation. I hope that everyone who leaves my interview feels respected and like their time wasn’t wasted. Sometimes I include one of my junior engineers on the technical interview so they get experience with it. Usually they start off peppering questions and trying to be smart, but I just set a good example and they calm down quickly and realize it’s about a conversation and seeing if the candidate would like the kind of work we do.

I can’t think of any bad hire we’ve make in my years of doing it this way.

Re: Ten years of experience, still failing phone screens

#163
The best interviews are designed not to filter out bad candidates but rather to allow good candidates to demonstrate that they are good. The best companies know that and design their interviews in that spirit.

Some technical test interviews appear pointless to experienced candidates because they are designed to give an opportunity to someone without any experience to show that they know enough to get started. That's how some companies can hire people without work experience.

Many (most?) companies are simply bad at hiring and use poorly designed cargo-cult test interviews. They have a vague notion that more successful companies use test interviews so they try to do the same, only without designing an actual effective hiring process. As a result, their hiring is essentially random - they interview some people, which they put through a test interview ritual, and then hire a random selection of these people. Even if you can get a job at such a company, would you want to work somewhere where you'll end up with randomly selected colleagues? These also tend to be the companies that have high employee turnover - they have to let underperformers go to compensate for their random hiring, and the best people leave because they don't like their randomly selected team.

If you have a realistic view of your own skill and fit for the role and the interviews don't make sense then either you're overqualified or it's just a bad company or both, and you wouldn't want that job anyway.

Re: Ten years of experience, still failing phone screens

#164
post #93

One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…

I have noticed that sense of "domination" come out in interviews as well. I remember long ago having one interview where the interviewer was asking me to code something which I knew would be impossible to complete in the time allotted. It just seemed so ridiculous to me that I was supposed to write this complete solution in about 30 minutes. I remember how superior he was acting at the start of the interview too, and…

What the hell does a yo-yo do in an interview? I think that by itself would make me walk out.

Re: Ten years of experience, still failing phone screens

#165

One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…

Well he could also be pissed off that he’s interviewing someone who claims to be an expert in something he can’t even install.

I mean, you set up cypress exactly once, and after that you write only tests.

It seems reasonable to me to not be great at setting it up.

Re: Ten years of experience, still failing phone screens

#166

Earlier quoted context omitted.

> Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. That is a feature. You look at what they worked on before to see if they are senior material. Then you do leetcode and system design to see if they are smart. A smart person would most likely learn whatever tech and problems they worked on, so if they do well on leetcode you just assume they did wel…

As a former director of engineering who has hired many great developers and many terrible ones, I can safely say that grinding leetcode isn't a valid signal for smart, just for conformity, ego, and time. Some of the worst developers I know could crush leetcode all day. Yes, it's an easy signal, it makes an unpredictable and messy process feel neat and binary. However, it is a false signal, and no amount of personal c…

Yes! See my earlier comment about how we hire.

Want to add agreement that grinding leetcode is a terrible metric. The ideal candidate probably already has a full time job and if you add in a family and other responsibilities, they don’t have time to focus on leetcode. Heck, they probably are tired of thinking at work all day and don’t have the mental capacity to task switch into leetcode after work (I know I don’t!)

I think leetcode is an antisignal

Re: Ten years of experience, still failing phone screens

#167

As Jensson points out, smart people can grind leetcode, so if you have good experience, grinding leetcode shows you're smart enough to get the job. If you don't grind, there's no signal of how good you are at coding, so it's a no hire. Really, it's on you if you don't do what needs to be done to get the job. So get grinding! Or remain unemployed.

Can't tell whether you're being sarcastic.

Re: Ten years of experience, still failing phone screens

#168

Earlier quoted context omitted.

> This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Looks like he has ADHD. Maybe somebody with more time can go through his blog post line-by-line and figure out what's going on. Most of my Coderpad stuff compiles and runs the first time, so I don't use his incremental test method, or see a need for it. Maybe he learned programming on heavy-weight IDEs and got…

So a screening system that only allows devs with your writing style in is valid why? I'm just like them, only my ide is notepad++. My code never compiles on first attempt, and never runs correctly on the first attempt.

If my code compiles and runs correctly the first time, I spend an inordinate amount of time looking for bugs in it ;)

Re: Ten years of experience, still failing phone screens

#169

Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. In the last 4 months of job searching I've gone from barely being able to get past the question (reading under time pressure stresses me out), to convincingly passing about half of my recent phone screens. All I've done is one LeetCode per day and interviewed a couple of times per week. I'm not fundam…

> Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. That is a feature. You look at what they worked on before to see if they are senior material. Then you do leetcode and system design to see if they are smart. A smart person would most likely learn whatever tech and problems they worked on, so if they do well on leetcode you just assume they did wel…

>so if they do well on leetcode you just assume they did well in their past jobs.

wat? how did you draw that crazy conclusion?

even competitive programmers says that there's probably negative correlation between good engineer and competitive programmer

and I'm saying this as a person who doesn't mind having to solve algo questions

Re: Ten years of experience, still failing phone screens

#170
post #2

This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain…

Your mention of Joel's post made me curious to find and read it. I assume this is the post in question: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...

I'd say much has changed since he wrote that, and even for the time it contains some odd advice which he tries to force down the throat of the reader, but I'd be more interested to hear other's thoughts on the article.

Post reply on HN