These days I find myself interviewing quite a few candidates. Some are good, some aren’t. So it goes. However, there is another group who I feel could be good but just aren’t showing it in the interview. I think I was probably in this group earlier in my career. So, in a bid to help my younger self, and hopefully somebody else, here’s some things to consider.
1. Know the Basics
If you google ‘top 10 X interview questions’ where X is your technology, and a question is on that list you should probably know the answer. It turns out that interviewers aren’t that original so you’ll find the same questions cropping up again and again. There’s definitely a debate to be had about whether interviewers should ask more original questions, but we are where we are. At least score the easy goals.
2. Know why not (just) what
Great you know what idempotency is but why is it a useful property? There’s probably no quicker way to tell the difference between a junior who knows a lot and an experience dev than the ability to articulate why things are the way they are.
For instance, take the SOLID design principles. Uncle Bob has said that it’s about trying to create a Plugin Architecture similar to that found in, for instances, IDEs. SOLID isn’t just a bunch of sentences that you’re supposed to spout out in an interview, it’s a set of guidelines intended to achieve a certain purpose. Of course, whether it actually achieves that purpose is another matter (see 3.).
This is important for a whole host of reasons but primarily, how can you be trusted to make decisions about what technologies/approaches to take if you don’t understand their purpose.
3. Express Opinions
If a company wanted you to be a dumb vessel for received wisdom you probably wouldn’t want to work there. Just like knowing that things are they way they are for a reason, we should also know that those reasons aren’t valid in certain scenarios.
I used to ask ‘tell me one of the SOLID principle you strongly agree or disagree with’ but I had to stop because it ended up with the interviewee listing/describing the SOLID principles rather than critiquing them.
Another question I like to ask is what is a feature you would add/remove from your language of choice. If I disagree with you, that’s not an issue. Just like the songs Lennon and McCartney wrote together were better than the ones they wrote after, contrasting opinions on a team bring new insights and better decisions.
4. Listen to the Interviewer
I’m genuinely surprised at how often interviewee don’t listener to the interviewer. The question about SOLID (see 3.) is an example of not listening to the actual question which is more common than it should be. However, there is another form of not listening that’s more destructive to a candidates chances.
I’m sometimes in a practical part of the interview where a certain part isn’t going well. It’ll be a point to note, but not a deal-breaker. At that point I’m unlikely to gain any more information from that section so I’ll be keen to get to another section where I can get more useful information, and hopefully they can do better. At this point I’ll try to offer the interviewee some hints or maybe even just tell them what to move them along. However, on quite a number of occasions this advice has been flat out ignored and the candidates have kept ploughing on with whatever failing approach they were using. To put it bluntly, the initial inability may not have been a deal-breaker but ignoring advice is.
5. Be Upbeat
As a final point. A bit of enthusiasm can help a lot. You should never worry if you drop a few clangers because it’s rare that successful candidates are perfect. Probably more importantly, if you are borderline, is that you haven’t left the interviewer with the impression that they’ve been pulling teeth.
And last of all, Best of Luck!
dev with a hammer 