Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

331–340 of 340 posts

Re: Ten years of experience, still failing phone screens

#331
post #257

I was in agreement with most of the article, but the final footnote came out of left field for me: 7. I have a bunch of ideas around testing how quickly and how accurately people can type, or accurately transcribe text from a second screen, that I think could be decent predictors of job performance but I'm not sure are fair to test out in a professional context without academic research that could validate them at le…

Attention to detail and recall, mainly, but again I don’t think you can justify screening for it at all without additional academic research.

Maybe the accuracy of the final work product would be a fine filter for attention to detail, but as a sibling comment points out, “quick and accurate” transcription is likely to just discriminate against otherwise fine candidates.

Re: Ten years of experience, still failing phone screens

#332
post #124

I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't hav…

Would give some example questions for this? New manager here, trying to figure out hiring!

Re: Ten years of experience, still failing phone screens

#333
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…

I wish America would adopt what I've seen in some European countries -- a paradigm where they introduce a fixed-time contract first, then only hire you if they like you after the contract. I have seen that in some jobs in America, but just not programming jobs.

Re: Ten years of experience, still failing phone screens

#334

Earlier quoted context omitted.

What kind of shop are you working in which requires you to solve algorithms puzzles to resolve outages? Even if we think we see a way to solve an outage with something like this, we generally consider it inappropriate for an outage mitigation scenario, always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Implementing a better or more scalable or more r…

> always preferring to rollback / flip feature flags / add capacity / other simple and minimally invasive interventions. Sure, that's nice, but you're living in a fantasy if you expect that to always be possible. I also didn't say anything about implementing scalable or more resilient, or even algorithm puzzles. That's not what we're discussing. I'm talking about communicating when problem solving. If solving an outa…

I think talking through an algorithm puzzle solution during an interview gives you no signal at all of how well an employee would communicate in the scenario you described.

Re: Ten years of experience, still failing phone screens

#335
post #124

I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't hav…

Would give some example questions for this? New manager here, trying to figure out hiring!

Sure, Ruby on Rails. I literally start with something like:

"You've just created a new Rails app and you change into that directory. What are some of the directories and files you find at that top level?"

"What do you find in Gemfile? Gemfile.lock? What's the difference between the two?" Maybe some discussion of resolving dependencies/versions.

There are numerous "right" answers to which files/directories are at the top level and I don't care which ones they get, but they'll get some and it gets the flow going. Most of them can be taken to greater depth. If I want to guide it away from views into models, at least they know the level of detail we're working at.

Rails is a problem interview, too, because there is so much which is take it or leave it. There are Rails apps with no front end, and someone may have not worked with views for years, or the backend may be Api based and they haven't worked with models in the same way. I've worked on a project where 95% of the work was in the workers, and the user facing code was just nudging things between work states. So I use this to guide the conversations and draw out examples of their experiences when possible.

Re: Ten years of experience, still failing phone screens

#336
post #184
post #67

Earlier quoted context omitted.

same thing, same thing better spend more time maintaining those connections i myself never really practiced algorithms, so in an interview they’ll see me as a weak learner however the reality is complete opposite - i have spent thousands of hours on piano and guitar and speak 3 languages i have the opposite of learning disability and learn stuff quicker than many of your algorithm-knowing employees can

Side effect of this is probably making much less than your counterparts. If you can ace a leetcode style interview, you are much more likely to have competing offers (or retention offers later on) that allow you to make MUCH more. It’s a horrible system but just something I noticed before I got really good at them.

leaving aside the FAANG outposts in my town, I'm doing pretty good.

Re: Ten years of experience, still failing phone screens

#337
post #235

Earlier quoted context omitted.

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…

I wish America would adopt what I've seen in some European countries -- a paradigm where they introduce a fixed-time contract first, then only hire you if they like you after the contract. I have seen that in some jobs in America, but just not programming jobs.

It happens in programming jobs here but in different ways. The general style I think you're thinking of seems more likely to me for startups to try experimenting with (and more informally), but we also have a different style where you work for a general contracting agency who has you work for another company for a fixed term. Some of those after the fixed term can transform into that other company hiring you directly (and giving you higher pay not cut by the contracting company, benefits, etc. that you lacked as a contractor), or if not the contracting company helping you find a new company to contract for. The final style I can think of is already institutionalized at big companies for entry level roles in the form of hiring interns almost done with college. They work for you for a few months of the summer (often at equivalent 'hourly' salaries as a senior role) and if you like them, you offer them a full time position (at a lower entry level salary) starting next summer after they graduate. It can be a smart way to get talent that doesn't yet know it's great, or will become great, without paying a premium.

The biggest problem when hiring people with experience though, and why the probation style is pretty rare in the direct form I think you're thinking of, is that it's going to filter out the best people -- just like many other too onerous hiring practices filter them. They're just not going to put up with it when they have much better options. For Europe to the extent such a practice works at all is probably related to how universal it is for employees and employers to have a symmetric long period of notice of termination/notice of quitting that often ends up being at least a month if not 60+ days. In the US, every state is at-will, you can leave at any time and be dismissed at any time (within the bounds of certain legal protections, paranoid risk of violating which has driven larger companies to an insane PIP-style process of nudging someone out the door over a period of months). I think US companies and employees both should continue leaning in to that more as an advantage.

Re: Ten years of experience, still failing phone screens

#338
post #325

Earlier quoted context omitted.

> When one of the mediums actively helps and avoids small human errors How does it actively helps and avoids small human errors in reasoning. > I'd prefer the person knowing using it instead of sticking an old and imperfect method out of pride. What does even pride have to do with this?

> How does it actively helps and avoids small human errors in reasoning. Because reasoning is only a part of everything to be done. An IDE can help with typos, best practices ( global variables, lack of error checking, etc) which are tedious things that take time. Isn't it better to the things that matter instead?

> An IDE can help with typos, best practices ( global variables, lack of error checking, etc) which are tedious things that take time.

Which applies to everyone? Take IDE out of equation and what do you have?

Re: Ten years of experience, still failing phone screens

#339
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…

I’d hire you.

Re: Ten years of experience, still failing phone screens

#340
post #285
post #284

Earlier quoted context omitted.

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.

Yeah, that's what Leetcode is. A bar. Some people meet it, some don't.

With Leetcode, everyone starts on equal footing (there's no bias towards people who code in their free time)

Yeah, it's extremely irritating as a candidate but it's something

Post reply on HN