Category: Interviews

So, the Vicissitudes of Interviews?

I’ve recently gone through the process of finding another job. It was quite frustrating. I thought I’d write a few comments on the various processes I went through for fun and profit.

1. The code test that was an exercise in catching people out

For the record, I’ve taught classes on how to do Test Driven Development. I’ve also been writing software professionally since I did my sandwich year in 1985, started actual coding in 1983 (in those days we didn’t have many PCs or the Internet so most people didn’t code until they got to University). I originally learned to do it in Ruby at the European Rails conference in 2008 from (if I recall) one of the people who first contributed to RSpec. I’ve also run classes and written how to in languages other than Ruby (Perl and PHP – which were both interesting). I think it’s fair to say I know what I’m doing.

So I get asked to develop something using TDD. I get comments back saying these are the worst tests the person has ever seen, and some other fairly snarky stuff. I can only conclude that they have never seen anything developed with the TDD like you mean it concept. This means you start with a test that makes sure the class just loads and all of the libraries are in place, then you work outwards from there.

I did have the flu when I did this and may have misunderstood the brief. I did the infamous one small change just before I took myself to my bed and the cut I sent to github didn’t load – I was almost seeing double at the time but it was a silly mistake.

The thing is – if I was interviewing me I would have found myself wanting to have a conversation, if the brief had been misunderstood I would want to know why because that’s an interesting conversation in itself. If I had seen an unfamiliar way of constructing the tests I would have again wanted to talk to the candidate because there may be something to learn there. The software I wrote did indeed use the API and show stuff on the screen as requested – for some reason that wasn’t right, and I don’t care enough to find out why.

For the uninitiated, a lint program is one that goes through the code and looks for common errors. It sometimes formats things as well, but not always. I used the standard gem to do linting and checking and it found nothing. I have a habit when I just hammer Ruby code into the editor of not putting in new lines except between method definitions, and even then I sometimes I don’t bother. So my Ruby code straight off the press, as it were, can sometimes look a bit dense. But you can press the return key a few times, right? You’re a grown up. I should have done this, and had a last tidy of the code but as I said I could hardly focus on the screen at the time and I just wanted to close it out.

That hurrying and not just asking for a couple more days was a mistake and I own it. I don’t own the other faults the reviewer found. I also reject entirely calling the tests poor – I used to teach this stuff, I might know more than you and have a different approach. Your ignorance is showing. You could try talking to me – I’ve been doing this stuff for nearly 40 years – have you read my CV?

After this long I can read code in a variety of languages that may not be formatted at all well and (to be honest) I don’t notice. I might run the reformat command in my editor of choice (because sometimes you see indentation move in a way that indicates code blocks are formatted but the actual syntax tells a different story).

The rude review I saw was moaning about the code not being linted – it was linted to death, buddy. You mean formatted and you don’t know the difference. If you want a new line between definitions and before blocks say so in your spec. Standard doesn’t care about that, neither does RubyMine’s formatter. Your inexperience is showing and you probably aren’t even aware of it. I mean, provide a rubocop config file and be done with it.

I definitely feel I dodged a bullet if I would have ended working with the individual who wrote that review. Maybe they were having a bad day too, but I gave up an entire weekend, feeling rough as a bear’s bum and worse and worse as time passed, and a little bit of courtesy wouldn’t have gone amiss – from their comments they spent about 5 minutes and never even attempted to understand my approach. We would probably have had a falling out eventually if they turned out as arrogant as they appear to be.

2. That Gem you wrote is all wrong

I’ve recently been playing with word games on my phone and wanted a little tool that I could give me a list of options. To that end I wrote the silly Ruby gem werds that lets you do this. It has a deliberate design choice where it loads the whole dictionary it uses into memory once so it can be interrogated over and over again from the console.

Obviously, this won’t work that well in a web context where the gem might be loaded once per request and use up lots of memory that then has to be released. But for my uses and prototyping it was fine. Future versions of the gem might even load things up into a Postgres database and use regular expressions as queries.

I put this gem on my CV, because why not? Problem is, according to someone who looked at the gem the gem was wrong. I had made a deliberate decision that I might change in future. I’m not an idiot. I’ve been doing this stuff for a very long time. But instead of having a conversation with me about that choice the gem was wrong. Err, no, it works the way it works for what I consider to be good reasons that may change later.

So they decided not to go on with the interview process after the first interview (which I really enjoyed, by the way). I started to have a conversation with the recruitment agent about this and see if I could rescue the process, but then decided I couldn’t be bothered. I don’t play games and the incident had soured things for me.

So, if I didn’t have anything on Github at all, or didn’t mention that gem it might have gone forward.

Why play some game of gotcha and demonstrate you don’t know how to talk to someone with my level of experience? What was the benefit, there? Another bullet dodged, I think.

3. The one that didn’t get away

After the initial HR has this guy only got one head and can he speak coherently interview I did a very interesting exercise with a couple of people where we talked through the potential faults and improvements we could make to some Rails controller code. It was fun and let me establish a human relationship with them.

The final stage was me doing a simple but hard enough task using TDD – we did it together and they watched and I talked through my process.

Can you see the difference here?

First, they talked to me and got to know how I think. Second, they watched my process and had me explain it to them while we worked together on something.

These people know what they’re doing and I’m really happy to be going forward with them.

If you treat interviews as some off in the distance zero sum game you will probably not be able to find candidates who either have a depth of experience you’re not used to, an approach you’ve never thought of, or any one of a number of things that could help you with being more diverse or deeper in terms of experience. It’s not school, it’s not some sport, it’s work. You will end up with candidates who look and think like you do, because that’s what your rules will pull in.

Put away the childish things and talk to people. It may appear to take longer, but when there are very few people with the skills you need you don’t want to turn down a candidate because you haven’t got a clue why they approached a problem in a way you either don’t understand, or perhaps don’t agree with. I’ve been doing this stuff for some small while now, and I never do anything without a reason I can back up.

My approach to these exercises is always code is a conversation. If you end up not wanting to talk to me I’m more than happy not to – the chances are we won’t work work together well.

I will own that if you’re not feeling well, ask for more time and try later. That one was on me.

Tumbleweed Interview Candidates

In my present role helping a team become more agile I was asked to help with some interviews. We must have talked to about ten people. The profile is relatively unusual: Object-oriented PHP with MVC and some Oracle PL/SQL. Unusual but a lot of people claim to have at least some of it.

I’ve helped conduct at least two interviews where you ask a straight question related to a claim on a CV e.g. claims about knowing Object-oriented design patterns, I get what I’ve come to call the tumbleweed response. As in what happens when someone makes an unfunny joke and there is silence. The idiom comes from the cowboy movie where the wind blows across the silent plains and makes the tumbleweed roll by; there is nothing there! (Reeves and Mortimer fans will know exactly what I mean).

So, if you are going to be interviewed by me, remember the following:

If you claim to have designed databases with hundreds of tables you should be able to explain what foreign keys and lookup tables are. Third normal form? It’s a dying art. Look it up or don’t make the claim.

If you claim to know PL/SQL then you know the difference between implicit & explicit cursors, probably what ref cursors are and what in, out and nocopy mean and why you would use them. Bonus question – what are PL/SQL tables (hint: nothing to do with database tables, it’s a language construct, so don’t start talking about database tables – it means you don’t have a clue).

SQL: inner and outer joins, foreign keys etc. Why as well as what.

If you know J2EE or Java beyond having attended a one-day course tell me what might go wrong with singletons (have a read up about serialisation)? How and why do you implement an equals method (just look it up)? Bonus question – if you have read about trying to create enumerated types in Bloch’s Effective Java are there any problems with it? Double bonus – tell me about synchronisation and the actual order statements can be executed when optimised that breaks it. It’s a feature. I’m a bastard question: why have’t you read Effective Java? Do you know what POJO is, and why does it have so much meaty goodness? (See Bootnote – some of this stuff has changed).

If you claim to be well-versed in object-oriented techniques you sure as christmas is coming need to be able to tell me the difference between has-a and is-a relationships, and why they are needed. Plus the usual stuff about abstract classes, interfaces and so on. Maybe, as a bonus question, why dynamic languages don’t need interface or abstract – or do they? I like people with opinions.

Ruby – what is duck typing? Can you explain what method_missing does? What does yield do? What’s the difference between a string and a symbol? How do you pass a block to a function – why would you? What’s a mixin and why do they taste so nice and chocolatey? Bonus: Why is the splat operator so handy?

Rails –  how does an @ variable set in the controller appear in the view? What tools to you use to test model/view/controller code separately and together? Tell me why fat model, thin controller is a good guideline. (This question also works for PHP/J2EE and whatever framework you want).

(I will think up more RoR questions – readers feel free to chip in and I will add them).

Agile: What does YAGNI mean? What does PIE mean? What is TDD? Then, of course, why? Bonus: Demeter/Tight and loose coupling/…

Patterns: Describe MVC (why as well as what). Do you know what the conductor pattern is? If you claim to know patterns such as Factory or Singleton, then expect to be asked “what does a factory give you” (concrete class that implements a known interface, like a database connector or cross-platform representation of a GUI object) or “why would you use a singleto” (global data store, or even a factory!) Bonus question – what does “concrete class” mean? Expect why questions – anyone can implement someone else’s pattern – why was it a good idea?

General Programming: How do you track production system bugs down (this is open ended – no right answer – but have some idea, please!) Why is refactoring old code generally a good idea? Or is it a bad idea? What’s refactoring anyway?

I can’t be bothered asking questions about XML but there are plenty – I leave that as an exercise for you, dear reader.

Some of these questions overlap, obviously.

Bottom line: If you claim to know something then expect to be asked about it – I will bone up on the web if I don’t know to do you the courtesy of being able to shine – I want you to succeed, honest.

Bottom line: Don’t make claims you can’t back up. Don’t waste my time.

Envoi: I don’t know is a fine answer, don’t be afraid of it. You get more respect for it. Just don’t sit there watching the tumbleweed after claiming to be a world expert on something – it makes us all so embarrassed.

Bootnote: 2015

I believe that enums are now part of Java and the daft problems where the compiler would sometimes re-order code outside of synchronized blocks have been resolved. Not so sure about the singletons not being singletons when they get moved from VM to VM problem though.