Note: This entire post is an enormous, link-baiting rant, and completely full of my personal opinion, but I think there might be a kernal of value somewhere in here, so I am going to post it anyway. I am also tailoring this to .NET Web developers, but most of it applies web developers of any language (I think).
I go on an interview at least once a year. I make a point keeping my interview skills as sharp as possible. This is an industry where people change jobs every 2-5 years, and layoffs could happen for no logical reason, so I want to make sure I know the job market. I am also frequently involved in hiring for my teams, so I know, first-hand, exactly how little effort, preparation and thought goes into making a hugely disruptive change to a development team.
Hiring Guide For Dev Teams
1. Know what you are looking for
The absolute first thing to do, before posting the generic, HR-approved, complete bullshit job description, asking for 7 years experience in ASP.NET 4.5, HTML 5 and jQuery 2.0 is sit down as a team and figure out what skills you value and what skills you are looking to bring into the team. Be descriptive and be realistic.
For example, if you are on an collaborative, agile team, maybe something like this:
- Strong experience in TDD
- Able to pair program 4-6 per day without burning out
- A focus on delivery
- Experience in front-end development skills to round out the teams current strength in back-end.
- Experience in responsive and fluid designs and progressive enhancement.
Notice that none of these are framework specific. We aren’t asking for a fantastic whiteboard coder, or someone who can efficiently reverse a linked list. We don’t care if you are still working in MVC 3. We don’t care if your previous experience was in AngularJS instead of KnockoutJS. Frameworks and libraries are easy for skilled devs. .NET has a generic LinkedList in System.Collections.Generics. Yes, it can reverse itself. Instead, we focus on a very specific list of what our team does well, what it values, and what we need for future projects.
- We consider TDD very important and set a high quality bar.
- We are collaborative and value pairing and understand it can be draining for some people.
- We know our skill set is back-end heavy, and that the industry is moving in a direction where front-end techniques and mobile are more important, and a new teammate can help us ramp up.
Now, write a job description that tells people what you are looking for. Include the standard framework laundry list, but put those things last. List MVC 5 and SQL Server 2014 as a nice to have. Focus the job description on what matters
2. Have the Team reach out to their networks
You are paying for referrals, right? The best chance you have for quality hires that will fit in well with your existing team members are people that they have already worked with and that they will vouch for. Ask your team to post on LinkedIn, Facebook, Google+, Twitter, etc. Encourage them to build a professional network if they don’t already have one. Ask them to mention the job at community events that they attend like code camps or meetups. Remind them that the company pays $XXXX for a quality referral. Ideally, if you can find someone without the mind-numbing agony that is the hiring process. You will remember I said this when you are reading through resumes.
3. Involve the whole team
Make sure that everyone on the team has an opportunity (snicker) to review candidate resumes, but let one or two people weed through the sea of shitty resumes. Buy them a beer afterwords for taking that hit so you didn’t have to. Put the quality ones in a pile. Spend an hour or two skimming through them as a team and toss any that someone on the team feels negatively about. You are all going to be working with this person. Make sure everyone has input. Quality people are worth the time and effort. Repeat this to yourself after you’ve read your 50th resume. Remind the team that this is what happens when we can’t hire via referral.
4. Use the phone screen effectively
You have invested a great deal of effort finding these candidates. So let’s make sure we blow it by asking a bunch of generic, easily google-able and vaguely insulting questions.
- What is the difference between an Interface and an Abstract class?
- What are the three properties of Object-Oriented design
- Name the events in order of the ASP.NET Page Lifecycle.
- What are the levels of garbage collection in the .NET framework and when do they occur?
Oh, wait. We made a list of the things we are looking for in a new developer. So, instead, maybe I’ll ask about them.
- “I noticed at job x you wrote unit tests. What frameworks did you use?”
- “So, at job x it looks like you worked with MVC 2. What challenges did you run into testing your controllers? How did you resolve them?”
- “Did you use any DI or mocking frameworks. If so, which ones? What was your experience with them?”
- “Have you ever unit tested multi-threaded code? (or something else potentially advanced) No? Ok, so how would you figure out how to?”
Four questions, focusing on something we value, tailored to a specific area of the candidates resume. No way to bullshit past this. It’s about experience and communication and depth of knowledge. Not rote memorization of Scott Hanselman’s New Interview Questions for Senior Software Engineers. If you aren’t getting the answers you are looking for or expecting, politely end the call. Don’t waste an hour of their time and yours when it is clear they don’t have what you are looking for.
Also, make sure they have time to ask you questions. Even if they don’t end up having any, leave time for them. There is literally nothing worse then coming out of a phone screen and not having a good sense of whether it is worth taking a full day off to go to an onsite interview. It wastes the candidates time and the dev team’s as well. Favor engaged candidates.
5. Give them homework
So, now you know your candidate can write a grammatically correct resume and has some experience in the things you care about. Great! Let’s make them burn a whole vacation day, schlep into our office wearing their freshly ironed interview khaki’s, and we will bounce them around in 30 minute increments between an HR rep, 5 devs, the hiring manager and the Director of App Development (Just for shits and giggles. I mean, honestly, what does he care?)
Instead, let’s give them a little homework first. Good developers like problems, especially fun problems. So, ask them to take an hour or two and build out a simple feature in a fun problem space. Blackjack, monopoly, hangman. Whatever. File | New a project and create a feature to return a shuffled deck of cards. Build a data structure that will represent a Monopoly board. Ask them to send a zip file of the code back. If they don’t want to do it, fine. They aren’t that interested in the job. Or they can’t do it. Either way.
Take a look at the code. Pass this job off to someone else on the team who didn’t just spend half a lifetime reading resumes and performing phone screens. Did the code come with passing unit tests? We did mention unit tests like six times, right? Is the structure and naming informative and maintainable? Is it intention revealing? Did they try to impress with an overly complicated implementation? Did they incorrectly use spaces and not tabs? Does it work?
6. Build something onsite
We are in an amazing position right now. Think about it. We have whittled down dozens of resumes to 2 or 3 candidates (if we’re lucky). Now, you have access to one of them for 4-8 hours. A person you might be working with 8 hours a day for years. You know they have skills you value. You have seen their code and you only said WTF 2 or 3 times. Maybe you even learned something from it.
Start them off with what they expect. 15-30 minutes with an HR rep or the hiring manager. Let them get the nerves out of the way. Then, start the real interview.
We are hiring someone to write code and conveniently, they have provided us some of there own before the interview. It seems rude not to make use of it. Come prepared with a list of features to add to our homework problem. Pair on the features, making sure to rotate out pairs frequently so that everyone has a chance to work with them. The focus here is coding, and coding as closely to the real work environment as possible. No whiteboard coding, no algorithm problems or language trivia. Just coding and pairing on a fun problem. Take frequent breaks give them a chance to play on that onsite Ping-Pong table no one uses and drink the free soda. Remember that we are trying to evaluate development skills and find out how someone interacts with the team during a workday. Few developers aren’t fried after a several hours of pairing. End the interview with a few more minutes with the hiring manager or HR.
7. Make your decision after the interview
The time to talk about each candidate isn’t after all the interviews are done, or the end of the week, or the next morning. Do it right after the interview is done. Get the team back together as the HR rep is walking your candidate from the building and decide if they are your hire. Do they have the skills you are looking for? Do they work well with the team? Look at they code that was produced. Was it high enough quality? Did we accomplish anything? What do they bring to the table? What will we have to do to bring them up to speed? Are they worth investing in? Could I work all day in a tightly enclosed cubical-farm with them?
For whatever reason, people like to draw this conversation out, especially if the answer is too not hire. Try to keep this conversation to 30 minutes. Give everyone a chance to say yes or no and why, but keep it brief. If the answer is no, then it’s no. Rinse and repeat. If the consensus is yes, then hire them and move on. There is a strong desire to believe that the next candidate might be better. Don’t believe it. They will be worse and you will be out another day. If you have found a candidate that meets your requirements and is well liked by the team, then your hiring process has worked exactly as it was intended. The grass isn’t greener. Seriously.