One 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…
Ten years of experience, still failing phone screens
181–190 of 340 posts
Re: Ten years of experience, still failing phone screens
#182One 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…
I consider myself an expert on lots of things I’d still need references and a bit of study to install properly.
Re: Ten years of experience, still failing phone screens
#183One 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…
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…
Imagine asking a doctor basic biology questions or what an antibiotic is used for in an interview.
Re: Ten years of experience, still failing phone screens
#184Earlier quoted context omitted.
I'm on your team. up front technical "gotcha" style evaluations feel like they don't respect where I'm coming from, nor my track record of work - and are a cue that the job is not the place I want to be at. I've gotten nearly 100% of the jobs I've gotten in the past 15 years through friends. Interview process real easy after the informal "backchannel" reference check has happened. Just hi, how you doing, when can you…
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
Re: Ten years of experience, still failing phone screens
#185Earlier quoted context omitted.
I generally write some naïve code and if it doesn't work, get out the debugger and fix it from there. I can work a lot faster when everything is laid out and I don't have to guess about what the data structures are going to look like. If it's performance sensitive like some tests I've seen, I'd use a profiler. I often use the jetbrains find and replace tool, as well as the search tool, I also like that I can click in…
A profile can’t suggest a better algorithm.
Re: Ten years of experience, still failing phone screens
#186Earlier quoted context omitted.
> Talk it out I personally hate this approach. Solving programming problems requires my full focus and vocalizing while trying to think is a challenge (partially due to my stutter). I can either focus on communicating clearly and professionally or I can stfu and code, not both. I’m happy to solve a problem silently and talk about it after I’m done, but I won’t do a phone screen that asks me to word vomit in the middl…
Can't speak of others, but when I'm doing interview I never "take points off" for not talking while coding - as long as they're building the answer in the correct direction, that's all I want. I think "talking while coding" is, at least in theory, for the benefit of the candidate - if they're "thinking aloud" and about to make a mistake which may take 20 minutes to recover, the interviewer can gently nudge them in th…
I fully expect Sr engineers to talk about why they choose the approach they do, and then implement it. I can adjust their approach while I hear about it, and then let them code it up.
This whole being silent and focus coding is bs I think. When you're doing the typing part, don't talk, just code. When you're doing the strategy part, talk. I want to see how you'll be able to express your strategy to your coworkers when a real actually challenging problem occurs.
Also. Algo problems are worthless. They only tell me you know how to cram. Don't do those, they don't actually answer anything. If I see that in an interview that's a flag for me that their eng culture might have issues. Only exception would be if you're applying to a job where you'll be doing that all day.
Re: Ten years of experience, still failing phone screens
#187By using leetcode in your interviews you are giving bad candidates an opportunity to apply for a job in your company.
Re: Ten years of experience, still failing phone screens
#188Earlier 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
#189One 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…
> 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…
Re: Ten years of experience, still failing phone screens
#190Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. In the last 4 months of job searching I've gone from barely being able to get past the question (reading under time pressure stresses me out), to convincingly passing about half of my recent phone screens. All I've done is one LeetCode per day and interviewed a couple of times per week. I'm not fundam…
> Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. That is a feature. You look at what they worked on before to see if they are senior material. Then you do leetcode and system design to see if they are smart. A smart person would most likely learn whatever tech and problems they worked on, so if they do well on leetcode you just assume they did wel…
This is the only relevant part of your comment. 90% of the tech companies out there should not rely on leetcode.