3 ms·

Can someone explain why we need: 1. A phone coding interview (Potentially another phone coding interview) 2. A homework 3. An onsite with 5 rounds Seriously,

by NTDF9 9y ago

Can someone explain why we need: 1. A phone coding interview (Potentially another phone coding interview) 2. A homework 3. An onsite with 5 rounds Seriously, what does that additional tree traversal round prove?

RickS 9y ago
I don't necessarily buy fully into all of these (I am in favor of homeworks, but they should be paid and later staged [this usually means more phone screens. can't win em all]). But since you asked: 1) because meaningfully large swaths of applicants are too stupid to fizzbuzz 2) because passing fizzbuzz is not the same as writing software 3) because teams are comprised of many people in many roles and just because team/person X likes you, doesn't mean you'll be a good aggregate fit.
- animal531 9y ago
  1. If applicants can't pass fizzbuzz then you shouldn't hire them and you can end the interview process right there. 2. Asking them to write fizzbuzz is exactly the same as asking them to write a method that does anything else, unless if they're aware of it and already knew how to do it, but of course you're asking them other questions as well? 3. Agreed, but it's impossible to match a new candidate with everyone in the company. If they're going to be working closely with person X then have that person sit in the interview for 15-30 minutes and see if they can work together on a problem.
- NTDF9 9y ago
  I will respond: 1) I don't get fizzbuzz in first coding rounds anymore. It's usually graphs 2) Ok. I write software. Your whole team can go take a look at my software. Done coding? 3) Ok, so the last on-site round should be meet and greet then? Because I already submitted my code before. You guys all should have looked at the code and agreed to bring me on-site and just meet me. Why ask me to traverse trees again?
michaelt 9y ago
Here's how it works in many companies: Hiring manager: Hey recruitment team, I've read articles saying <interview type A> doesn't work very well, we should try <interview type B>. <Interview type B> solves <concern X> Recruitment team: Sure thing, we'll start with a parallel run so we can see how <interview type A> results compare with <interview type B> Hiring manager: We've run both for a few months now, should we stop doing <interview type A> ? Recruitment team: Some hiring managers still like it, as it addresses <concern Z>. We don't see it as our job to second-guess them. You can spend your time and political capital convincing every other hiring manager, if you like? Hiring manager: I'm awfully busy with things that are a better use of my time.
cdoxsey 9y ago
It provides a diversity of opinion. You might be surprised at how much disagreement there is about most candidates. Its probably one of the few parts of the process that actually makes sense, but the fact that people rarely agree belies the deeper problems with tech interviews. The selection criteria is way too subjective and the bar at so many companies set artificially high. In my experience your best bet is still to know someone on the inside. Though even that doesn't always work. A former intern of mine was rejected for a full time job at the company because he was "shy". Mind you this was someone who built something still running in production today. I do 3 or more interviews a week and the process seems like complete nonsense. (but its my job so I do what Im asked)
- stevenwoo 9y ago
  Did they do something to correct the intern not being hired or they just wanted extroverts/loud people? I've erred on the wrong side going the other way, recall one interview on a team where I thought something was off with the candidate because they were so abrasive and then they got into a shouting match with one of my teammates (we thought they were fighting in the conference room), but when it came down to it I didn't want to be the only no and reject them. That was my fault because they turned out to really be a sociopath after a couple of months.
sidlls 9y ago
Think of these interviews as a means by which interviewers assure themselves they're working on deeply intellectual CS problems and working with people who are incredibly intellectually gifted mathematicians practing computer science (like themselves), or that they're of the same caliber as what they believe of developers at FAANG, and it begins to make more sense.

by NTDF9 9y ago

RickS 9y ago

I don't necessarily buy fully into all of these (I am in favor of homeworks, but they should be paid and later staged [this usually means more phone screens. can't win em all]). But since you asked: 1) because meaningfully large swaths of applicants are too stupid to fizzbuzz 2) because passing fizzbuzz is not the same as writing software 3) because teams are comprised of many people in many roles and just because team/person X likes you, doesn't mean you'll be a good aggregate fit.

animal531 9y ago
1. If applicants can't pass fizzbuzz then you shouldn't hire them and you can end the interview process right there. 2. Asking them to write fizzbuzz is exactly the same as asking them to write a method that does anything else, unless if they're aware of it and already knew how to do it, but of course you're asking them other questions as well? 3. Agreed, but it's impossible to match a new candidate with everyone in the company. If they're going to be working closely with person X then have that person sit in the interview for 15-30 minutes and see if they can work together on a problem.
NTDF9 9y ago
I will respond: 1) I don't get fizzbuzz in first coding rounds anymore. It's usually graphs 2) Ok. I write software. Your whole team can go take a look at my software. Done coding? 3) Ok, so the last on-site round should be meet and greet then? Because I already submitted my code before. You guys all should have looked at the code and agreed to bring me on-site and just meet me. Why ask me to traverse trees again?

michaelt 9y ago

Here's how it works in many companies: Hiring manager: Hey recruitment team, I've read articles saying <interview type A> doesn't work very well, we should try <interview type B>. <Interview type B> solves <concern X> Recruitment team: Sure thing, we'll start with a parallel run so we can see how <interview type A> results compare with <interview type B> Hiring manager: We've run both for a few months now, should we stop doing <interview type A> ? Recruitment team: Some hiring managers still like it, as it addresses <concern Z>. We don't see it as our job to second-guess them. You can spend your time and political capital convincing every other hiring manager, if you like? Hiring manager: I'm awfully busy with things that are a better use of my time.

cdoxsey 9y ago

It provides a diversity of opinion. You might be surprised at how much disagreement there is about most candidates. Its probably one of the few parts of the process that actually makes sense, but the fact that people rarely agree belies the deeper problems with tech interviews. The selection criteria is way too subjective and the bar at so many companies set artificially high. In my experience your best bet is still to know someone on the inside. Though even that doesn't always work. A former intern of mine was rejected for a full time job at the company because he was "shy". Mind you this was someone who built something still running in production today. I do 3 or more interviews a week and the process seems like complete nonsense. (but its my job so I do what Im asked)

stevenwoo 9y ago
Did they do something to correct the intern not being hired or they just wanted extroverts/loud people? I've erred on the wrong side going the other way, recall one interview on a team where I thought something was off with the candidate because they were so abrasive and then they got into a shouting match with one of my teammates (we thought they were fighting in the conference room), but when it came down to it I didn't want to be the only no and reject them. That was my fault because they turned out to really be a sociopath after a couple of months.

sidlls 9y ago

Think of these interviews as a means by which interviewers assure themselves they're working on deeply intellectual CS problems and working with people who are incredibly intellectually gifted mathematicians practing computer science (like themselves), or that they're of the same caliber as what they believe of developers at FAANG, and it begins to make more sense.