If anything can be learned from the Milgram Experiment, it is that intentional behaviour is far easier if you are not under pressure. There are a few reasons developers might feel pressure when approaching an interview, as either the interviewer or the candidate. The ultimate goal of an interview, no matter what side of the table you sit, is to determine whether the company and the candidate are a match. The trick is making sure neither of you is so frantic that you end up creating a negative experience. The purpose of this post is to share what I have learned as both a candidate and an interviewer, and put them side by side.

Whenever people communicate, in whatever form, whether they are asking questions, telling a story or just explaining something, they are always giving away more than just the content. The delivery is so important and being calm enough to read the context as well as the content is something that I have only been able to learn from doing many interviews. Practicing and engaging empathetic communication is probably the greatest asset in an interview situation.

Due to the length of this article, I have made each sub-section collapsible. Click on the arrow to expand the section for more detail.

General guidance

This is the opportunity for first impressions and not being on time is non-negotiable. Also in the world of video conferencing it should be really easy to be on time. I have noticed that some companies do their preparation before the interview, which is fine, but you cannot leave a candidate lurking in an unknown environment (perhaps unsure if they have navigated to the correct link) because your preparation meeting is running a few minutes over.

If a candidate is a few minutes late that is obviously another story. There might have been some settings or a mix up of links or connectivity issues. However everyone should be ready to send an email to the other in case they are unsure of what is going on.

Remember to bring yourself to the interview, not someone else. What I mean by this is acceptance of who you are today and not try to be the person you think someone else might want. As a candidate it's really important because if you can accept yourself, then there is nothing the potential employer can do to take that away, and that should be calming. As an interviewer, you should not be trying to impress with your knowledge, but be awarding an opportunity for the candidate to demonstrate theirs.

  • Not all programmers are great communicators. The problem is that an interview is all about communication, verbal and non-verbal. The more you practice, the more calm and confident you will find yourself. As a candidate it's really important that you are also capable of evaluating the employer in the way they communicate. Are they on time? Are the questions the interviewers ask "Textbook" style (lack of preparation, nerves on their part)? Are the questions (candidate and interviewer) they ask relevant to the position? Also, don't prepare so much that you panic when it doesn't go as planned.
  • Be succinct. Try to answer the question fully, but not to waffle. If you read my blog, you'll notice I really struggle with that. Look for opportunities to converse about a topic, but don't overplay it.
  • Learning to code and talk is tough for a lot of people. I was very fortunate that I used to be a lecturer and so from quite early on I was coding on a whiteboard in front of as many as 500 people. It's a skill I am very grateful for having, but one I only got through practice. If you want to develop this skill, you can start by doing pair programming.
  • When coding, break down problems. I have seen so many candidates overwhelmed by the scope of a programming question. The goal is to first of all verbally deconstruct the problem into it's core elements and start on the most important part. When doing a problem breakdown, this is actually an opportunity for the candidate to get the interviewer involved and see what it would be like to work with them. Ask things like "I think x is the minimal viable product here, because the code won't work without it. Should I start coding there?" - judge their response, expand, adapt. Any great company is going to relish a curious programmer.
  • Seniority is more about soft skills like communication, empathy and decision making. Being able to code might get you through the door, but if you cannot talk about the elements of quality code or communicate design patterns and their utility, your level will be evaluated in the lower scales.
  • Be able to admit when you don't know something. Answering a question with "I don't know" can be one of the most powerful tools a candidate or human being can have. Just make sure you are ready for it. Ask follow up questions like "maybe we use different terms, can you elaborate?" or "I haven't worked with that, but I have heard of this, do you think it might be similar?" and always, ALWAYS gauge the response.

As a candidate:

This might sound a bit obvious at first glance, but a lot of the time candidates fail to even just go to the web site or use the app of the company with which they have an interview. Read up about them, look at their press outputs, see if they've appeared in the news recently. Develop an opinion and some questions. You cannot be more impressive than when you demonstrate applied knowledge.

Some companies might even provide you with an interview guide. It's essential that you read and understand this. If you walk into an interview without knowing anything about the company, or demonstrating that you didn't read the preparation guide, you are communicating a bad work ethic, or maybe a lack of attention to detail. Either way, you won't benefit from that behaviour.

Ask yourself "why this job?" - and let that fuel the questions you are going to ask. Also start preparing the answer questions like "What specifically can I bring to the company?" and "What values are important to me in an employer?"

I remember for a long time I used to complain that my employers never sent me on any training. One day an interviewer called me out on that and asked me: "What are you doing to train yourself?" At first I disliked the question, but I have realised that this specific topic is worth noting: If I am not putting any effort in, how can I expect my employer to? It also speaks of my willingness to approach management with my issues, rather than just throwing a tantrum and leaving for another job, and experiencing the same problems. In terms of training, it should be a collaborative effort that benefits both employee and employer.

Asking questions is probably one of the most important things you can do as a candidate. It tells your interviewer you are interested in the conversation and the role. It's a great tool for understanding people better and showing you aren't simply a "one person show." It's also handy for flipping a particularly difficult question:

Q: Can you tell me about the Android Activity lifecycle?
A: I know onPause, onResume, onCreate and onDestroy, I know that's not everything, but these are what I focus on in my day-to-day
Q: You're missing onStart and onStop
A: Oh, thanks, yeah I knew there was more - normally I would look that up on the documentation before using it anyway. Well, since you bring it up, how does your app use onStart and onStop? How often does the need to consider that option arise? Are developers required to know this in detail off by heart, and if so, doesn't that lead to mistakes? (This is a great question, because the official documentation does not state how onStart() should be used by developers...)

Perhaps the flurry of questions might be bad, but you can definitely use it to open up the floor and alleviate some pressure off of yourself. I also recommend flipping complexity questions around. It's not that it's a bad question, I just happen to think that it's utility in day-to-day is fairly low, and asking a question with such potential for naval gazing gives it far too much credence in an interview.

The questions you ask also say a lot about the asker. Pay attention not only to the questions, but the frequency of the topic. It works both ways so pay attention to the questions you ask and the questions that are asked of you. Try not to become too "one sided."

One of my favourite managers once told me: "Bring me a story." Having a few great stories of your experience will go a long way in demonstrating your experience in a variety of fields, not just the area of concern. While I'm not the biggest fan of the common "what's your greatest weakness" question, a good answer would probably be a short story of when I received some critical feedback from a variety of sources and then put a plan in place to make a correction. Just remember to keep it short and be honest.

Some good examples of stories to have in your repertoire:
  • Dealing with difficult people / projects
  • Failing with grace
  • Taking charge
  • Learning something new

As a candidate, I often find I am most grateful for rejections. It saves me the time and effort to have to say no myself. Very few times in my life have I interviewed for a "dream job," where the specifics of the role are so different and so uniquely fit my aspirations that a rejection would, for lack of better terms, "break my heart."

Just remember that they might have interviewed someone else for the role with more experience, or any variety of reasons that might not actually be about you. The manner in which you handle the rejection is vital. But so is the mechanism by which that rejection is delivered. Did they offer a reason? Did it sound justified? Could you ask for aspects upon which to improve? I think companies that do "blanket" rejections (e.g. "We feel you are not a fit for the role") are probably not great places to grow anyway.

As an interviewer:

The candidate is going to be judging the company on you, your behaviour and the questions you ask. It's very important that you are able to represent your company in a manner that is befitting them. It's critical that the interviewer does not create unrealistic expectations or misrepresent the company. The candidate is going to be looking for honesty.

It's very important to have some sort of plan when going in to an interview. Think about what the role needs, and then read through the CV to determine if they can meet the job requirements. Think of questions that are not simply technical, but also offer the candidate a chance to explore.

I really dislike "textbook" questions. Questions about S.O.L.I.D., Complexity Analysis, or the Activity Lifecycle are normally bland and tiresome, requiring the candidate to have done a particular type of research or experience. I find that this can often just put people in a box unnecessarily. There are good general questions, though, like the difference between an abstract class and an interface. However it should always be referenced with experience.

For example, instead of asking if they know S.O.L.I.D., and only if they do ask them to repeat Wikipedia to them, why not ask them what their experience with S.O.L.I.D. is? If they are unsure, tell them one principle and see if they can expound on the idea. This not only opens the floor to the candidate, but does not mandate they have researched every little detail in preparation for the interview. Remember the goal is not to find out what a candidate doesn't know, it's to find out their experience with the concept, and their ability to adapt.

Another example in the Java world is that of Garbage collection. The question is so standard I would recommend every candidate brush up on the version of their compiler of choice, but also interviewers should be prepared to answer any question they ask, and follow up. It's one thing for a candidate not to know the answer, but if the candidate can flip the question I think we owe them the ability to converse about it, and show themselves to be leaders.

I have found typically two types of developers: those who are great at interviews and those who are absolutely not. I think the difference is that those who are good are constantly asked to do more, and so become better, whereas others avoid it and never advance. We should always be mentoring people in the organisation. Interviewing is a skill gained through experience, and we should be delighted by the opportunity to contribute to our colleagues' development, whether they are an interviewer or a candidate. In addition, having a second person in the interview will mean that the decision does not solely rest on one person's shoulders.

I strongly recommend having a mentoring process, where the more experienced interviewer runs and drives the interview, and the less experienced person can learn. Eventually you swap roles, where the less experienced runs and drives, knowing they have the backing and safety net right there with them.

Just remember an interview is an exercise in communication. You can learn so much from candidates and their experiences. It will help you when you talk to your peers and to your management, and will demonstrate your potential in the way you reflect upon others. It might even help you reflect on how you can improve.

I have had the absolute privilege of being permitted to give immediate feedback in an interview. It is customary to ask the candidate first if they want it, but I find I am always on the lookout for an opportunity to praise or help someone. Positive feedback is always easy and a joy to give, the one that takes practice is the constructive feedback. Be able to point to direct scenarios that may help them, and why it contributed to the decision you made. Don't be mean, be offering them assistance, if they want it. And then, once you've delivered the news and the feedback, ask them to give you feedback.

Remember that if you are too nervous to tell them you will not be continuing the process while still in the interview, still offer constructive feedback face to face. If you can't offer them a job, the least you can do is leave them with the impression that you cared about them and made use of their time. Just remember if they have a bad reaction to feedback, this can inform you a lot about what it would be like to work with them.

I find candidates get overwhelmed very easily, especially at more junior levels. Even when we have it written on the code question "There are no tricks" and "We don't expect you to finish everything" - they still manage to panic and get flustered. What I do in these situations is to tell them these things verbally before showing them the question, and if I see them getting jittery, I try to offer some help or just give a small nudge: "What are you thinking?"

Red flags

If a company is going to shift the goalposts or offer you another position after you have interviewed, be careful. This might be a common pattern. Phrases like "we think you can grow into this role eventually" have the distinctive aura of carrot-chasing.

Another example of this is when you are offered far below your asking salary and they respond that they will increase it after a certain period. While that might be true, you need to ensure that you have a short-term mechanism for testing their commitment to fulfilling promises. And then you need to ensure you get promises in writing. Personally I find that this is far more effort than it's worth.

As a candidate I find it really suspicious when interviewers don't put effort into introducing themselves or getting to know me. If introductions don't matter to you, then maybe I don't either. Or if you spend too much time on yourself, and nothing on me, I am being told my value straight away.

Spend five minutes getting to know each other. Tell them your role and how long you have been working at the company. Show a bit of your personal side by mentioning a side hobby or project. Not only does this show that you care, but people are most comfortable talking about themselves and this can create a comfortable environment for the rest of what hopefully is a delightful conversation.

I've had it on a number of occasions as a candidate (at two very well known companies) that I failed the interview shortly after the programming exercise. In both situations questions about the problem were seen as attacks on the interviewer, and that the scenario was entirely realistic and should be understood and solved in silence. This screams toxic workplace environment, and it's not worth it.

I find that when interviewers have a prepared answer to their code question, they cannot understand when someone else's code works but looks different to their solution. In situations where an interviewer says "I don't know why your code works" normally means they want you to conform to their echo chamber or it could just be that they aren't that experienced at interviewing. I prefer not to have an expected solution, but evaluate the candidate's for what it is.

Conclusion

I think preparing for an interview is really difficult, because you never know exactly how it’s going to go. However if you can learn to embrace the chaotic nature and harness it, you can discover powers you never knew you had. Find strength in showing vulnerability, really put effort into making sure you are comfortable with who you are, and you will find your way. It might not be now, or at company A, B, C, or D - but keep trying. And stay curious.

This article is really long, and I think people who don't know me might be asking: "What makes you an expert on this topic?" While I don't necessary consider myself an expert, I do have many hours of experience in interviews.

I decided back in 2001 that I wanted to leave South Africa for the United Kingdom, and determined the best way to become a "stand out" candidate was to get a masters degree. This also makes it easier to get a work visa. When I graduated in 2009 I started looking for work overseas, and found it really tough. I knew nothing about immigration laws and it's was hard finding places to even consider me. It would only be the end of 2016 when my opportunity finally came through.

I decided on a two-pronged approach: work for local companies that had a global presence, and apply to international "well-known" companies. This lead to a lot of interviews on both counts. Locally, it meant I moved jobs quite a lot, because the goal was to move overseas, if the company was not working with me to achieve this goal, I felt that it was time to leave. The "problem" there is that at one point I had had 10 different jobs in 9 years!

On the international side, I would normally get flown into a country for a day or so after an initial video conference interview. I have had the privilege of interviewing at some very big tech companies, but never got the offer. It lead to a lot of reflection. For interviews, I went to the United States, Amsterdam, Finland and United Kingdom all from South Africa! The pressure was high and I would always read a book on interview techniques before arriving. The company that actually gave me the job offer to move did so after doing a "Fizz buzz" question verbally over the phone - which was quite a surprise.

At many of the jobs I have been in, I have also been tasked with conducting interviews. I started off shadowing someone, until both they and I were comfortable enough for me to take it on myself. At my current role, I am very fortunate in that I have been conducting mobile engineering interviews for 3 years across many of our international offices, and have been asked to train staff in this area on a few occasions, as well as mentoring and shadowing.