As part of a big company, we’re limited to the traditional pattern (resumes, interviews and whiteboards, oh my!) - unfortunately, we can’t do a 40 hour test project. But there are better and worse ways to do a traditional interview, and this post outlines my current thoughts.
If you’re looking for a job, consider this a guide - “how to get my hire recommendation”. Read it, follow it, send me a resume, and mention this post for ten bonus points.
(Disclaimer: Bonus points are fake. I’m one developer of many, so YMMV if you interview here. This post is also a “how we should hire” case to my teammates.)
Code, if you’ve got it
The entire process becomes much easier if I can review some of your code before the interview. Open source, class project, side business, whatever - just send me a github link to something production-quality. This lets me skip the boring “can-you-code-at-all” questions, and turn the interview into a code review. We’ll sketch your architecture on the whiteboard, talk about design choices, maybe sketch out a new feature to bolt onto the project. It does not have to be perfect (all code sucks in its own way). Just having something that works puts you head and shoulders above most candidates.
But most people don’t have recent code samples to demonstrate. Many of the best candidates are not seriously looking, just kicking the tires for better gig. If you’ve got no code, that’s not a disqualification, but it means we need to spend time on the basics.
The Basics
The first question is, can you program at all? So we’ll ask something like FizzBuzz in a phone screen.
Then we’ve got to check for a basic understanding of our technical stack - relational database, Ruby, Rails, and Javascript. I’ll outline a very basic app, like a single-item online store, and ask for a database schema. With that 3-4 table schema, we’ll write some SQL queries, then some light ActiveRecord classes. I’ll describe a page in the system, and we’ll write out the simplest possible HTML, and do some Javascript transformations on it.
A “full-stack” developer should get through these questions quickly. Holes in your knowledge may be ok, but even a front-end developer should be able to hand-wave some kind of database schema, and even a back-end specialist should know what jQuery is.
The Meat
Now that we’ve established some level of bona fides, my goal is to get into a design discussion, code review, or outright debate, just like we would have as teammates. We might start with something on your resume - “You wrote feature X, how does that work?” Or we’ll start with a theoretical discussion - “Users complain that a page is slow, where do you start?”
At this point, feel free to blatantly manipulate the discussion - “Let me tell you about this awesome feature I wrote…” I want to know what you’ve done, what tradeoffs you made, and what other designs you considered. War stories of horrendous code are great - I want to know what you find ugly, and how you handled it. If you’re in love with a particular architecture pattern, tell me about it.
In the middle of this discussion, we need to talk a bit about “soft factors”. How do you work with your current teammates? Have you ever used strict by-the-books Scrum? How about grab-this-ticket-whenever informal “process”? What do you prefer, and why? What kind of problems have you had with coworkers? Honestly, I don’t have an agenda or a list of questions on these factors, but they are considerations in the hiring decision.
Conclusion
The ultimate goal is to establish three things: Can you deliver working code? Will you make our codebase better? Will you make our team better, by teaching, learning, getting along, and encouraging others?
I’ve outlined one process to establish these factors - but it’s certainly not the only one. If you’ve got a better idea, drop me a line.