Comment by A4ET8a8uTh0_v2
Comment by A4ET8a8uTh0_v2 16 hours ago
The interview process in US is already insanely ridiculous, but this would only add an additional level of crazy to it. Honestly, licensing would be less bad by comparison.
Comment by A4ET8a8uTh0_v2 16 hours ago
The interview process in US is already insanely ridiculous, but this would only add an additional level of crazy to it. Honestly, licensing would be less bad by comparison.
Everything except the 30-60 minute manager call is a waste of time and money for everyone involved.
You just need to ask a couple of open-ended questions about the candidate's preferred programming language and/or some technical details of a past project they've worked on to get an idea of whether they are reasonably competent or not. It shouldn't take more than 10-15 minutes to go through. The majority of rest of the meeting can consist of the candidate asking you questions and/or chit-chatting to make sure the vibes aren't off.
What you are trying to judge is whether or not they can do the job, which you can really only tell once they are actually doing the job anyways. So you pay extra attention to what they do for the first couple of days/weeks after you've hired them and if it's obvious things are not going to work out you let them go. Most places have laws that are amenable to hiring someone on an initial trial period before stronger employee protections kick in.
In general, most of the pathologies of the hiring process can be solved by treating it as a satisfier problem instead of an optimizer problem.
There's a wide spectrum between "extremely efficient" and "insanely ridiculous". To keep it short, I think the incentives are pretty well aligned here. There's not much of an incentive for either party to waste our collective time.
I would be interested to explore a "quick hire, quick fire" philosophy, but I'm not sure it would lead to overall greater satisfaction. Employers don't like to fire people and employees don't like to be fired.
6 hours per application, plus another hundred hours of leetcode practice.
Because, let's be real, not a lot of us are writing leetcode type solutions in our shitty web devs jobs where we center a div. So we need to practice, and more importantly, memorize. Companies don't want a solution, they don't even want a good solution, they want one particular solution. That requires memorization.
The part where I have to rehearse solving ridiculous problems for a few weeks in my free time so I can perform them to the interviewer and then never use the skills again. It’s typically 2 medium/hard problems solved optimally in 20 minutes each with no errors if I want to beat the competition.
I don't think I've rehearsed for an interview ever. (And to your question in another thread, yes, I've interviewed since 2015. Multiple times, thanks to a layoff.)
> It’s typically 2 medium/hard problems solved optimally in 20 minutes each with no errors if I want to beat the competition.
I have also definitely made errors in interviews, and gotten hired. If I had to guess, it is a lot more about how you handle those. (To a degree. E.g., in one question, which was a coding challenge, I could solve it, but I was pretty sure my solution was not efficient. I voiced that, voiced why my gut was thinking it could probably be better, but I didn't ever get the full solution. In another one, I was just asked for past experience; I didn't think I had much to offer, voiced what I did have. I still to this day like the question, because it was a tough question, and the person who asked it really pressed me — in a good way, in that I could see that she took her own role/work seriously — on why I thought I was qualified.)
I've also had a call where me & the interview were definitely not connecting, at all. That wasn't going to work out, so nothing was lost?
As an interviewer,
> It’s typically 2 medium/hard problems solved optimally in 20 minutes each
… add 5 min for entry pleasantries and padding, 10 for questions for you at the end, and that's an hour, which is often all the time the recruiter schedules. And honestly, that's usually enough.
I don't ask hard problems. Easy ones sift out candidates. Where I ask coding questions, the first is almost always designed around "can the candidate write a for loop?" and the second is around basic datastructure comprehension. (Can you recognize situations that require a hashtable? a queue? and apply those to the problem.) Often a parsing question. Essentially CS 201, or easier, though I do not care if you know big-oh notation.
Most interviews I've been a part of fit that MO, and I've done interviewing with startups and with FAANG-sized companies.
> each with no errors if I want to beat the competition.
It's not about beating the competition. SWE hiring IME is never zero-sum. Two phenomenal candidates are two hires.
It can suck. I've definitely had some low points where I screw up an easy question and lost out on a place I wanted to work. I also understand that companies can't afford to make a bad hire often. My experience has been that interviewers are interested in the ability to recognize and fix mistakes, communicate about the problem, etc, and have had multiple occasions where I never even got around to filling out a couple pseudocode comments and still got passed.
Can you describe what you see as the insanely ridiculous interview process? Most of the interviews I have initiated are something like:
So for a total investment of what, 6 hours, I can go from a cold call to an offer of something like 150k-300k/y? And I'm not even playing in the FAANG ecosystem.I'm not sure if we are experiencing different processes, or we have different opinions about what kind of time / reward tradeoff is reasonable.