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.
Ten years of experience, still failing phone screens
331–340 of 340 posts
Re: Ten years of experience, still failing phone screens
#332I 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…
Re: Ten years of experience, still failing phone screens
#333Earlier 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…
Re: Ten years of experience, still failing phone screens
#334Earlier 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…
Re: Ten years of experience, still failing phone screens
#335I 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!
"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
#336Earlier 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.
Re: Ten years of experience, still failing phone screens
#337Earlier 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.
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
#338Earlier 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?
Which applies to everyone? Take IDE out of equation and what do you have?
Re: Ten years of experience, still failing phone screens
#339> ” 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…
Re: Ten years of experience, still failing phone screens
#340Earlier 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.
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