Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

111–120 of 340 posts

Re: Ten years of experience, still failing phone screens

#111

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 knew everything about C. But in implementing a new C compiler (ImportC) a few months back, I had to go over the Standard again, as I'd forgotten bits and pieces.

There's no reason at all why the interviewee cannot drive the direction of the interview, rather than being driven. For example, when I interviewed for a software job after leaving my mechanical job at Boeing, I was concerned that I wouldn't be taken seriously as a programmer. So I brought along listings of the code I'd written and pulled it out during the interview and proceeded to explain it to the interviewer, on my own initiative.

A long time after that, I was talking to the interviewer, and he said that that was what got me the offer.

Re: Ten years of experience, still failing phone screens

#112

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 recall voicing an opinion that we should record interviews we give candidates and re-review it during the hiring committee, much like we do code reviews. Have the interviewer justify certain beliefs about the candidate with hard timestamps rather than platitudes ("not confident", "wanted to see how they react under pressure", etc. etc.). My comment always gets pushback. Privacy, respect for interviewer ("If I work…

If I was the candidate, and you informed me the interview would be recorded with video, I would politely thank you for your time and end the call.

Re: Ten years of experience, still failing phone screens

#113
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 fundamentally any better of a software engineer than 4 months ago. The current system is great for zero-knowledge people with the time and mettle to study, and awful for accomplished but time-poor senior engineers.

And, why all companies have decided upon almost the exact same methodology, I can't understand that either. It seems to be the same double edged sword as the Common Application for college: you get more applicants because the incremental effort required to apply to college n+1 is low, but it drives down college admit rates as well as matriculation rates: the signal to noise ratio probably goes way down.

Re: Ten years of experience, still failing phone screens

#114

Earlier quoted context omitted.

>IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated. What if it was skin color, how ethnic your name is, or your gender? Did you know the majority of developers are men? Should we throw all the female applications in the trash because they're statistically not as likely to be developers? Yeesh. Sorry if I sound h…

How is skin color, ethical or gender are related to their point? > Should we throw all the female applications in the trash because they're statistically not as likely to be developers? What do you mean?

The point is that top level comment talks about something being predictive of job performance. In this case, leetcode.

What if skin colour, ethnicity or gender were highly predictive of job performance? It doesn't seem very ethical to judge candidates like this.

I believe the GP is not convinced by the "all that matters is that it's predictive of job performance" idea.

Re: Ten years of experience, still failing phone screens

#115
post #76

Earlier quoted context omitted.

On the receiving end it weeded out a huge number of bad candidates. Along with (as was the main point of the original blog post) probably quite a few false negatives, Like the author of that post, for example. Meanwhile, you can achieve the same filtering benefit by far less obnoxious and more accurate means (a cursory glance at their repo, fore example).

I'd rather filter out good candidate than let bad in. It's a domino effect. You let one bad, he will hire more in the future.

> You let one bad, he will hire more in the future.

When your organization can recognize a poor investment but cannot act on it, you have an organizational problem. Why would someone get to hire more "bad" (for whatever that means) if you can recognize it? Even if you're doing all the hiring yourself, it's unlikely you'll have a 100% record over time.

Re: Ten years of experience, still failing phone screens

#116

Earlier quoted context omitted.

I'd rather filter out good candidate than let bad in. It's a domino effect. You let one bad, he will hire more in the future.

I always hear this but never seen proof. If they are bad how do they get into a position that lets them make hiring decisions? Everyone likes to think they are the good candidate and not the bad one that slipped through…

> If they are bad how do they get into a position that lets them make hiring decisions?

We have flat hierarchy. Just volunteer to interview because your voice is on the same level as others.

Re: Ten years of experience, still failing phone screens

#117
post #76

Earlier quoted context omitted.

On the receiving end it weeded out a huge number of bad candidates. Along with (as was the main point of the original blog post) probably quite a few false negatives, Like the author of that post, for example. Meanwhile, you can achieve the same filtering benefit by far less obnoxious and more accurate means (a cursory glance at their repo, fore example).

I'd rather filter out good candidate than let bad in. It's a domino effect. You let one bad, he will hire more in the future.

Isn't this why there are trial periods ( no idea if it's a thing in the US with the "right to work" thing)?. Over here in the EU a work contract can't be terminated from the company just like that, there needs to be a specific reason ( like downsizing, or a serious error), and you can't quit just like that a mandatory notice period is required ( of course negotiable depending on the situation), usually in the 1-3 months range. Therefore there's a trial period at the beginning, 3-6 months usually, during which any party can end the employment with a very small notice ( a day or two).

So if someone lied their way through interviews, in the first couple of months you should be able to detect that and terminate their trial period.

Re: Ten years of experience, still failing phone screens

#118

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…

> There's no reason at all why the interviewee cannot drive the direction of the interview, rather than being driven.

You know how they made a program pass the Turing test? They didn't make it smart, they hardcoded a conversation where the program drove the conversation to where it wanted it to be. That way the person interacting with the program was passive, so they never noticed that they were just interacting with a stupid program in the 5 minutes they had with it.

The same happens in interviews, if you take a person who don't understand tech, but have watched a lot of conference talks and read some papers and he can re-tell those, and he even remembers answers to common questions from the question parts there, but he doesn't understand much at all of what was said he just remembers conversations, then that guy will look like a world class expert if he gets to drive the interview. But once he starts working he didn't know anything at all, he just learned to talk about these things not do them. Some would say "just dive deeper into his knowledge!", but you can't always do that, if you aren't an expert yourself in his subject area you wont be able to drive down deep enough to find his flaws, and since he is driving the conversation most likely you wont be an expert on what he is talking about.

Re: Ten years of experience, still failing phone screens

#119

Earlier quoted context omitted.

Maybe you're trapped in mentally simulating a compiler and those of us with good dev setups can dedicate brainpower to other concerns?

It's the other way around, from my experience. People who can write a program without any setup can solve it even on paper, while people that are hardwired to specific setup or IDE quickly froze when you ask them for something.

> People who can write a program without any setup can solve it even on paper,

As someone who had courses in C on paper, i can only say that it's a colossal waste of time. Tooling exists to make lives easier, gain time and productivity, why avoid it?

It'd be like saying only the farmer who can do everything by hand without any tools increasing their productivity is a real one. Or an accountant refusing to use Excel/calcuators/ERPs and writing everything on paper.

And before anyone jumps to conclusions, i often write small scripts with vim with a minimal setup, but when I'm doing anything complex i prefer to use an IDE

Re: Ten years of experience, still failing phone screens

#120

Earlier quoted context omitted.

I'd rather filter out good candidate than let bad in. It's a domino effect. You let one bad, he will hire more in the future.

I always hear this but never seen proof. If they are bad how do they get into a position that lets them make hiring decisions? Everyone likes to think they are the good candidate and not the bad one that slipped through…

When they put it in the promo committee calibration doc that X level has done Y interviews per quarter, they end up on interview loops but then feel they must say no to Z% else they’re not “raising the bar”
Post reply on HN