Live data from Hacker News

Ten years of experience, still failing phone screens

kevin.burke.dev

201–210 of 340 posts

Re: Ten years of experience, still failing phone screens

#201
post #93

Earlier quoted context omitted.

I have noticed that sense of "domination" come out in interviews as well. I remember long ago having one interview where the interviewer was asking me to code something which I knew would be impossible to complete in the time allotted. It just seemed so ridiculous to me that I was supposed to write this complete solution in about 30 minutes. I remember how superior he was acting at the start of the interview too, and…

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.

Re: Ten years of experience, still failing phone screens

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

This is how I got a job with a bunch of really smart folks in the early 2000s (they were all MIT grads and I was a graduate of a state liberal arts college in NY.) It was several rounds of interviews and a couple of the folks interviewing me (who clearly liked me) warned me that the interview at the end would be the hardest because the interviewer was an old non-nonsense engineer (MIT CS degree and MIT MBA.) It was intense for sure, but I had read somewhere that (as you stated) if you can get them to talk about themselves and engage them: A) they will love you and B) you'll run out the clock. I can't recall how I got him to talk about 'the good old days' of programming, but I did and I don't think I had to answer more than a handful of questions in that hour.

Re: Ten years of experience, still failing phone screens

#203
post #170
post #2

This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain…

Your mention of Joel's post made me curious to find and read it. I assume this is the post in question: https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... I'd say much has changed since he wrote that, and even for the time it contains some odd advice which he tries to force down the throat of the reader, but I'd be more interested to hear other's thoughts on the article.

To Joel Spolsky's defense, leet code questions where probably a great idea for him, when it was not an industry wide thing.

He also had this, what seems to me, nightmarish, dev. speed and progress estimation tracking app he made. I don't remember what blog post, but he described it and jokingly wrote that Lisa needed to get the speed up, or something. Fast forward to today and it is a predecessor to our agile nightmare. But I don't think that was his intent.

Re: Ten years of experience, still failing phone screens

#204

Earlier quoted context omitted.

It feels like the other way round to me, can you clarify why you think that a multiple choice questionnaire is more subjective than an algorithmic interview?

> I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.

But this is also common in algorithmic interviews, correct? Like if I have a sheet that says bubble sort is the answer, and you provide merge sort then you are marked wrong.

The interesting thing about mcq is that their administration is completely standardised so it's more objective in pretty much every sense.

Maybe you prefer algorithmic interviews, that's fine. But I really don't understand how you can believe that they are less subjective than algorithmic interviews.

They avoid the bias of using different interviewers which is massive, even if the questions are standard.

Re: Ten years of experience, still failing phone screens

#205

Interviewing is really tough. The OP replaced some coding questions with other questions and if he were to interview a bunch of people with them, we'd get another set of blog posts complaining how ridiculous his interview questions were. "Why is it bad to write a file to the disk one byte at a time?" What are they interviewing for, low level disk experts? "Here's a stack trace from an open source project, can you tel…

I'm not sure if you are being sarcastic or not, but I think those are some pretty excellent interview questions.

The first one, it's exactly about the thing I find a lot of developers lack in: a fundamental understanding about computers and processing. I've had 'experienced' developers write algorithms where every intermediate value was written to a cache/disk only to pull it out on the next line. I feel asking some more fundamental questions can help weed ppl out.

Same with being able to look at a stack trace and see where it went wrong, how quickly are you able to hone in on a specific target. Crucial skill imo, and I've had sooooo many people at my desk -- 'it's not working' -- that did not even read the f'ing error message.

Re: Ten years of experience, still failing phone screens

#206

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

> whether or not you communicate well

So whether you would be good at the job being hired for, then.

The whole point of the post is that the phone screen isn't just screening for deal killers. If it was you wouldn't flunk people for not nailing the optimal Big O runtime for your custom algorithm.

Re: Ten years of experience, still failing phone screens

#207
post #71
post #2

This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain…

Im not a huge fan of leetcode or work samples but on the receiving end it weeded out a huge number of bad candidates. We'd get tons of copy/pasted together infra as code from top Google results that wasn't even close to runnable (usually being close to runnable with a few small bugs was a good submission and runnable with no bugs was a great submission)

This is my experience hiring developers. If I hire without a code screen, it's a 50-50% chance the developer cannot close a ticket in their first month. With a code screen, I've had one developer not work out (personal problems). And I'm talking about "ensure that no trailing spaces are being inserted to the database in this csv import function" kind of tickets.

>usually being close to runnable with a few small bugs was a good submission and runnable with no bugs was a great submission

This is exactly what we do: check the solution, and if it's close we continue the hiring process. There is a huge difference between an almost working solution and what you get 70% of the time: code that will never, ever, ever work, even if it could run.

Re: Ten years of experience, still failing phone screens

#208

So here's my read on this, based on the post. The author is focused with technical review, and as such he probably fails to see just how important personal review is. Yes, you are being reviewed technically, but you are also being reviewed personally. You may know a lot of technical things, but do I want you on my team? The phone interview is what i'm going to use to make that decision. Technical we can work over lat…

But the author is specifically complaining about the technical phone screens using vastly inferior tools and processes than what you work with day-to-day. Being asked to write code on demand in a notepad with no way to test or compile is not a personal review, it is a monkey show.

Re: Ten years of experience, still failing phone screens

#209
post #2

This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain…

>Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing

Perhaps it's just me, but I took a look and I'm not convinced. Nothing jumps out to me as overwhelming proof of programming ability.

Re: Ten years of experience, still failing phone screens

#210

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.

It's entirely believable that many programmers couldn't write fizzbuzz without searching Google in the days before it was universally memorised. The modulo operator is somewhat rare in real code and is defined slightly differently in different languages.
Post reply on HN