piątek, 6 maja 2016

iOS interviews done right

There's been a heated debate about technical interviews lately. More specifically, about whiteboard interviews. The first time I've encountered the community damning the whiteboard interviews was with loud and popular tweet by Max Howell, the creator of open source code like PromiseKit.




That's strong, isn't it? Seems like the dev community hates whiteboard interviews. Not just because they're hard, but because they're supposedly pointless and tell nothing about technical skills of the candidate.

Is that a justified opinion, or just a rant from people who failed a test ? What's the "right way" to interview developers ?

Whiteboard Interviews

You get an algorithm challenge and a marker. You're supposed to write code on a whiteboard, while other people are watching you. What does that really test ?

  • It shows that the candidate can write code under pressure - This is the biggest problem. Programming isn't about typing, or writing stuff on a board. Programming is about thinking and solving problems. How are you supposed to focus, think and solve a problem if someone is watching, evaluating and expects you to come up with a solution. I can't even program on a normal IDE when someone is watching. Solving problems with someone watching you closely is a skill, sure. Is it a skill that a good developer should have ? Hell, no! Programmers work best when left alone to think and focus in silence, or to tunes of their favorite music.
  • It shows that the candidate remembers the syntax and collections API by heart - Do experienced programmers use google frequently ? Yes! And that's completely normal. Nobody remembers everything. Swift string has a complicated API - I need google almost every time I need to do something advanced. There's a reason why sites like fuckingswiftblocksyntax.com exist. We program with auto-complete, documentation, google and syntax highlighting. It would be crazy to do otherwise. Is remembering everything by heart a clear sign of a great developer ? Hell, no!
  • It shows that the candidate has algorithms knowledge - This I can't argue with. If I had two similar candidates I'd choose the one who seems to be better at solving coding algorithm problems. It's valuable to test that in a candidate.
The first two points are really big obstacles for even the best programmers. I had one whiteboard interview and it was just awful. Writing code that's supposed to compile, on a board, is just unnatural.

How do you test candidate's problem solving and algorithm skills ? How about the normal way ? By using something like Codility, or just leaving the candidate alone for an hour, while he's solving the problem on a computer, with a normal IDE and access to documentation.

How to interview iOS developers

Testing the developer's problem solving skills is just the tip of the iceberg. 

I've interviewed a lot and I've been interviewed a lot. Testing the knowledge and experience of iOS developers in their domain is the most most important thing you can evaluate in a candidate. How do you do that ?

  • Let's start by saying that: Ignoring people with a lot of experience, open source contribution and ambitious project just because they marked 20% on a Codility test is a bad idea.
  • Let them talk about their experience. Inquire about their projects, passions, challenges, war stories. It's very important that you listen. It's a very good idea to ask technical questions relative to the candidate's experience, to verify his knowledge. It happened to me only once and it was a very positive experience: the interviewer chose and noted the technical questions as I talked about my past projects. It was valuable for both sides: the interviewer could verify the experience I described and I felt that the interviewer actually listened to me - not something that happens every often. Choose the questions for the interview accordingly to the candidate.
  • Browse iOS programming blogs for interesting and detailed questions. A candidate that knows advanced auto-layouthow stuff gets drawn on the screen under the hoodknows how runtime of his language works is a very valuable candidate.
  • Choose some fun questions to evaluate the candidate's creativity. One of my favorites is: "If you were assigned to crash an app with code, what would you write ?" or something like: "Try to think of a feature that's not allowed by Apple and would definitely get rejected by the review team".
  • I've read a lot of posts saying that giving candidates 5-10 hour demo projects is a good idea. In my opinion, making the candidates work for 10 hours for free is not optimal. If the candidate doesn't have any open source contributions, to see how they perform in coding real solutions, just have a project ready with 2 or 3 tasks to finish. It should take an hour maximum and you'll have a candidate's code example, style and architecture.
  • Assign fast simulated problems: "Please make a pseudo-diagram of architecture for app with such requirements:...", "Please design a CoreData scheme for such requirements...", "The client has reported that... What do you do?". It's a great way to see how the candidate would react in real life problems.
  • Prepare small snippets of codes with common mistakes in them and see if the candidate will be able to tell what's wrong with them. A typical example is a memory leak in a closure/block. More examples here (question 7), and here.
Unlike whiteboard coding these are all very relaxing ways of interviewing a developer. Moreover I like such interviews and I learn every time I go through one.

If you're ever in charge of creating the recruting process, please think about avoiding whiteboard coding in favor of more humane and friendly kinds of questions and challenges.