Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

211–220 of 340 posts

Re: Ten years of experience, still failing phone screens

#211

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 hadn't done many interviews before starting at my current job, where they seem to make a point of getting a lot more people involved in the interview process. I guess this is an idealistic view, but it should be pretty clear if you're a hiring manager whether the people you're getting involved in the interview process are likely to be jerks to a candidate.

What you describe is embarrassing, and does reflect poorly on your company. Review sites like Glassdoor do or did have interview reviews as part of their company review, and people do go look at those when deciding whether to apply at a company.

I hope you shared your feedback with your coworker, and also the hiring manager. That coworker is probably not ready to do interviews and needs some training (or maturing) first. In the future, you might interrupt the coworker and then try to help the candidate along; maybe they won't pass the interview, but you don't have to let them leave feeling like a failure, and along the way you might get some information about where they could fit in your organization. And the entire interview won't have felt like such a waste.

Re: Ten years of experience, still failing phone screens

#212

> In theory a phone screen is supposed to evaluate whether a) this person would be good at the job being hired for and b) whether it's worth investing another five hours in trying to hire this person. They also screen whether or not you communicate well, your motivations for looking for work and whether that matches the role and future growth of the role, whether there are any logistical or compensation-based blocker…

It's hard to get meaningful answers to these really general properties you're after:

> communicate well

This has so many elements and is really only fully visible after you work with someone for a while. Sure you'll catch some red flag issues, but such issues likely to be caught are also likely to be caught no matter what you're talking about, so this can't be the primary purpose of the screen.

> motivations for looking for work

Is not wanting to trade services in exchange for money in a valued environment enough? But sure, aspects of this for most people can be an important subgoal, it's just important to set expectations on how easy it is to game and how unreliable the signals will be. I've sometimes found it useful to probe seriousness and a sense of longevity commitment (if that matters, and can be incentivized without needing to probe), and some of their values, and whether their idea of your actual environment matches your reality and how much that matters (the candidate should be actively participating in this with their own questions though), but again reliable signals are hard. Once I helped screen a manager who was thinking of coming back (he had previously left a couple years prior) to the company to manage a new project, and got out of him when asking what might stop him from leaving again in a year the vague (if true and agreeable) "you never know what opportunities life will bring" and concluded he wasn't that committed for the role I felt needed someone willing to put at least a few years at it. It surprised another guy who talked to him, but he hadn't probed into that.

> logistical

Seems this could be handled before any conversation takes place by clear communication about whether the role is remote or not, how much office time is required, whether relocation support is offered, and so on.

> compensation

Also can be handled before any conversation by having salary ranges for the role. If they're too low, a good candidate might go through with things anyway and try to negotiate beyond the range.

> getting all the deal-killers out of the way is the point of the phone screen

Ultimately I agree with you on this, but I think the biggest deal-killer for a technical role is: the candidate cannot actually program at a level you require. I'm a fan of Yegge's process (https://sites.google.com/site/steveyegge2/five-essential-pho...) and warnings and have used my own variant for what we cared about more, but frankly if your screening doesn't require some level of coding at least on the level of fizzbuzz or easier (but adjust to requirements/expectations), sooner or later you're going to bring someone in for a full round and discover they can't program, wasting possibly considerable time (more than five hours when adding it up for everyone involved) as well as the opportunity cost.

Re: Ten years of experience, still failing phone screens

#213

Earlier quoted context omitted.

Incompetent until proven competent. Most industries don’t have to deal with that attitude but it’s prevalent for us. Imagine asking a doctor basic biology questions or what an antibiotic is used for in an interview.

For example: The idea that there are many programmers who cannot even write fizzbuzz sounds like a very strong claim. It seems far more likely that there are many programmers who have socially-induced anxiety.

I have interviewed senior candidates (more than two, fewer than five) who couldn’t write code to sum an array of ints (ignoring overflow). *

Not in the sense of missed a bit of punctuation, but rather in the sense of “couldn’t get started with anything that vaguely smelled like an answer, didn’t understand the type system of the language they claim 5 years of experience with, etc”.

I’ve probably interviewed fewer than 400 candidates in-person and maybe 200 of those would be senior ICs. To have more than a percent of them be utterly incapable here is a signal that there are candidates out there taking their best half-court buzzer-beater shot to try to land the prize. If you’ve done 100 first round in-person interviews and never run into someone that causes you to check up on how the phone screen happened, your screening processes work pretty well.

Is it possible that these candidates are capable programmers in daily work? Sure, it’s possible, but I’d bet against it.

* We used to ask a candidate to average an array of ints. It’s a question that was designed to tease out whether the candidate would discuss/inquire about overflow, what the return type should be, etc. After a couple years, we realized that candidates would stumble on the loop and sum more than anywhere else and we got more signal/minute from asking the vastly simpler summation question. Candidates who could fluently write the loop usually knew about overflow and the fact that the average of ints isn’t mathematically an int but that many times an int is what you want and can discuss the reasons.

Re: Ten years of experience, still failing phone screens

#215
post #199
post #194

Earlier quoted context omitted.

> chatting on his phone with the audible keybord ticks enabled. That alone is a disgrace.

Please go off in a corner and ponder why such casual ageism is as unwelcome as casual racism or sexism and maybe just stay there until you come up with an answer. Substitute woman for boomer in that sentence and listen to what it sounds like.

I could substitute it for child, another group of people who are broadly less likely to know where the setting is, and it wouldn't be offensive that way either.

Re: Ten years of experience, still failing phone screens

#216
Everything he said is spot on. I suspect algorithm interviews are optimized for FAANGS - e.g if you can do the whiteboard and coderpad under pressure and interruptions you'd statistically do well in FAANG. I suppose that's true otherwise they wouldn't be doing it. But this hiring process is extremely broken for most everyone else; FAANGs don't really care about false negatives; they have so many great people wanting to work for them its ok for them not to hire some great people. But this whole process seems problematic to me for smaller companies who are in great need of good people and aren't drowning in great resumes. You can't really afford to miss 50% of great people if you're a startup, and this process will do just that; it will let you hire good people but also not hire good people on a really bad margin. Companies who are not FAANGs, especially startups, are better off coming up with some hiring process like the author described; it's not perfect but it will have less false negatives.

Re: Ten years of experience, still failing phone screens

#217

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…

> he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo and he floundered the entire time If I was floundering because the interviewer found a hole in my knowledge (and there are many holes in Albert Hall) I'd proactively state that and say where the holes weren't and ask for a question about that. For example, I've implemented a complete C compiler, front to back, so at one point…

I agree that an interviewee should be an active participant (though not being is fine too given the state of interviewing), however attempting to drive it themselves can really backfire if the interviewer isn't expecting it and/or is bound by policy to actually ask certain questions or go through some process. I still remember one guy who wanted to drive things a bit too strongly, which for most of my section was fine with me because I was still able to get the data I wanted out of it and hopefully he got some of his, though at a point I really insisted he actually code a working solution to a problem in the IDE setup for him (requires like 15 lines of code, it's embedded in the context of a larger program) rather than continue to whiteboard/pen-and-paper general thoughts. He did, and I gave him a positive recommendation. But in the after-meeting my coworkers were less happy with their sections (one of them even brought up the sense he was trying to 'run the clock'), and some of them were still new to interviewing and didn't know how to handle a more 'aggressive' candidate and apart from not enjoying the experience couldn't get the info they wanted, so the eventual decision was to say no to him. I still think he would have done fine, but hey, it's just another element in how broken our interviewing practices can be.

Re: Ten years of experience, still failing phone screens

#218
post #195

It's important to remember that it's also YOU interviewing THEM. The coding interview is an opportunity to get to know the company culture in a very feet-on-the-ground fashion. How the interviewer behaves and how they expect you to do things reflects upon them as managers, mentors, and in general people you'll be working with for potentially a long time. - If they're forcing you to go against your natural flow, that'…

I've always thought it would be fun do say, "Ok, this sounds like a fun game. It's only fair that if you get to ask me a question I get to ask you one." I'd be willing to bet 90% of the interviewers would crumble on the first question. I've noticed that most of the interviewers not only select their questions ahead of time but also have to do research so they are sure they know the answers too.

I hate interviewing but the very few opportunities I've had to have a technical discussion back-and-forth Q&A with a candidate have been helpful. A lot of candidates don't even ask about the day-to-day expectations or stack, and I think that's unfortunate for them.

Re: Ten years of experience, still failing phone screens

#219

I read about three paragraphs in and then stopped. Coderpad tests where you're encouraged not to write tests, can't hit the run button, and can't use reference material? Worthless. Most people - not just the author - are going to fail those, and they are not representative of the work environment, so what's the point? We use Coderpad for one of the 3 interviews we give candidates. We do a tech screen first, then the…

> Overall I'm not sure how much value we get out of coderpad

Well so you're pretty much in agreement with the author it seems. He's just more convinvced than you that coderpad is actually more bad than good that's all, you have a bit more doubts.

Re: Ten years of experience, still failing phone screens

#220
post #189

Earlier quoted context omitted.

> he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo and he floundered the entire time If I was floundering because the interviewer found a hole in my knowledge (and there are many holes in Albert Hall) I'd proactively state that and say where the holes weren't and ask for a question about that. For example, I've implemented a complete C compiler, front to back, so at one point…

What's really great is if you can get the interviewer talking about themselves. If you're lucky you'll spend the entire interview nodding and saying things like, "wow", "that's really cool. How did you come up with that?". At the end, if it's the kind of interviewer that will talk about themselves for an hour straight they're going to love you, just sat there and let them be the center of attention. The problem is do…

A word to interviewers:

Watch out for this. It is a real phenomenon. If you "enjoy" thr interview, you are more likely to think the candidate did well. And if you spend a lot of time talking about yourself, you are more likely to think the candidate did well. Don't be fooled. Have a rubric that you can objectively measure the candidate against.

Post reply on HN