4 ms·

Any suggestions for how to improve the process? I've been conducting a lot of technical phone screens lately and I'm always interested in how to make it better

Any suggestions for how to improve the process? I've been conducting a lot of technical phone screens lately and I'm always interested in how to make it better for both parties.

justboxing 9y ago
I've been attending a lot of phone screens, and in-person interviews for a Senior Software Engineer ( C# / .Net ) Position. Here's some feedback. YMMV. 1. Don't ask questions that are hard to explain over phone. For instance I was asked if I've used Lambdas in C# and I said, "Yes, extensively.", next question was. "Explain to me what a Lambda is.". I gave the textbook definition for it, and he was expecting more, so I simply said "It's hard to explain lambdas, I can show you some source code I've written and that way I'll be able to explain it better.". I thought that was it and that I would be 'screened-out', but I was moved to the next round of on-site interviews! 2. Do ask questions about how the candidate has used the technologies that the job requires, and ask them to explain how they designed and implemented their most recent solution, and where they used what technology, and how. After initial answer, drill deep into areas that are important for the job posted, and from the answers, you can get a fairly good assessment of whether the candidate should be moved to the next stage of the process. 3. After passing the tech phone screen, I've received and completed 3 take-home coding exercises (1 each from 3 different companies), and in 1 of those companies, I was subject to white (water-) boarding exercises on site in addition to the take home test. The white boarding seldom goes well because of the environment and nature of the whole thing. I found the take home exercises to be better than on-site white-boarding because the former is closer to how a future employee would work, than the latter. Also, how a candidate does on algorithm and data structure questions is a false positive (or negative) because these can be practiced, rehearsed, perfected and hence gamed. Coding exercises, or specific question on the candidate's most recent project, on the other hand, cannot be 'gamed' and even if it was, you could tell from listening to the response, or from reading the code... Hope this helps!
- mkozlows 9y ago
  Take home is great, except people cheat. People even cheat on early screening questions knowing that an interview is coming up. (In a previous role, I gave applicants the same -- very trivial -- question that they had already coded the answer for in a do-at-home screening. I wasn't secretive about this, either, I told them that this is the exact same question they had already answered. A significant percentage of them were unable to figure out the same answer they had provided a few days earlier.)
  - jxramos 9y ago
    I like your style on this one, basically pulling out these: "I was on fire the day I solved it in the recent past, I just don't know why I can't pull it together today"
  - justboxing 9y ago
    > except people cheat. I never understood this. In a programming / software development job more than any other job, aren't you very likely to fail at delivering on the job, if you cheat on the interview and tests?
    - jldugger 9y ago
      But the money's good while it lasts, right? And you can always 'fake it until you make it' on the job too, right?
    - heartbreak 9y ago
      If cheating is defined as looking up the solution on Google, I frequently cheat while performing my job responsibilities.
  - dajohnson89 9y ago
    is take home great? if you have a full time job, any sense of home life, is being asked to code a small project in your spare time (and on a limited time basis) sane? I did two this year, and tbh I think the next company that assigns me one I'll just decline.
Jach 9y ago
I made my own minor variant of https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho... but I think it's still good advice in general and I'm fairly happy with how my version of the process has gone, given I only get 1 hour. If I had 90 mins or 2 hours I could be happier. It doesn't matter now though since higher ups at the company are deciding to revamp the process and remove all interviewer decision making from it in terms of what to ask and how to conduct things, which is probably going to be both good and bad. If you're pretty happy with your routine the next step is review. Look at candidates who passed a phone screen but were later turned down at a followup stage. Is there anything you could change about the phone screen so that the later time and money could be saved? (If you have no one who passed the screen but failed the later stage, sounds like you could just eliminate the later stage altogether.) Another interesting thing to review is candidates who didn't work out after hiring, or didn't work out as much as hoped. Again, anything at the phone screen that could have caught this? Or for those ones you can look at other stages too. One example for me is an intern that didn't work out so well, we only do a couple phone screens for them though, but still the biggest skill that was missing that I realized I could try testing for was the ability to dive into unfamiliar code they didn't write and make a few small changes at various places to fulfill some business goal. Or in other words, filter out people who can only program if they can keep the whole program in their head (which usually only works for larger things if you wrote everything yourself).

Any suggestions for how to improve the process? I've been conducting a lot of technical phone screens lately and I'm always interested in how to make it better for both parties.

justboxing 9y ago

I've been attending a lot of phone screens, and in-person interviews for a Senior Software Engineer ( C# / .Net ) Position. Here's some feedback. YMMV. 1. Don't ask questions that are hard to explain over phone. For instance I was asked if I've used Lambdas in C# and I said, "Yes, extensively.", next question was. "Explain to me what a Lambda is.". I gave the textbook definition for it, and he was expecting more, so I simply said "It's hard to explain lambdas, I can show you some source code I've written and that way I'll be able to explain it better.". I thought that was it and that I would be 'screened-out', but I was moved to the next round of on-site interviews! 2. Do ask questions about how the candidate has used the technologies that the job requires, and ask them to explain how they designed and implemented their most recent solution, and where they used what technology, and how. After initial answer, drill deep into areas that are important for the job posted, and from the answers, you can get a fairly good assessment of whether the candidate should be moved to the next stage of the process. 3. After passing the tech phone screen, I've received and completed 3 take-home coding exercises (1 each from 3 different companies), and in 1 of those companies, I was subject to white (water-) boarding exercises on site in addition to the take home test. The white boarding seldom goes well because of the environment and nature of the whole thing. I found the take home exercises to be better than on-site white-boarding because the former is closer to how a future employee would work, than the latter. Also, how a candidate does on algorithm and data structure questions is a false positive (or negative) because these can be practiced, rehearsed, perfected and hence gamed. Coding exercises, or specific question on the candidate's most recent project, on the other hand, cannot be 'gamed' and even if it was, you could tell from listening to the response, or from reading the code... Hope this helps!

mkozlows 9y ago
Take home is great, except people cheat. People even cheat on early screening questions knowing that an interview is coming up. (In a previous role, I gave applicants the same -- very trivial -- question that they had already coded the answer for in a do-at-home screening. I wasn't secretive about this, either, I told them that this is the exact same question they had already answered. A significant percentage of them were unable to figure out the same answer they had provided a few days earlier.)
- jxramos 9y ago
  I like your style on this one, basically pulling out these: "I was on fire the day I solved it in the recent past, I just don't know why I can't pull it together today"
- justboxing 9y ago
  > except people cheat. I never understood this. In a programming / software development job more than any other job, aren't you very likely to fail at delivering on the job, if you cheat on the interview and tests?
  - jldugger 9y ago
    But the money's good while it lasts, right? And you can always 'fake it until you make it' on the job too, right?
  - heartbreak 9y ago
    If cheating is defined as looking up the solution on Google, I frequently cheat while performing my job responsibilities.
- dajohnson89 9y ago
  is take home great? if you have a full time job, any sense of home life, is being asked to code a small project in your spare time (and on a limited time basis) sane? I did two this year, and tbh I think the next company that assigns me one I'll just decline.

Jach 9y ago

I made my own minor variant of https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions https://sites.google.com/site/steveyegge2/five-essential-pho... but I think it's still good advice in general and I'm fairly happy with how my version of the process has gone, given I only get 1 hour. If I had 90 mins or 2 hours I could be happier. It doesn't matter now though since higher ups at the company are deciding to revamp the process and remove all interviewer decision making from it in terms of what to ask and how to conduct things, which is probably going to be both good and bad. If you're pretty happy with your routine the next step is review. Look at candidates who passed a phone screen but were later turned down at a followup stage. Is there anything you could change about the phone screen so that the later time and money could be saved? (If you have no one who passed the screen but failed the later stage, sounds like you could just eliminate the later stage altogether.) Another interesting thing to review is candidates who didn't work out after hiring, or didn't work out as much as hoped. Again, anything at the phone screen that could have caught this? Or for those ones you can look at other stages too. One example for me is an intern that didn't work out so well, we only do a couple phone screens for them though, but still the biggest skill that was missing that I realized I could try testing for was the ability to dive into unfamiliar code they didn't write and make a few small changes at various places to fulfill some business goal. Or in other words, filter out people who can only program if they can keep the whole program in their head (which usually only works for larger things if you wrote everything yourself).