The morning session I chose was run by the event sponsor 7Digital and of special interest to me a it’s something we practise at LateRooms and have recently been evolving.
Firstly we were gathered into groups of 3 and asked to each take the role of Candidate, Interviewer and Observer and each gven a crib sheet on the role. I was to be interviewed by Paul Barrett (@echodeck) with @samwessel of @esendex observing. This was a great combo as Sam and Paul both previousy worked together at Codeweavers under the tutelage of @kevinrutherford, Sam and I had worked together @esendex and we are luky enough to have @kevinrutherford currently doing a stint at Laterooms. This meant we all had a good grounding and common understanding from which to work from. We were given the Checkout Kata to perform. I have actually lost count of the number of times I have performed this kata, yet I’m still finding bigger and better ways in which to tackle it.
I performed the kata, pairing with @echodeck, with @samewessel observing and making notes. In pairing terms I was driving with Paul navigating, questioning my motivation, techniques and decisions, with Sam occasionally chipping in. We didn’t make much progress as mostly it was discussing the approach, questioning it, trying new things, deciding if they worked, backing out and getting a feel for working together. This lasted an hour and Sam made the following observations of me:
* Discussed approaches before writing any code
* knows some resharper shortcuts
* knows NUnit
* Uses BDD syntax for tests
* justifies decisions
* Mostly works back from assertions
* slow to get a running (even failing) test
* Manually renamed each reference of a field instead of using tools
* Backs out quickly when she has made a mistake
* Overly complex first test from using helper methods
* Corrected this by inlining helper methods
* Explained a decision to interviewer using a diagram
* Listened well to advice
* Asked for feedback when appropriate
* Likes to be at green 🙂
* Knows about code smells, e.g. magin numbers, primitive obsession
* Likes to take small steps
* Realised she’d not got very far
* Spotted duplication
Thankfully both Paul and Sam decided they would give me the job. Phew!
We then swapped around so that I was observing, Sam was interviewing and Paul was the candidate. This is a role in which I’m quite comfortable as we have adopted this format at work. We take notes and then use a scoring system at the end to help us document our final decision on whether the candidate was successful. This time the problem was a Fibonacci sequence generator, which was a nice change actually. I’ve not had much to do with algorithmic katas and I’m sure this is something I’m going to change!
Some of the discussion after the two pairing exercises left me with quite a bit of food for thought:
* Pair on prduction code for half a day – maybe as a follow up interview
* For more experienced developers in addition to the kata get them to work on a snapshot of legacy code which has since had a good refactor
* Environment – is it better to be in a meeting room or at a dev machine for the interview?
* Meeting room – it gives the candidate some privacy and quiet
* At dev machine – gives them a flavour of the environment they’ll be working in and doesn’t necessarily require an observer.
* Swap pair over half way through. Fresh pair will need the candidate to explain current stage and can then throw in new requirements
* 2 hours in total for interviw – 1/2 hr set up, 1 hour coding, 1/2 hour tear down
* Don’t tell the candidate it’s an hour, just in case you decide to cut the interview short.
* Get the candidate to submit a code challenge and then refactor and build upon this with them during the interview.
I’m going to discuss some of these ideas with the team when I get back, would be interested to hear your thoughts. Do you have coding as part of your interview process? Do you pair or work on submissions? Have you been interviewed in this style? What was your experience?