3 ms·

> None of them even cared about my Github repository that's full of code I write for fun. Context: I've interviewed around 200 people for our current org, and

by nomel 3y ago

> None of them even cared about my Github repository that's full of code I write for fun. Context: I've interviewed around 200 people for our current org, and have "settled" on an interview that's used for a certain position. I don't think I'm necessarily good at interviews, and I'm not sure I'm "doing it right". I give the number to show that my sample size is reasonable. We're solving practical problems, with code. Our interview sessions are 45 minutes for each person (which is the fundamental limitation). I don't look at GitHub projects, or really ask about previous work. I used to, but I very quickly found that the vast majority of people lie on their resumes. Generally, the more senior, the more lies. Most people put bullet points of "achieved x" which end up really being "kinda helped those people who were achieving x". For GitHub, in most cases, it was obvious the person was not the author of the Github repo they gave me. They could answer questions about the code, but couldn't go into any depth about it. I found that going over previous work, or Github repos, ended up taking a huge chunk of the 45 minutes, that put each person on a different standard, somewhat of their own crafting, leaving no time to find out if they were actually able to write a for loop or not, which I've had Phd candidates, with "15 years of experience", fail to do. For feedback of the candidate, I need a tangible justification, and clear demonstration of why I say yes/maybe/no. There are no "gut feelings" allowed from the panel; you need reasons. So, I give the candidate a simple, practical, work relevant, problem to solve during the interview. No compilation, no running code, no worries about perfect syntax, and no esoteric knowledge/libraries required. They're free to use whatever language they want. It's an interview where they have to demonstrate their thought process, how they question/navigate the requirements, and ability to see consequences (which I think is 90% of programming). Maybe a few percent have finished within 10 minutes. For these people, we had fun talking about their other work, and they showed great knowledge, as expected. But, as desired, that wasn't required to do first. The interview itself proved that they would already. I would love feedback about this approach, even though it seems to be working well for our orgs needs. Ideally, I would take the Jim Keller approach, and have a nerd out session, but, I have a feeling people are more properly filtered before they would get to him.

codr7 3y ago
Wouldn't that be an excellent filter? If the candidate is lying, just move on to the next.
- nomel 3y ago
  Maybe my org is different, but I need to have confidence and justify/document my yes/maybe/no. It's very hard to prove that someone is lying, especially since you can't expect them to remember everything from some years ago. You could claim they should have tried to remember the details of their projects, but that's tricky since most people can't take code or notes with them. If I show that they have a Phd, with experience building whatever, but can't write a for loop, then I have my proof. Terms like "good thought process", etc aren't allowed in our feedback, unless specific examples are given. Terms like "team fit" will get your feedback outright rejected. No mushiness allowed.
  - codr7 3y ago
    Sounds interesting, feel free to get in touch.
OkayPhysicist 3y ago
Personally I wouldn't terribly mind such an interview, but I do know plenty of people who absolutely fall to pieces when having to code while being watched, and it's definitely not particularly pleasant to me, either. I think the best interview I've experienced was one where the "2 hour interview" consisted of me receiving an email with a short, job-related task and then after an hour was up we spoke and discussed my solution. Respected my time, as it wasn't some open-ended take-home test that somebody with too much time on their hands could spend dozens of hours polishing to perfection, while still not being quite so "whiteboard-y". With regards to Github projects and the like, I do ask about them in interviews, because I think there's a place for them as an early screening. Every engineer worth their salt has some war stories, and that's a good angle to approach their GitHub profile: if they have an interesting sounding project, asking them to talk about any interesting problems they ran into during its creation tends to make it immediately clear whether they're full of shit or not. It's not a great positive signal, but if they're not chomping at the bit to talk about engineering challenges, it's a strong negative signal.
- nomel 3y ago
  > absolutely fall to pieces when having to code while being watched Yeah, this is the biggest problem I have with it. I try to be conscious of this, and try to keep things pretty lighthearted. If I notice someone getting nervous, a "you're doing great for time" usually calms them. If not, I do follow up interview, if they did well seeking an understanding the problem, and could explain it verbally. I've had a few people pass with flying colors after a second round. > and that's a good angle to approach their GitHub profile I disagree here, with the (probably wrong) assumption that not having a GitHub profile adds a negative bias. Some people put their coding hours into work, with different lives outside of coding. All of the colleagues I've known with impressive GitHub profiles burnt out/left. Battle stories can be within corporate repos.
bhasi 3y ago
> no compilation, no running code I recently had an interview where, for the first time, the coding round was Coderpad based, which allowed me to run my code and build my solution bit by bit with instantaneous feedback. I know for sure that I wouldn't have been able to solve that recursion problem without that live terminal. I now am going to insist on this live terminal in all of my future interviews and refuse to do any that don't employ one. I think it helps my anxiety immensely.
- nomel 3y ago
  I think this is fair. But, with how simple the problem is that I give, it's a real issue if they can't read/understand the code they've written. It's simple enough that anyone should be able to mentally run the program. Regardless, I'm going to offer that as an option and see how things go. Maybe everyone will be in a better mindset, allowing me to add a bit more complexity/depth to the problem.
nomel 3y ago
I realized I've left out some detail. I'm on a panel, and I'm not one of the hiring managers. Others might be looking at resumes and repos, ideally before they make it to us. The above was to show why I, personally, don't consider them.

by nomel 3y ago

codr7 3y ago

Wouldn't that be an excellent filter? If the candidate is lying, just move on to the next.

nomel 3y ago
Maybe my org is different, but I need to have confidence and justify/document my yes/maybe/no. It's very hard to prove that someone is lying, especially since you can't expect them to remember everything from some years ago. You could claim they should have tried to remember the details of their projects, but that's tricky since most people can't take code or notes with them. If I show that they have a Phd, with experience building whatever, but can't write a for loop, then I have my proof. Terms like "good thought process", etc aren't allowed in our feedback, unless specific examples are given. Terms like "team fit" will get your feedback outright rejected. No mushiness allowed.
- codr7 3y ago
  Sounds interesting, feel free to get in touch.

OkayPhysicist 3y ago

Personally I wouldn't terribly mind such an interview, but I do know plenty of people who absolutely fall to pieces when having to code while being watched, and it's definitely not particularly pleasant to me, either. I think the best interview I've experienced was one where the "2 hour interview" consisted of me receiving an email with a short, job-related task and then after an hour was up we spoke and discussed my solution. Respected my time, as it wasn't some open-ended take-home test that somebody with too much time on their hands could spend dozens of hours polishing to perfection, while still not being quite so "whiteboard-y". With regards to Github projects and the like, I do ask about them in interviews, because I think there's a place for them as an early screening. Every engineer worth their salt has some war stories, and that's a good angle to approach their GitHub profile: if they have an interesting sounding project, asking them to talk about any interesting problems they ran into during its creation tends to make it immediately clear whether they're full of shit or not. It's not a great positive signal, but if they're not chomping at the bit to talk about engineering challenges, it's a strong negative signal.

nomel 3y ago
> absolutely fall to pieces when having to code while being watched Yeah, this is the biggest problem I have with it. I try to be conscious of this, and try to keep things pretty lighthearted. If I notice someone getting nervous, a "you're doing great for time" usually calms them. If not, I do follow up interview, if they did well seeking an understanding the problem, and could explain it verbally. I've had a few people pass with flying colors after a second round. > and that's a good angle to approach their GitHub profile I disagree here, with the (probably wrong) assumption that not having a GitHub profile adds a negative bias. Some people put their coding hours into work, with different lives outside of coding. All of the colleagues I've known with impressive GitHub profiles burnt out/left. Battle stories can be within corporate repos.

bhasi 3y ago

> no compilation, no running code I recently had an interview where, for the first time, the coding round was Coderpad based, which allowed me to run my code and build my solution bit by bit with instantaneous feedback. I know for sure that I wouldn't have been able to solve that recursion problem without that live terminal. I now am going to insist on this live terminal in all of my future interviews and refuse to do any that don't employ one. I think it helps my anxiety immensely.

nomel 3y ago
I think this is fair. But, with how simple the problem is that I give, it's a real issue if they can't read/understand the code they've written. It's simple enough that anyone should be able to mentally run the program. Regardless, I'm going to offer that as an option and see how things go. Maybe everyone will be in a better mindset, allowing me to add a bit more complexity/depth to the problem.

nomel 3y ago

I realized I've left out some detail. I'm on a panel, and I'm not one of the hiring managers. Others might be looking at resumes and repos, ideally before they make it to us. The above was to show why I, personally, don't consider them.