Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

281–290 of 340 posts

Re: Ten years of experience, still failing phone screens

#281
post #230

Earlier quoted context omitted.

As someone who was born before the moon landing and saw one of the last IMPs get installed on the ARPANET, yeah that was offensive. You should apologize. Knowing to silence your phone in meetings is a matter of having manners, not age.

> 'As someone who was born before the moon landing' That would include any and all of us in this thread. No man has ever come anywhere near the moon. Unless, of course, you happen to know of some kind of magical (presumably still classified) rocket nozzle tech that would somehow avoid leaving a crater in the soft 'lunar dirt' as the 1960s tin can touched down on the 'lunar surface.' Not to mention an actual solution…

See the capacitor in this closeup that kens took of a power supply module in the Apollo Guidance Computer? My dad's company made it. You are telling the wrong person that the landing was faked.

https://static.righto.com/images/agc-power/transistor-closeu...

Re: Ten years of experience, still failing phone screens

#282
post #273
post #269

Earlier quoted context omitted.

A lot of candidates don't have public repos It doesn't have to be a public repo of course. They can just send zip file. You need an equal comparison across all candidates. "We'd like to see a code sample -- something we can build and compile, that you feel is representative of your skill level." Sounds pretty straightforward and egalitarian to me.

I'm curious, if we exclude all your open-source work (assuming you have some), what did/would you submit when given the question?

Floppy disk? A printout?

Long before open source was a thing, and repos were even thought of -- I always had a few 1,000+ line personal projects I could dig up and show people.

Re: Ten years of experience, still failing phone screens

#283

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…

> 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?

Google has data on this, when I worked there anyone working there could view it. Performance on their technical interviews is the strongest signal they have that someone will perform well at the job. It is stronger than every other signal. They have tried a bunch of different things, Google HR hates these technical interviews since it is hard for them to game so they work hard to remove it, but they can't since they can't come up with anything with a stronger signal.

Performance on a single technical interview isn't a strong signal, but the combined performance on 5 interviews is a strong signal. If you only run a single of these instead of many with many different people then you will hire a lot of bad people anyway. Also if you pay less than Google and similar then you will get their rejects, there is probably something wrong with the people who are good at algorithms but get rejected by FAANG, not sure why you would want to hire those.

Re: Ten years of experience, still failing phone screens

#284
post #282
post #273

Earlier quoted context omitted.

I'm curious, if we exclude all your open-source work (assuming you have some), what did/would you submit when given the question?

Floppy disk? A printout? Long before open source was a thing, and repos were even thought of -- I always had a few 1,000+ line personal projects I could dig up and show people.

right, and plenty people don't have large personal projects, or not personal projects that align with their work skillset, and the question is extremely vague what scope you're looking for.

Re: Ten years of experience, still failing phone screens

#285
post #284
post #282

Earlier quoted context omitted.

Floppy disk? A printout? Long before open source was a thing, and repos were even thought of -- I always had a few 1,000+ line personal projects I could dig up and show people.

right, and plenty people don't have large personal projects, or not personal projects that align with their work skillset, and the question is extremely vague what scope you're looking for.

Right - it's a bar, and some people won't meet that bar. And that said - a pretty minimal bar.

1,000 lines isn't that large, btw - but yeah, maybe 500 would be a better number.

Re: Ten years of experience, still failing phone screens

#286

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…

>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

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

They don't. I've worked with some of the best competitive programmers in the world, they do think it is a positive and look for people with a strong competitive programming background.

However, if your interview process only selects for ability to solve algorithm problems, then people with a lot of practice solving algorithm problems will over perform relative their level of talent, so when you run a dumb regression analysis it might look like competitive programming experience is a negative signal. So if someone has competitive programming experience then you want to bring them in for an interview, but you should probably be harder on them in the interview than regular candidates to account for this effect.

Re: Ten years of experience, still failing phone screens

#287
post #235

Earlier quoted context omitted.

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 tha…

I love this because I agree 100%. I accepted the idea that they were "out there" but only really internalized it after I interviewed someone with a Masters in physics who couldn't make any progress on my simple problem. (The problem does assume you can understand the concept of a geometric line, but I give the two line equations most people first run into in junior high, among other things, I'm not testing recall.) E…

> 1) you can detect that like in the first day, or at least first week 2) the amount of damage they can do before detected is small...

But the cost is actually minimized already by rejecting in the interview. Just like finding a bug while writing unit tests is cheaper than QA finding it after you make a build, even if QA does so in the first hour of testing.

Re: Ten years of experience, still failing phone screens

#288

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…

> but for a well paying company that isn't a problem as millions of candidates gladly brushes up for the pay bump. This is the only relevant part of your comment. 90% of the tech companies out there should not rely on leetcode.

The bottom 90% cargo cult this and don't get good results doing it, yes. I'm just explaining why the top companies run this.

Re: Ten years of experience, still failing phone screens

#289

Earlier quoted context omitted.

> I wish there was a way to report bad interviewers. You can always tell the recruiter/coordinator. It's just tricky because you don't want to burn bridges, doing it before you hear back could be read as you asking for a do-over, doing it after could come across as bitter.

Recruiters don’t care. I’ve had some of the rudest interviews recently and complained to the recruiter and they completely ignored me.

Depends on the recruiter and their relationship to the company.

Re: Ten years of experience, still failing phone screens

#290

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…

"Bad leetcode, great and relevant experience" - that's me after 20 years in the industry and at least 30% of that time working on very non-trivial systems. I usually don't do actual leetcode actually, I review algo books before interviewing. In the last few years it stopped working for me even at no-name companies. But I find it nearly impossible to force myself to leetcode, it feels humiliating and stupid.

Another thing I noticed is that they stopped asking questions about concurrent code or writing recursive-decent parsers. They seem to be strangely fixated on a narrow and not particularly practical subset of CS body of knowledge. We don't discuss OOP or its alternatives anymore. Companies don't seem to care about my actual hard-won real life experience even when it directly applies to the kind of domain/system they are building.

Don't get me wrong, I expect people to know how to perform depth-first traversal or the general idea behind quick sort. But we are long past that stage even in small companies with average pay at least here in the SFBA.

Post reply on HN