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.
Ten years of experience, still failing phone screens
201–210 of 340 posts
Re: Ten years of experience, still failing phone screens
#202Earlier 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…
Re: Ten years of experience, still failing phone screens
#203This 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.
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
#204Earlier 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.
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
#205Interviewing 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…
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…
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
#207This 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)
>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
#208So 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…
Re: Ten years of experience, still failing phone screens
#209This 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…
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
#210Earlier 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.