RayWenderlich.com just posted a list of Swift interview questions. After a quick scan though I couldn’t help but sigh. There are some interesting tidbits there that might be useful for evaluating some basic familiarity with the language. But what’s totally lacking is any context about how to use those questions to lead to a good hire. Maybe that’s not needed on a site about iOS tutorials but it’s not a discussion that I see happening anywhere else.
Don’t interview devs as if they’re writing a language. Maybe those abstruse details will help once a year. A developer who focuses on getting things done and caring about their user’s experiences will make a difference every day. Ask how they’d plan a project, what they think of a common library, what they’re proud of.
I did a lot of work in mathematical multiobjective optimization in university. That’s when you have a problem with more than one competing goal and they’re in conflict, like coding up the most efficient algorithm and getting it done ASAP. I haven’t used any of the math since but one concept approach has stuck with me.
One way to deal with multiple objectives is to decide which one goals really matters to you and what’s good enough for the rest. You optimize for the main goal and satisfice for the others. We do this all the time when coding: we implement the best algorithm in the time available. Optimize for efficiency but only if we can satisfy the time constraint.
Somehow we never think of hiring that way. We want the most technically talented developer who will make the best software who is the best fit with our team. Those are 3 very different objectives. Ability to plan, estimate, and make pragmatic decisions isn’t proportional with knowledge about Big-O notation and search algorithms. Or with how many ways there are to unwrap an optional in Swift. Or with whether they’ll be happy with our workflow.
So what happens? We fall back on the easiest thing to measure: technical knowledge. And so we implicitly optimize for it while satisficing for fit and what some would call engineering skills and some would call getting things done.
Maybe that isn’t so bad, if you’re hiring for developers to work on search algorithms or to create a new game engine or to work on the bleeding edge of image recognition. Those positions where deep knowledge of the language matter exist but they aren’t even 10% of software development jobs. If you’re hiring for that then maybe that approach is justified.
For the rest of us, technical knowledge is not the most important thing. We’ve gotta be good enough at our craft but we don’t need to churn out a compiler overnight fueled by nothing but pizza and energy drinks. It makes more sense to look for candidates that are good enough technically (or good enough to train). Make sure they understand mutability, optionals, and closures.
Then make your pick optimizing for qualities that will make your company run better. Pick the person whose code will be easy for anyone to work with. Pick the person who’ll give you an honest evaluation of how a technical decision will affect your schedule. Pick the person who knows how to get requirements nailed down. Pick the person who’ll spend their days trying to delight your users instead of impressing their colleagues.
How bout we stop saying "tech industry" and start saying "our community" since we live here and have the ability to change it.— Mikeal Rogers (@mikeal) August 25, 2015
Maybe if we explicitly acknowledge that technical chops aren’t the only thing that matter we can begin to look at what does matter in our community.
P.S. I don’t really hate those interview questions. They’re a really great resources for understanding a language where we’re really all beginners. But I do hate the culture that has experienced professionals cramming esoteric details that they never use because that’s how we’ll evaluate their competence. Doing good interviews is hard but turning them into trivia contests isn’t the answer.
P.P.S. Learning Swift? Want tutorials that will show you how to get things done without dragging you down into the inner bowels of the language? Sign up below and you’ll get