Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Part 2 of owning your hiring process. This week I talk about what my process is. What's yours?
Reblogged from Captain by Rank.
If you're going to do something, make it right and make it as good as you can. Don't waste anybody's time, especially your own. - Debra Wilson
As I discussed last week, I feel like there are a lot of issues with standard hiring practices. This week, I'm going to talk about what I've personally found to be more effective at identifying great hires, creating a healthy culture, and creating a good reputation in the industry.
First, a disclaimer. This is my process and it works best with the types of engineers I'm trying to hire. Your mileage may vary, because you maybe looking for different skills, value different behaviors more highly, etc.
As I mentioned last week, I want you to think about what your goals are for hiring as well as what message you want to send to the candidate throughout the interview process. Then, craft your process to achieve those goals.
Here are my goals:
The candidate is as relaxed as possible. Peoples' best thinking usually comes when they're relaxed, not when they're stressed.
The candidate understands that we are an open, respectful, communicative, collaborative culture with strong ownership.
The candidate understands that we don't expect them or anyone else to be perfect. No ego is involved a la "winning" the interview.
We clearly communicate to the candidate the core skills we are looking for, which is to say:
They are self directed. I can trust them to do their jobs.
They are good at communication.
They do good work.
They understand their limitations and what's achievable on a normal development schedule.
With those goals in mind, here is what my current process looks like.
First contact
This is the initial meet and greet, either over coffee or video chat. I prefer to see individuals so I can gauge relative nervousness and adjust accordingly. The goal here is for it to be fairly relaxed and casual so we can see if it's a good fit for both parties. I usually want to understand what they're passionate about, what gets them out of bed in the morning. Are they passionate about the craft of engineering, or is it just a job? Can they communicate well? I also want to know what are they looking for in a job. What sort of corporate culture do they like? I make sure to explain our culture and how they would fit in to it, so they can determine whether that is a good fit for them. The whole process should be a two way street. If that goes well, then I move on to the next step.
The take home test
In case it isn't obvious, I'm not a big fan of white board coding or "trivia" coding problems for screening candidates. I like to stretch them and give them a challenge, so instead I give people a take home test. I give them 24 hours to complete it, the test itself should take them 4-10 hours depending on how thorough they want to be. When I send them the test, I make several things very clear.
Questions are strongly encouraged.
The test should take them 4-10 hours, depending on how thorough they want to be. Therefore, they should choose a solution appropriate to the limited amount of time they have.
I'm looking for a real-world solution, not pseudo-code.
The problem itself is carefully crafted to achieve several goals, as follows:
It is intentionally vague, since that will be true of many tasks they are given. Do they ask for clarity? What questions do they ask?
It allows for multiple solutions, some of which take days, some of which take a few hours. Are they good at evaluating how long different solutions will take and choosing appropriately, given the amount of time they have?
I ask them to define how the data is laid out to get an optimal solution. My goal here is to make sure they're thinking about how data flows through the system vs. focusing on just particular algorithms or answers.
I do not have a specific requirement that the code they send me actually works. Do they compile and test it themselves, or do they send me untested code?
It can be solved with greater or lesser performance. Do they get caught in crazy complicated solutions, or do they go for simpler solutions with good performance at reasonable scale?
It tests that they understand the basics of vector algebra (this is one of those cases where I'm looking for something very specific that you might not be).
I have a few other goals too, but they're very specific to what I'm looking for with regards to skill set and ability.
The follow up questions
Once they return the test, I go over their solution and follow up with questions via email. I try to make it clear that they can take their time and craft their answers. Again, I want people to be relaxed and to think about the questions. I also want to see how well they communicate. My questions usually are along the lines of:
Why did you chose the solution you did?
How would you change your solution if the data set grew by several orders of magnitude?
How do you minimize bugs in your code?
What process do you use to communicate your status so I can trust that you know what you are doing and not have to hold your hand?
How would your solution change if you had more time?
How would your solution change if you didn't have control of the input data and it had X format?
If their test answer was good and they were able to communicate well, we would move on to the final step.
The cultural interview
This is the face-to-face portion where they meet the team and the team meets them. This portion of the process has the highest risk of sending the wrong message to the candidate, so make sure it is friendly and respectful. Interact with the candidate the same way you would an existing team member. You don't grill your co-workers, do you? So why would you do that with a potential candidate? (If you do grill your co-workers, you've probably got serious cultural issues IMO. :-p).
As part of this interview, I think it's important to talk with them about their personal processes. What's their coding standard? What are their personal philosophies around programming? What have been their biggest challenges, and how did they achieve success? Keep in mind, they are going to be nervous. Sometimes very nervous. Here's a tip. Watch their hands. If they're shaking you need to move it into a more comfortable space for them. Usually that's as simple is asking them about past achievements, what games they like to play, give them a few easy questions.
If it's all gone well, then you've got a great candidate on your hands. Hire them! Now!
Hopefully I've gotten my message across that I want you to think carefully about your hiring process, and then craft one that achieves your goals with regards to culture, engineering skills, communication skills, work ethic, etc. Don't just do what everyone else has done unless that's truly getting you what you want. Like Ms. Wilson says, if you're going to do it, do it right and stop wasting everyone's time. Until next time.
Agree or disagree with anything I’ve said? Questions? Let me know in the comments below or via Twitter, Facebook or email contact at captainbyrank dot com.
Cheers,
Shaun
Read more about:
Featured BlogsYou May Also Like
