A few thoughts, from someone who has been on both sides of the interview numerous times:
On-the-spot, timed exercises tell you nothing about a dev's ability. How is it that so many experienced developers in charge of such exercises fail to consider that, if you're not taking adequate time to reason about what needs to be written, you're probably writing terrible code?
A weekend for a take home project is crap. You have a life outside of work, and it shouldn't revolve around potential work. I insist upon giving candidates a week (including, but not limited to, a weekend) to complete a take home project, which itself is no more than a few hours of work, so they have time not only to reason about the challenge in an ongoing manager, but to do it in their spare time here and there rather then a huge chunk all at once (if they decide to do that, they're free to, but it's not required).
As long as they've met (or come close to) meeting the project requirements, I follow up with a code review interview. This is where you truly learn something, by making them defend their decisions (even if part of the solution was lifted from Google/Stack Overflow/GitHub, which I'm more likely to count as a positive than a strike against them - you need to know how to Google).
Furthermore, terminology quiz interviews are crap. I've seen great devs bomb (and I've bombed plenty as a candidate even when I knew all the answers, because my mind was on actual problems I was solving at my current job), and was overruled when I said they were likely the best candidate anyway. Homie don't play dat anymore.
My first round is always conversational. The more experienced the candidate is, the more it's about trading war stories. Either way, we're talking about the tech they've been working with and how it might apply to what I'm looking to hire them for (they might have a solution I never even considered), and letting them ask plenty of questions and make suggestions for what I've already got in place. This is a phone call, so they don't have to stress with a commute to an interview (I work remotely anyway, and so will they) or worry about the feeling of being in a fishbowl during a Zoom interview.
Why? Because it's a lot easier for me to detect BS if they're at ease, and conversely it gives them a chance to make their best case on their terms.
I guess most of these companies are startup’s in “growth phase” and they care lot more about shipping out code fast, rather than making it good. They probably don’t see any value in an Engineer thinking deeply about code structure and shipping something out over 2 days, compared to someone who gets the job done in 2 hours.
I recently saw a series of videos by DHH on how he thinks about his OO code. He goes into a detailed analysis about how a variable should be named, where it should be placed, should he use a constant, should he make it private, where should the constant be in relation to the method that uses it etc... I guess DHH would find it pretty hard to get a job in Bangalore.
Yes, I believe you are right, most of these companies are in their "growth phase" & I am sure DHH will bash the companies for having this kind of interview process but I guess it is up to these companies on how they want to hire their employees.
A few thoughts, from someone who has been on both sides of the interview numerous times:
Furthermore, terminology quiz interviews are crap. I've seen great devs bomb (and I've bombed plenty as a candidate even when I knew all the answers, because my mind was on actual problems I was solving at my current job), and was overruled when I said they were likely the best candidate anyway. Homie don't play dat anymore.
My first round is always conversational. The more experienced the candidate is, the more it's about trading war stories. Either way, we're talking about the tech they've been working with and how it might apply to what I'm looking to hire them for (they might have a solution I never even considered), and letting them ask plenty of questions and make suggestions for what I've already got in place. This is a phone call, so they don't have to stress with a commute to an interview (I work remotely anyway, and so will they) or worry about the feeling of being in a fishbowl during a Zoom interview.
Why? Because it's a lot easier for me to detect BS if they're at ease, and conversely it gives them a chance to make their best case on their terms.
Wow. Exactly what I feel about hiring process especially here in India.
I Wish, I see an interviewer like you soon. ❤️
I guess most of these companies are startup’s in “growth phase” and they care lot more about shipping out code fast, rather than making it good. They probably don’t see any value in an Engineer thinking deeply about code structure and shipping something out over 2 days, compared to someone who gets the job done in 2 hours.
I recently saw a series of videos by DHH on how he thinks about his OO code. He goes into a detailed analysis about how a variable should be named, where it should be placed, should he use a constant, should he make it private, where should the constant be in relation to the method that uses it etc... I guess DHH would find it pretty hard to get a job in Bangalore.
Yes, I believe you are right, most of these companies are in their "growth phase" & I am sure DHH will bash the companies for having this kind of interview process but I guess it is up to these companies on how they want to hire their employees.
Well obviously. It's a free country. So of course they have a right to hire the way they want to.
People getting furious for some reason that "I" jad to write these assignments 😂.