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)
Ten years of experience, still failing phone screens
91–100 of 340 posts
Re: Ten years of experience, still failing phone screens
#92- It makes fresh graduate noobs (or even just noobs in general) able to compete on equal ground on high-paying job prospects. Think about it, if every high paying jobs out there value experience over leetcode style of interviews, then young noob programmers won't be able to rake great salary because all of those jobs are filled already by experienced engineers
- Great engineers should just use their talent somewhere else in startups, create more innovation, create more wealth rather than helping the big tech giants become bigger
Re: Ten years of experience, still failing phone screens
#93One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well. Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo a…
Another interview I had years later, the interviewer clearly didn't think I was worth his time because he literally got up and started playing with a yo-yo as he threw challenging question after challenging question at me and pressing me harder and harder for solutions ("Imagine you were given task X and nothing more. How would you solve this? What would you do next? If that didn't work, now what would you try?") I remember it was incredibly disrespectful and left a bad taste in my mouth about the team. Thankfully I didn't get the job.
Re: Ten years of experience, still failing phone screens
#94It's fine, though. TFA goes into ways to improve the hiring process such that this sort of thing doesn't happen. But I don't mind it at all. I want to fail fast; if the company decides I'm not the right candidate, great, I'm glad it happened before we wasted time with more extensive interviews.
There are two possibilities. If they're right and I'm not a good fit, I don't want that job because I won't be successful there. If they're wrong, I don't want that job because the company isn't being successful at hiring me. The hiring process is looking for the wrong attributes, or the interviewer isn't properly trained, or... well, something, somewhere has gone wrong. There are no false negatives.
A company that's firing on all cylinders does a lot of hiring, and is good at it. They source solid candidates, and interview them thoroughly but quickly. If they're not hiring effectively, well, they're probably dysfunctional in other areas too.
Re: Ten years of experience, still failing phone screens
#95Earlier quoted context omitted.
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)
You wouldn't know if they are bad candidates because you didn't hire them.
Re: Ten years of experience, still failing phone screens
#96Earlier quoted context omitted.
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)
On the receiving end it weeded out a huge number of bad candidates. Along with (as was the main point of the original blog post) probably quite a few false negatives, Like the author of that post, for example. Meanwhile, you can achieve the same filtering benefit by far less obnoxious and more accurate means (a cursory glance at their repo, fore example).
Re: Ten years of experience, still failing phone screens
#97Earlier quoted context omitted.
> This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing. Looks like he has ADHD. Maybe somebody with more time can go through his blog post line-by-line and figure out what's going on. Most of my Coderpad stuff compiles and runs the first time, so I don't use his incremental test method, or see a need for it. Maybe he learned programming on heavy-weight IDEs and got…
Maybe you're trapped in mentally simulating a compiler and those of us with good dev setups can dedicate brainpower to other concerns?
Re: Ten years of experience, still failing phone screens
#98Interviewing 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…
What are they interviewing for, low level disk experts? While I agree that "disk" stuff is "low level" compared to a web developer, it's definitely a very relevant question. You might ask it and if the candidate is interviewing for a web developer position rephrase it after getting a blank stare: Why is it bad retrieving 50 users from a REST endpoint like `/api/users/{id}`, one at a time? Oh sure, print-based debuggi…
Sounds like a mental gymnastics to me.
Re: Ten years of experience, still failing phone screens
#99Interviewing 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…
To quote the author, > Triplebyte has a quiz that actually does a pretty good job of this; you get asked thirty or so questions about databases, networking, and simple coding questions ("what is the value of 'a' when you get to line 17?"). I could absolutely see people complaining about multiple choice questions and how you're more likely to get tripped up by minor mistakes.
Re: Ten years of experience, still failing phone screens
#100I conceptually like the idea of dropping coding screens, etc - but how do you objectively identify what you're looking for in a candidate without adding bias to the process? I.e., at least with a coding question, you can set up objective criteria. If you ask someone about their work, it might be a good experience but you're also setting yourself up to bias towards people who talk/think like you.
If you really want to test someone's coding, let them do some coding in their own time with their own tools and send it to you. This isn't ideal, since it can be time consuming, but I think it's more humane than live coding in some weird environment.