4 ms·
> The interviewers had zero interest I used to think the same when I started interviewing. Now I'm into the hundreds, and in my experience, that is the correct
by nomel 2y ago
> The interviewers had zero interest
I used to think the same when I started interviewing. Now I'm into the hundreds, and in my experience, that is the correct approach for a peripheral interviewer (not the direct hiring manager), and it's for your benefit.
We have 45 minutes to prove to ourselves, and our managers, and their managers, that you are the right hire. No "feelings" or "hunches" allowed: clear tangible demonstration of competence for the requirements listed, that everyone can read, and be convinced. Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected.
If I spend 30 minutes going over what you did, there are two problems:
1. Figuring out if they actually did the work, or maybe played some small part in a team, takes considerable time. It's not easy, because people are often running with inflated resumes, with the most interesting things usually being the inflation. People can have a good understanding of a project, without doing anything in that project, claiming the whole project for themselves. The path to being convinced that they actually did it ends up being very different for every candidate, and any exaggeration/lie you catch them in makes you question all of it.
2. It only gives a short amount of time to get some deterministic proof that represents the work: typing actual code to solve a problem. If something questionable comes up during then, in the little time left, you're not going to get a chance to prove it's not an issue. If that same issue shows up in anyone else's interview, without me being able to defend you, then that's it.
So, I immediately jump into my "standard" interview. It's easy. An average person will finish on time. A great person will fly through it. It checks all the boxes, gives me the proof, and even expands out into a few things that I know are sometimes questionable for others. It gives a clear yes or no for the job requirements. THEN we go into the projects with the remaining time. If you're competent, you'll have a bunch of time left, but you'll also be a strong "yes" anyways. Any cool stuff you show me will change it from a "yes" to "we need this guy, throw money at him".
If you don't like interviews, you have to blame the liars that make them the way they are. There are so many liars.
- ryandrake 2y ago> Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected. This is a very good thing because it helps to prevent bias from sneaking in, either positive or negative. Too many interviews are vulnerable to rapport and charm. "I really like and want to work with that cool bro" should not be enough justification to hire someone. Also, (at least at larger companies), when you provide feedback, you need to also reference evidence from the interview. You can't just say "Candidate X can definitely code." You have to say "Candidate X showed, through their implementation of the Linked List Reversal problem and the Towers of Hanoi problem, that they could think through a problem and express it effectively in code. Here are some examples from the code itself that show this...."