Recommendations for creating take home-tests

Recorded May 2nd 2020 – watch the full episode on YouTube.

What recommendations would you give to groups creating a good take home project to bring out the best of candidates?

Sean Allen: This is not easy. That's my first thing to say. Because I had to create the take home test to give for hiring at Aluna. You have to have this balance of finding out the stuff you want to know and how they code, but also being respectful of the candidates time. Right? Because you can easily come up with this project that's going to take 20 hours to do, right. It's a fine balance.

So, let me think back to some of the stuff I made sure I wanted to check in Aluna. Aside from the basic again, it was the hidden network, parse the JSON, make it look pretty in a collection view, but I made it so two of the views were very, very similar to the view controllers I should say. So they had to get the top 10 and then what's coming soon. It was like a movie app. So you had the top 10 movies in theaters now, and then the coming soon.

“You have to have this balance of finding out the stuff you want to know and how they code, but also being respectful of the candidates time.”

Presented, they looked the same presented, but they were just different data. I did that on purpose to see if they would reuse the view controller. Rather than just making two separate view controllers and copying and pasting the code. That was my reusability test, if you will.

What I did though, sometimes in a take home test, you'll get a specific UI design spec that you have to build to. I think that's valuable too, because you do want to know if your developer can build the spec. Right? Because I've seen people get a design spec and it looks nothing like the design, wait a minute, you need to be pixel perfect here. That's the whole point of this. There is value in testing for that on my take home test.

“So when I gave the take home test, I didn't give them any UI. I just gave a small list of requirements and said, ‘Create a product.’ And I was very specific to say, ‘Part of this test is to see how well you create products.’ Because that's important to us as a small startup.”

You need to cater this to your company, right? If your company has a designer, that's what they're going to have to do, I recommend that. What we were hiring for is, as a small startup, you need to have autonomy. You need to be able to contribute the design to this product.

So when I gave the take home test, I didn't give them any UI. I just gave a small list of requirements and said, "Create a product." And I was very specific to say, "Part of this test is to see how well you create products." Because that's important to us as a small startup. You need to be a product person, not just a type in code person. So I guess, the advice there would be to cater it towards what you actually need for the job. Don't just have a blanket, I want to see your coding abilities, right? If you need product ability, design ability, put that in your project.

Paul Hudson: I remember the very first take home project I designed for someone else to take, which is, I think it ended up six or eight folks did it. It was for iOS 4, maybe iOS five just, and it was a simple project. There was a list of picture names to show in a table view. You had navigation bar right at the top, and then tap on one to show the picture at full screen, and then share it somehow. That's pretty much it; that was the entire project. It was really, really simple. It was a goal that everyone would complete the project. It wasn't hard enough that people get stuck halfway through. But they'd come back to us and say, “here's my code.” And the value then was discussing, “how did you solve it? Why did you choose that? What happened here?” And so the discussion came out from that. “Why did you choose this class hierarchy? Why did you build this model?”

“All the value comes in the discussion. That's where we really found out the type of programmer we wanted.”

And that was interesting – why did you choose this particular feature, or this UIKit feature? It was more about architectural discussion and testing and similar.

That was the real discussion. Because that's where for me, as a hiring person, that's where the value lies. How can I get an interview into discussion space, where we can have an open chat about how we feel about MVC, or what you think about the coordinator pattern or singletons, or I don't care what. Something opinion-based. We can have a discussion, not just discussion how the specifics of Swift work, because that's a bit less interesting to me.

“I like to make the candidate make choices, like you said. Because that's the interesting part. Why did you make this choice? It's not that they have to defend their choice, but you hear their thought process on what they thought about that led them to that choice. I think that's where all the value is.”

Sean Allen: I 100% agree. The values in the discussion, how we use the project was almost like a screener. So I think I gave 10 projects, and only five of them made it to the discussion part. But the project was a good way to screen out people that you may not even want to talk to, but you're right.

All the value comes in the discussion. That's where we really found out the type of programmer we wanted. But to put a pin in this, to reiterate what you just said, and I forgot to mention is, I like to make the candidate make choices, like you said. Because that's the interesting part. Why did you make this choice? It's not that they have to defend their choice, but you hear their thought process on what they thought about that led them to that choice. I think that's where all the value is, like you said.

Sponsor Hacking with Swift and reach the world's largest Swift community!