Throughout my career I’ve been frustrated with the software developer interview process from both the perspective of the interviewer and the interviewee. The process varies substantially from company to company and I don’t think anyone has it right yet. One of the problems is that people either don’t know what’s important day-to-day in the actual job the candidate will fill or they don’t focus on it. This can come from the mindset of “That interview process was really hard but I made it through and I’m a good dev, so it must be a good process.” In revamping the interviewing process for the Android teams at Hulu (insert the usual disclaimer that everything I say is my opinion and may or may not reflect Hulu’s view), I’ve focused on a few core parts.

  1. Nervousness
  2. Representative Process
  3. Character

Nervousness

First, and possibly most important, is nervousness. Virtually everyone is nervous at an interview and that’s a natural response to a high pressure situation where you know your performance is being judged. Unfortunately, this can substantially block the ability for you to adequately gauge the candidate’s ability level, so it’s vital that you do everything you can to reduce nervousness. You can’t just magically make it go away but you have to deeply inspect every aspect of your interview process to see if it’s adding undue stress.

For example, when I do phone screens for an Android developer position, I start out with an intro of who I am, what the teams are like that the candidate would work with, and important projects that the candidate might work on. This gives the candidate a chance to get out a little of those initial jitters and just listen. Then I ask the candidate to tell me a little about his or her recent experience in Android. Since there isn’t a “right” answer for this question, most people find it pretty easy to just chat and it makes the conversation just a bit more casual. On top of that, this often reveals an enormous amount about a candidate. I listen for attitude (e.g., “I hate how I always have to use the support libraries”), uncommon choices (e.g., “I wrote my own HTTP client in the app”), and general experience. Then I dig into these a little like “What made you decide to write your own HTTP client?” It’s usually bad to reinvent the wheel, but there can be specific times when it makes sense and making sure the candidate understands the tradeoffs is important. Again, since it relates to real experience, it tends to be less nerve-wracking.

When we do the coding portion of the phone screen, I immediately start out by saying something like “I know these online tools aren’t great, so I’m not worried if you have typos or missing parentheses or anything like that. I’m more interested in understanding your thought process. If you can’t remember the name of a method, just let me know that you want to do a Google search for it and that’s totally fine. You can run the code as many times as you’d like to catch anything along the way.”

I also like to start with a fairly easy real-world problem. Once the candidate works through it and is happy with the solution (and it doesn’t have any obvious flaws) I say something like “This is great and it does exactly what we needed it to. Now lets say your code is out in production and everything is good, but someone decides the API needs to change. Now your code needs to handle X. How would you update it to do that?” The whole point is to be encouraging and get the candidate to see it as a next step. Many interviewers will just say “Okay, now you need to handle X.” This can leave someone feeling like nothing was accomplished and the rules suddenly changed unfairly. If a candidate is thinking, “Why didn’t you just tell me the rules in the first place?” then the candidate isn’t spending that brainpower working on the solution.

No matter what you do, most candidates will still be nervous, but anything you can do to decrease that will help you get better insight into the candidate, which is vital for making a good hiring decision.

Representative Process

To me, representative process means that the interview process should represent the real skills that are necessary in the job day-to-day. That’s why I encourage the candidates to feel free to use Google searches both during the phone screen and when onsite; that’s what you do on the job! That also means each part of the onsite interview is meant to get at specific valuable skills. For example, one part will be whiteboarding a system. It’s essentially the high level “how do you break apart something that’s complicated into interworking pieces?” This is something that frequently happens during the actual job where we work together to discuss how to break down a new feature and how each piece will interact.

For the coding portion of the interview, I have the candidates bring their own laptop with Android Studio and a “skeleton” project (basically including the typical libraries they like to use). This lets them have a familiar development environment so they don’t get thrown off by things like suddenly not having IdeaVim (of course we also make a laptop available for candidates who don’t have one or prefer not to bring it). The task they work on during that part of the interview is reflective of a real task like interacting with an API, populating views, or managing state. I never have candidates “implement a hash table with only arrays” or “implement quicksort on a whiteboard.” I consider these CS (computer science) questions as opposed to software developer questions. They’re not representative of what a developer does and they’re ridiculously well covered in “how to interview” books and videos. That means you’ll get candidates who have memorized how to do these types of things, so you don’t get an accurate gauge of those candidates.

To me, a candidate knowing how to communicate to a product manager why the team should rethink a decision is a more valuable skill than being able to reverse a binary tree on a whiteboard. The former is a software developer skill, the latter a CS skill.

Character

Throughout the interview process, it’s important to regularly be considering how the candidate responds. When the candidates finish the initial simple problem and then you add on to it, are the candidates annoyed? When the candidates talk about why they’re leaving their previous company, is it focused on negativity? I like to have a very casual part of the interview process where I just ask about various Android topics. I might ask, “What is one thing you don’t like about Android?” A candidate who pretends everything is perfect is either being deceptive or is naive. A candidate who just complains about something for ten minutes is probably not a great fit either. A candidate who calls out a real challenge and talks about how it could be better is much more interesting.

This also gives you a chance to understand the seniority of the candidate. What you complain about with one year of experience is a lot different than with ten years of experience. Junior devs will often find fault with things they don’t fully understand. For example, it’s common to hear complaints about the Android Activity lifecycle, and it certainly introduces complexities, so it’s good to dig into how the candidate would change it. If the candidate says the Activity should just stick around all the time, then you can dig into how they’d handle configuration changes (e.g., orientation or language) or low memory situations. There are alternatives, so you want to know whether the candidate likes to think about how to make things better or just likes to complain about how things are.

Skill is important in the interview process; the reason I called out character instead is because it’s obvious that skill matters, but it’s easy to get hung up on that and forget to even think about if the candidate is someone you’d want to work with. You also want to consider how the person mixes with the existing team. You want diversity and you want to make sure the candidate’s development areas are strengths of other people on the team. You want someone who will be better tomorrow than today but will also bring that to the rest of the team.

I’d much rather work with a mid-level developer with a great attitude than a senior developer with an “everything must be my way” attitude.

Other Thoughts

A lot of people buy into the thought that the interview process should be stressful and excessively difficult. The idea is that “the job can be stressful, so we should see how the candidate handles that stress.” I disagree. Since I believe the interview process should be representative of the day-to-day, the only reason the interview process should be 100% stressful is if the position will be 100% stressful; in which case you have a different problem you should be addressing before worrying about hiring.

Many people buy into the CS-type questions. The idea is that “If a candidate can solve a pattern of interdependencies by treating it as a directed acyclic graph and do topological sorting on the fly, the candidate can easily do the day-to-day stuff” and that sort of makes sense, but consider it from another perspective. If you’re hiring someone to rebuild your roof and you have 30 minutes to gauge if that person can do the job, would you see how well the candidate can fix part of the roof or would you have the candidate hand cut dovetail joints because that’s a hard task that an excellent builder could do, so the day-to-day stuff would be easy for that person? Personally, I’d rather find out if the person knows something about working on a roof.

If nothing else, please don’t waste anyone’s time with brainteasers. Well, unless the candidate is applying for the Brain Teaser Solver position.