Phone Screening Junior Candidates


Phone screening junior candidates is hard. With 20+ years of experience I find it hard to evaluate someone who’s new to the field or worked less than 6 months. What I’m looking for is potential, but I can’t fall back on traditional measures where I ask for evidence of a skill. Sure they might have a beginning grasp of some language or the ability to put together a bare bones web site or iPhone app, but I really can’t drill them on OO, Domain Driven Design, or functional programming.

My approach has been to touch on some real basics to determine they’ve at least been exposed to subjects they claim on a recipe. Then I dig for stories of how they picked things up, what they learned from mistakes

Step one, is read the resume. They tend to actually be one page! Note anything I should ask them about such as basic language syntax or their explanation of TDD. Second, is take a look at any open source code you can find, often github. Ignore that it’s sloppy or untested and just take a good look at it. Then if you have time you can do some Googling and see what kind of data you can find about their participation in the community or even just questions on forums or Stack Overflow.

Next comes the actual phone screen itself. I have a stable of questions I use, a few I always use and many that I sample based on the interviewee’s experience:

  • What have you done in 2 minutes or less? (I’ll let this go over 2 minutes if I’m getting good information, but sometimes you just have to tell people you need to move onto the next question.)
  • I usually warm up with a question about the disadvantages of inheritance. This often throws junior candidates, but you can get a pretty good sense of how much OO they really understand this early in a career.
  • As I’m a die-hard TDD/BDD type I always ask them to describe how they’d write a test in their current unit test framework. A surprising number of resumes that claim to practice TDD can’t explain the syntax behind writing a rspec or Junit test.
  • I’ll often ask a question about a situation where they didn’t have enough information to complete an assignment and how they handled that. Sometimes this sort of behavioral question throws junior developers and I have to reiterate that I’m not looking for a theoretical answer.
  • Then I’ll jump around from behavioral questions to technical questions. I might ask about what an index is or what they find most challenging about their current project.
  • Almost always I include a question on how they come up to speed on new technologies. I’m looking here for anything they learned that wasn’t just presented to them in a class or at their job.
  • Finally I wrap up with a few standard questions:

  • Why do you want to work for us?
  • Is there anything else I should ask you?
  • What questions do you have for me?

Every few months I come through the questions and usually add a few and remove the ones I never ask. I still wish I had a better process, but the most common theme to come out of junior phone screens is that they’re enthusiastic and they know at least what they claim on the resume.

Kickstarter Idea: Mac OS X Package Manager

Developing on the Mac has generally been an awesome experience over the years especially with OS X and the UNIX underpinnings. The long pain point in this area is the lack of a solid supported package manager. It’s not in Apple’s DNA to worry about power users who actually use the terminal, and they’re unlikely to ever consider it important enough to delegate resources too. MacPorts and its hipster cousin Homebrew have been around for a while, but they’re always a bit rough around the edges, missing packages here and there, old versions, and sometimes they need extra tinkering just to install. In all it’s a most un-Mac like experience.

I don’t know that it will ever happen, but I know I’d support a Kickstarter that promised to maintain a Mac package manager like rpm or apt for OS X. I don’t care if they use Homebrew or Macports and just make it more robust, or build a new one from scratch. I’d just like a simple install of all those open source libraries. Yehuda Katz did a simple installer for Ruby and Rails on OS X a few years back via a Kickstarter, so I know there’s precedent and this would impact a lot more developers. Saving hassle is certainly worth some bucks for a kickstarter.

Favorite Recruiter Email Subject

I just chuckled when the I got the following email from a recruiter:

Are You Down With ATG???

Brilliant targeting as ATG barely survived the dotcom implosion and limped along before finally being sold off to Oracle. Given that almost any ATG developer would have been working in the late 90s, a reference to Naughty by Nature’s OPP was a great hook. Sadly I have zero interest in returning to work on a failed app server product, but I love the effort.

4K Programming Monitor at 30Hz

About a year ago now I acquired a Seiki SE39UY04 37″ 4K TV as a monitor. Despite the 30Hz refresh rate and once or twice a day screen reset for 5 seconds it’s the best monitor I’ve ever worked on. A 4K display is an almost infinite amount of screen real estate. I regularly have 4 files up in vim displaying over 120 lines each. At $400 dollars it was a great way to jump into 4K and wait until the really good 4K monitors show up down the line.

Pros:

  • 4 HD screens of stuff, regular have 4 1080P screens up on a single monitor.
  • If you’re not gaming the 30Hz refresh rate has much less downside.
  • It’s cheap enough that you won’t feel bad when you replace it a year or two down the road.
  • It doubles as a 4K TV.
  • After a year it hasn’t had any glitches.
  • I can remote pair and still have 60-75% of my screen available.

Cons:

  • 30 Hz is pretty noticeable at first and for gaming/fast updating.
  • To share for pairing you generally need to drop the resolution down from 4K.
  • It goes black a few times a day for a few seconds.
  • It doesn’t really sleep since it’s not a monitor.
  • Picture quality is fine for development work, but not great.
  • It’s hard to see co-workers around it.
  • If you share screens you’re constantly downsizing the resolution since almost no-one else has 4K yet.

Developer Alumni

It’s not unusual for a developer to change jobs every two or three years or even more often. Up until 2004 I had never thought of a company keeping up with you after you left or having an ‘Alumni’ concept. The consulting outfit I left had instituted an alumni program and sent me out a tiny flash stick with the company logo on it about a year after I left. It was a small thing, but I was kind of impressed they bothered with any effort at all. In addition they sent out an email every month or so with an update on how their business was going. About 6 years later I ended up back at the same company, partially because they had maintained a good relationship with me, and realized I left not so much because of them, but more for an opportunity to manage a development teams.

I came across this practice again in the most recent episode of The Front Side Podcast where they explained they were trying to build the company culture that allowed you to just tell your manager you were going on an interview. This is exactly the sort of thing to get you escorted out in many big companies, but they seem to be experimenting with having a very open and honest culture that admits, especially in consulting that many of your developers will leave at some point sometimes even over to your clients. They wanted an environment where a developer could admit they wanted a new experience the consulting business couldn’t provide and they left the door open down the road as Alumni to welcome them back.

I think it’s a great experiment and I’m honestly impressed if they can produce a company culture where an employee feels safe admitting they’re going on an interview. I love that companies are experimenting and blogging/podcasting on how it’s going. I also think the alumni idea is a great way to keep people motivated and maintain a good relationship with your local development community. I know some of the best recruiters I had were former employees who could explain why they left the company, but how it was a great opportunity if you were a good fit.