We’ve already covered that technical interviews are often primarily about not being too weird and that you should really try and show your working when solving programming questions in interviews.
But you should also try to make answers about technical subjects interesting.
When you’re being asked technical questions, the point is not seeing whether or not you know the right answer — the point is to get you to show off your technical skills. There’s overlap there, but those are not the same thing.
So you like databases?
Let’s find ourselves in an interview, where the interviewer has just said “Ah, I see you’ve got Postgres and MySQL on your resume”.
Here’s a plausible answer:
โIโve used MySQL for three years, Iโve used PostgreSQL, and I have used SQLite for testingโ
An answer that’s short and to the point. But it’s also entirely the wrong answer. Seriously, who cares? You said that on your resume already.
If you’ve read around this blog, you’ll know we prefer to prove, rather than simply saying, our experience. So dig up your experiences, show off your battle scars, and share your opinions!
Talk about that Unicode issue you had with MySQL where you lost three weeks because you’d chosen to use codepoints from an astral plane and MySQL didn’t support 4 byte UTF-8. Talk about how you eventually debugged that, which tools you used, and heck, why not segue into some interesting things you learned about Unicode along the way.
How about that time you thought you were being super clever by using SQLite databases to provide reusable fixtures and temporary databases for testing, even though the production DB was Postgres? It went terribly wrong, and you can explain why, and the trade-offs you made and lessons you learned.
Don’t forget the really clever solution you came up with for choosing distribution keys on Redshift, and two different ways you decided to benchmark it.
Interesting trumps right
It’s tempting to think that you should be narrowly trying to answer any question you’re asked. And if you’ve been given a specific technical challenge, that’s probably true. But most technical questions in an interview are simply exploratory, and exist solely to get you to try to show off your technical experience.
And when you’re talking about technical problems you’ve solved in the past, or talking directly from your experience, you’re showing off your technical experience. What’s more, you’re on pretty safe ground.
When you stop talking, you’ll get asked another question designed to show off your technical experience, and perhaps it’ll be on a topic you’re not so comfortable on. If your monologuing about your experiences is boring them, or there’s something specific they want to talk about, they’ll cut you off and talk about it, but otherwise, keep segueing into other things you think they’d like to hear about, and that you’re good at talking about.
Personally, I’ve got all sorts of interesting things to say about testing. So if I get asked any question that I can segue from in to a testing strategy answer, I will do that, and without shame. You want to spend as much time as you can talking about the things you really know well.
It’s not an exam
At the end of the day, remember that an interview isn’t an exam. Your resume is not a PhD thesis that you’re trying to defend. You’re trying to not appear too weird while you show off your technical knowledge. Don’t make your interviewer work too hard to dig out your technical knowledge — flaunt it by proving what you know.
