CTO Secrets: How to get the best companies fighting to hire you (part 3 of 3)
I recently gave a talk at the inaugural DDD East Midlands conference in Nottingham, UK. Here is a transcript of that talk, in three parts. UPDATE: the video of the original talk is now available here.
PART 3: Getting the job
Before the interview
So you’ve started hitting some of those sweet career goals, you’re making a name for yourself in the tech community as a bit of a badass, you’ve crafted a killer CV, and you’ve got yourself that plum interview. Now what?
OK, so first of all do a bit of research about the interview. Find out what the interview structure is and in particular whether there will be a technical assessment and what sort of assessment. More on that shortly.
Do at least some basic research on the company. You don’t need to be able to reel off facts about profits and what their first office dog was called. But at least be able to describe in a sentence or two what they do and why you find that super interesting.
Find out who is interviewing you. Look them up and try to assess how technical they are from their online presence or previous jobs. Do not attempt to connect with them on LinkedIn.
Have a look at Glassdoor. It might give you some clues about the culture, but also there are sometimes reports about what the interview experience was like.
Prepare some answers to behavioural questions. These are the sorts of things where you are asked how you have handled yourself in certain situations. They’re straight out of the corporate interview playbook, and you can train yourself to answer them better. Find a list online somewhere, write down bullet points against each, and just memorise as many of the bullet points as you can. Get a friend to randomly ask you similar questions until you’re confident you’re remembering enough of the bullet points.
But the main thing to remember about these behavioural questions is not that there is a right and wrong answer. Instead, view them as an opportunity to sell some of your achievements or knowledge. If you’re asked some random question like “how do you deal with conflict”, don’t answer that in the abstract, “err I try not to raise my voice” or “I’m a black belt in krav maga”.
Instead, use it as an opportunity to say something like, “I was working in a team where we had a disagreement about using SQL Server or Mongo. I could see the pros and cons of each, but one guy was arguing loudly for Mongo, so I spent half an hour writing the pitch for SQL, and we presented our boss with both options”…. or something along those lines.
And here’s the thing: it doesn’t even matter if you’ve used a bit of poetic licence. That exact scenario may never have happened in the way you describe it. As an interviewer, I don’t care. I’ve asked a question, you’ve engaged with it, you’ve managed to bring a technical angle into it, we may get to talk about that technical subject later, and I’ve learned that you understand the importance of not bringing a knife to a fist fight. Everyone is happy.
Some other prep you should do. Read your own CV carefully before you go in. Partly to remind yourself how awesome you are, and partly to remind yourself what you’ve said. I’ve lost count of the times I’ve asked someone in an interview about something they’ve claimed to be an expert in on their CV, only for them to tell me that they’ve not really used it. Those interviews didn’t last very long.
OK, listen carefully to the next three pieces of advice.
In preparation for the interview, write down the key projects that you have worked on in the last couple of years. Then write down what your contribution was that made it a success, and write down what you learned from that project.
You may think it’s pointless writing this down because it’s all in your head and you won’t forget. Well in fact, the act of writing something down accesses a different part of your brain and forces you to structure your thoughts. You are then more likely to remember it when asked about it — rather than looking like a fool, you’ll be able to crisply and eloquently describe these previous projects and what you gave to them and took from them.
Which leads me to the next thing: can you draw the architecture of the last project you worked on in 60 seconds? You would not believe the number of times I have asked someone to draw a simple visualisation — ANYTHING — of a system they were supposedly a key contributor to, and they can’t do it. With a whiteboard marker in their hand and an empty whiteboard in front of them, no matter how comfortable I try to make them feel, they turn into a blithering idiot. It might be stage fright, but what comes across is that they have never attempted to explain their work to another human being.
You might think you know in your head how your system is put together, but you will be proved wrong the first time you attempt to actually draw it in boxes and arrowed lines. So think about which project you are going to talk about the most in your interview, and practice drawing a diagram that represents it the best. And practice it again.
It might be a physical architecture diagram, or a logical system diagram, or a data flow diagram, or a sequence diagram, or a use case diagram. That’ll depend on your job and what points you want to get across. But it needs to be obvious to the interviewer that it comes very naturally to you to be able to visualise and explain a system you have worked on.
The third thing: you will often be asked what you would do differently if you had the chance for a do-over on a particular project. Think about this one in advance. Knowing what you know now, would you choose different tech or make different architectural choices? Would you put a greater emphasis on some non-functional aspect such as monitoring or performance testing? Why didn’t that happen first time around? Was it an oversight or were someone’s arguments to management not sharp enough?
I’m telling you to think about this not just so you can prepare a well-rehearsed answer. After all, you may not even get asked the question. But even just by asking yourself this question, you are training yourself to think about how you can learn from your mistakes or experiences. It may trigger a thought process about best practices and how to win the argument for adopting them.
So those last few things I mentioned are about demonstrating that you can see the bigger picture. You can move comfortably between the concrete and abstract details, and you can demonstrate ownership and personal accountability through being able to describe, visualise and reflect upon the projects you have contributed to. These all help me as an interviewer to feel confident in your ability to be net positive contributor if you join the team.
During the interview
OK, those were my tips for interview prep. Now a few words about the interview itself. I won’t dwell on this because there’s reams of stuff written on this topic, but here are a few quick pointers on what I value.
Turn up on time. I had an interviewee arrive 10 minutes late and offer no apology or explanation. I asked him, “did you have trouble finding us?”, “oh no, it was easy”. “OK, did you have a long way to come?, “no, I just live round the corner!”. Bad impression from the off.
Be polite and professional. Even if you know they have a very casual dress code, that’s not a reason to turn up in your favourite 20 year-old Napalm Death t-shirt. Little things like this matter. I once interviewed a guy who had a bag with him, and he left it open on the floor between us. I could see one condom sitting proudly at the top of his bag. Just one. Ribbed. I still wonder exactly how he thought that interview was going to pan out.
Ask about the tech culture. They should be selling this to you, but if not you should ask. Ask what they do to encourage and support the team keeping on top of the latest practices and technologies, and what they do to share knowledge in the team.
Don’t ask questions that sound like you’re a jobsworth. If you’re asking in the interview whether you can finish at 4pm every day, you may already be talking yourself out of it. If you have a specific requirement such as childcare commitments, it’s much better to bring this up once you have an offer but before you start, because they’ll be more psychologically committed to you as a candidate by then.
Remember that they want you to succeed. In most cases, they will be willing you to do well and hoping you are the right person for the job. They’ve already taken time out of their day to speak to you and have already rejected a bunch of other CVs. They’ve seen something in you they like. Take a positive mindset into the interview.
Unfortunately, there are bad interviewers. I said at the top of this talk that we all make snap judgments, and sadly that can work against you or for you. Some other bad types of interviewers are:
- The one that’s trying to catch you out or make you feel small. Usually this is because they have are having marital problems
- The one that persists with a specific question because there’s a particular thing they seem to want to hear
- The one who talks about themselves the whole time
- The one who is super friendly but doesn’t ask you any probing questions you can use to bring out your best
The best you can do in these cases is be polite and patient, but look for opportunities, little openings, to turn the conversation in a direction you want to take it. Have those bullet points about yourself and your projects that I talked about at the ready. It may or may not work, but this is where the prep pays off in an unexpected way.
Speaking of bad interviewers, you do unfortunately still get otherwise sane people asking you in interviews what your spirit animal is, or what kitchen utensil you’d like to be reincarnated as, or asking you to estimate how many grains of sand there are in the Sahara. One guy on my team had to talk for 5 minutes about a rock that was placed on the desk in front of him.
I have to admit to having tried all these things in the past. They might tell me something about your reasoning skills or your sense of humour, but I’ve concluded they are usually pretty pointless. But play them with a straight bat and answer them as best you can, because if you laugh in their face you will probably insult them, because they obviously think it’s a really clever question.
Ace the interview
Right, so I’ll repeat a few points here, but for me these things are key to delivering a great interview, rather than a decidedly OK interview.
I keep talking about having a point of view. Don’t be afraid to let that come out. Take the initiative in the interview and set out a narrative, a theme or common thread around which you can build your answers. You might want to make the case, for example, for automating as much as you can in the development pipeline. Lay that out as something you are passionate about early on, and keep referring back to that in your answers to subsequent questions. It is great to hear when someone has an opinion on the state of tech or the industry, and can speak passionately and informatively about it.
Listen to and answer the questions put to you. In doing so, try to work out why they were asking that. What were they really trying to get out of you by asking that question?
But then use their questions as springboards to get across the points you want to make that help you sell your skills and experience. Think of it like the tennis player who uses the power of the opponent’s serve to generate a cracking return, and then adds a bit of spin on top as well.
Expect the unexpected. That’s an awful cliché, but here’s what I mean. Let’s say they ask you about something on your CV that you weren’t expecting to be asked about, whether it’s a particular framework you’d forgotten about or something more leftfield. The natural response is to go on the defensive.
But again, think of these as an opportunity. Even if you give a mediocre answer, you’ve still got a free hit for you to bring up some of the attributes or skills that YOU want to talk about.
This is where it really helps if you have practised those bullet points about what you’re good at and what you’ve achieved. Because you’ll often find opportunities suddenly arising at the most unexpected time to get across some point you wanted to make, and you’ll have those little phrases and examples at the tip of your tongue just when you need them.
Try to balance confidence with humility. It’s a very British thing. We like people who are capable and intelligent, but we don’t like them to show off about it. A bit of self-deprecating humour can go a long way, used judiciously. You want to get across the message that “I’ve got this. But I don’t take myself too seriously, so other people will go along with me”.
If you’re going for a senior role, I read a great article about what companies are looking for, whether they realise it or not, when they say they want a senior.
Firstly, they want someone who is a skilled mentor. It’s not just about bringing mad skills; you need to be excited about and able to transfer those skills to more junior team members.
Secondly, they want someone who is an accelerator. Are you someone who makes things go faster, because you’re always looking at ways to optimise and improve? Or are you going to keep things as they are, or worse slow things down? Every manager in the world thinks the dev team aren’t delivering fast enough. So they want an accelerator.
Thirdly, they want someone with perspective. This often means experience, but you can gain perspective with every new thing you learn. There are always at least two sides to every story, and being able to balance off competing priorities using experience and insight is a valued skill.
Be comfortable visualising technical concepts you are talking about. Don’t be afraid to ask if you can jump up and draw it on a whiteboard. If you ask them, rather than wait to be asked, if you can draw it, you will give them a warm fuzzy feeling that you have a good handle on the big picture and are a natural explainer.
Interviewers for dev positions will listen carefully to your answers about technical debt and non-functional requirements. It’s a sore subject in most teams, and usually a source of tension between product and tech. The trick is not to come down hard on one side of the argument or guess what side you think they are likely to be on, but to demonstrate (ideally with examples) that you realise it’s a balancing act. It shows maturity and good judgment.
Nail the tech test
The tech test is where the chickens on your CV can come home to roost.
There are various flavours of technical test, and I’ve tried them all at various stages. Right now, I do a combination of a simple whiteboard test in the first interview stage to check you have got the rudimentary thinking skills, and a more in-depth coding exercise with the team if you get through to the second stage.
I’ll go through the main types of tech test you might encounter:
Standard screening test before you get an interview. I think these are generally a bad idea — it’s like they’re trying to put you off the company. I can’t give you any specific advice on how to approach these ones, other than that you can get better at them with practice.
At-home tests after you’ve already had a positive first interview. I’ve used these before, and they can be pretty useful. What I’m generally looking for here is that you a) understood the thing I’m asking you to do, and that means it’s OK for you to come back and ask questions about the challenge; b) can write solid and elegant code; and c) understand the importance of good housekeeping.
So take a bit of care with your solution, don’t rush through it. And for that last point, be sure to comment your code appropriately, even if you aren’t a big believer in doing that; write unit tests that pass; and commit to whatever repo you are using as though you were working on a team project. Clear some time in your weekend to work on it, because if you tell me you were busy and did a quick hack, I’ll assume you’re not that bothered about the job.
Locked away like a hostage in a meeting room for an hour with a challenge and a laptop. For these, before you start, ask the interviewer what success looks like; what are they are most interested in seeing from you? Are they more interested in having something working, something complete, or something well-written?
- Realistically, they might tell you to use your own judgment, but even asking them sends a good signal. If they do say that, tell them you’ll focus initially on having something working.
- In which case, you need to be disciplined about continuously compiling and running, so spend a few minutes at the beginning making sure you are set up for that.
- If they want something complete, it’s pretty much a test of your ability to hit a deadline. In this case, take a few minutes at the start to plan out your hour, and give yourself milestones to hit.
- If they want something well-written, take a few moments to consider what you want to showcase. Look for clues that suggest what they want to see — maybe it’s a particular code structure or implementation pattern. If you just dive in without considering what an elegant solution might look like, you will probably just write bad code.
Whatever your approach, explain at the end what approach you took and any assumptions or shortcuts you made.
Coding in front of a technical interviewer. For this one, you want to appeal to their instincts as a peer. They will, or at least should, appreciate you doing things like writing unit tests, perhaps even following a TDD style, observing concepts such as single responsibility principle and patterns such as dependency inversion.
They will probably also admire your pragmatism if you say, “Oooh I bet there’s an NPM package for this, can I have a look?”. In any case, the most important thing is to talk them through what you are thinking. Explain your reasoning, and if they guide you down a different path, be sure to listen.
Whiteboard coding. Don’t be deceived into thinking that you’ve dodged a bullet by not having to write working code. A good interviewer in a software company will actually ask you to solve a particularly thorny question in this format because it means you can focus on logic and reason and fundamental computer science concepts, without getting bogged down in the syntax of a particular language.
- Remember that — don’t get bogged down into writing working code. It’s a whiteboard, not an IDE. Write it in pseudo-code, or if you are more comfortable, write it in your favourite language but tell them you aren’t going to get hung up on semicolons
- If they ask, “are you happy with your solution?”, that’s often code for them saying they think there is a mistake. If you can’t see it, I’d be impressed if you started writing some pseudo tests for your pseudo code. Because this simultaneously shows you understand the importance of validating your code AND it may actually help you tease out the logical flaw if there is one.
- Also, don’t be afraid of just scrubbing it and starting again — it’s a whiteboard, that’s what they’re designed for. If you are really stuck in a rut, think about it as a TDD problem. Tell them you’re going to break it down into the smallest unit of a problem, write the simplest case that will pass, and then build on it. If you are still stuck, ask them for a clue.
As you go through your tech test, remember we’re looking for people who, in the words of Joel Spolsky, are smart and get things done. Focus on what the problem is they are asking you to solve, listen to what they are trying to guide you towards, explain your thinking, and prioritise getting to a working solution.
Thanks for listening, and I hope you found some of that useful. And of course I would be stupid not to use this opportunity to tell you: I’m hiring!
(Opinions are those of the author, not the company. All images used are copyright of the original publishers, who are too numerous to track down given the sheer volume of memes in this talk!)
