What Your Future Employer Is Looking For in a Technical Interview

It’s often frustrating to see good candidates coming to a technical interview without any preparation, or without any context about the position. Although a lot of technical skills require years of experience to master, there are a few areas that you can expect to cover in an interview according to your level of seniority. If you know what’s coming, you’ll be able to set yourself up well, and improve the impression you make at the interview. Let’s take a look at them.

I’ve been involved on the hiring side of the technical interview process for 15 years. Technical job interviews can be daunting, especially if you are new to interviews, are looking to move into a more senior position, or are looking to move into a different tech stack. There will usually be more than one interviewer, and it’s likely that at least one senior interviewer will have more experience than you do.

But from my experience, knowing what to expect can help you reduce your anxiety, help you show your true potential, and help you feel more comfortable throughout the process.

Technical interviews aren’t just about assessing your technical skills; as someone being interviewed, it’s important to understand what these are so that you know what answers they’re looking for at each point.

The first objective of an interview is - for the want of a better phrase - to ‘get the lay of the land’, and to test your soft skills. The interviewer wants to find out:

• Have you done your homework?
• Do you know what you’re getting into?
• Who you are as an individual, and whether you’ll be a good culture fit for the team and organisation
• Your ability to work under pressure and keep a cool head
• Your ability to communicate with the team

Soft skills are something you need to develop into good habits in every aspect of life, and is not something I will cover in this article.

The interview process then shifts focus and turns to your cold, hard skills:

• Your previous experience and education
• Your ability to demonstrate real understanding and mastery of languages and technologies
• Your ability to solve problems under pressure

When applying for high-end positions in software, even if your watercooler small-talk, your dress code, and your table manners are flawless, it’s the second part of the technical interview that will determine if someone gets the job or not.

Considering that every interview will be different from the next, it’s hard to predict what will be ‘right’ and ‘wrong’ for your situation.

Instead, what I’m trying to do with this article is to present the common themes that technical interviewers look for with regards to those ‘hard’ skills. Let’s take a look at some areas you should be comfortable with, and some things not to do:

The “hard” skills: What to know

Once you’ve proven that you’re a ‘nice guy’ and a dependable team-player during the earlier stages of the interview process, technical interviewers will, invariably, move on to probe your skills and experience as a professional software developer.

More than anything, demonstrating your skill will differentiate you from the crowd, and will also convince the interview panel of your level of seniority.

That said, it can be hard to know what skills need to be demonstrated. I’ve broken down a few areas that I’ve learned most interviewers will be looking for:

• Basic computer science skills
• Supporting disciplines and software engineering processes
• Senior skills
• Skills for positions requiring Design and Architecture experience

#1: Basic computer science skills

Even if you didn’t study a CompSci degree at university, your chances at impressing at your interview are much higher if you’re more than comfortable with the basics. You’ll not only be able to focus on the more advanced questions and topic areas later on, but you’ll also put yourself in a better frame of mind. The kinds of things an interviewer might ask about include:

Data structures: Picking the right tool for the job shows skill. So, you should aim to understand why specific structures are better suited to certain tasks. All modern languages have a full spectrum of tools such as Arrays, Sets, Bags, Queues, Stacks, Maps and Binary Trees - but when do you use each one?

Language constructs: In addition to ensuring that you know your ‘home’ languages well, take time to understand constructs in languages that you might not be familiar with. It’s no secret that modern computer languages plagiarise new, useful features from each other, and being familiar with a range of them will help to deal with anything that is thrown at you.

Object Oriented Programming: This is still the go-to paradigm in 2019. Although the academic nature of the original “Three Amigos of OO” has somewhat waned over time, Uncle Bob’s SOLID paradigm is as important as ever, especially when building code which is robust, decoupled, and most importantly, testable.

Algorithmic time and memory complexity: Knowledge of Big O complexity will gain you a lot of respect when dealing with performance computing. Being able to explain the complexity of nested loops, collision-free hashmap lookups, and common sorting algorithms will gain you a lot of credibility.

Memory allocation and use: Although most modern languages provide garbage collection, it is still important to understand how memory is allocated and used. Be able to explain concepts such as value types, reference types, and passing by reference.

#2: Supporting disciplines and software engineering processes

Depending on the company and the role you’re applying for, the interviewer might also be looking for some kind of insight or knowledge about other, supporting disciplines - after all, there’s more to delivering quality software than just writing code.

Unit, Integration and other Automated Testing: Seal the deal with familiarity with at least one mocking framework, and the knowledge of how to execute the tests into your Continuous Integration build cycle. Many believe that a good developer, during the completion of each new feature, always pays it forward by leaving applicable Unit, Integration or other Automated Tests (e.g. robot testing scripts, such as Selenium) behind in the codebase. This means that the team will be able to sleep peacefully at night knowing that a regression bug hasn’t snuck in with the latest feature.

Code Reviews: Developers are human, and humans make mistakes. So, it’s important to stress to the interviewer that you are comfortable with not only subjecting your own code for review, but also willing to review the code of others. Also, be sure that you can genuinely say that you don’t take feedback personally.

Familiarity with Agile processes: Knowledge of software development processes, and when and why to use them will give your interviewers the warm feeling that you are used to working in teams, and have respect for the bigger picture. In varying degrees, most modern software is developed using various types of Agile process, and it’s a safe bet that most jobs will require working knowledge of Scrum and Kanban, so spending an hour or so brushing up on Sprint Ceremonies and Retrospective techniques won’t hurt. End user knowledge of tools like JIRA (there’s a free 7 day trial) is usually a plus.

DevOps, CI/CD and Version Control systems: No software developer will be taken seriously without actively using a version control system, and teams of developers can’t be productive without one. Being able to configure and manage Continuous Integration and Deployment tools such as GitLab, TeamCity, Jenkins, or Azure DevOps immediately adds value to any team you join.

And if you have been caught in a time warp, then Git is the one VCS with which you absolutely must get up to speed on. Spend some time understanding (short lived) feature branching, how to merge feature branches into the main development branch(es), and be able to resolve merge conflicts.

#3: More senior skills

In addition to the basics, IT professionals looking to move up the ranks of seniority will be expected to show an understanding of more advanced concepts. If you’re looking for a more senior position, make sure you have opinions on some of the following:

Asynchronous programming: Historically asynchronous programming required ninja skills, but nowadays, almost all modern languages have made asynchronous language features accessible to mortal programmers. So for keeping user interfaces responsive on an App front-end, or by reducing threads to improve cloud-server scalability, make sure you can explain the conveniences of constructs such as async/await, Futures, Promises and Tasks.

Functional Programming (FP): FP used to be in the realm of the academic community, but over time, FP principals have invaded most modern languages. Not only will your prospective employer know that code built along FP principals be more concise and less prone to bugs than imperative code, you will also impress that you have been keeping tabs on advances in modern languages. That said, Java and C# developers will find likely find Scala a more comfortable fit than ML inspired languages like Haskell or F#.

Threading, concurrent programming, thread safety: Although context-switching has been around for ages, now that multi-core processors are cheap and ubiquitous, our desire has grown accordingly to harness parallelism in our programs in order to make them run quicker. Make sure you can explain how to tame evils such as (lack of) atomicity, race-conditions and deadlocks - and bonus marks if you’re able to hold down a conversation on lock-free approaches to concurrency issues, or explain how Amdahl’s law creates diminishing returns!

IoC (Inversion of Control) and Dependency Injection: Not all languages use IoC containers, but one of the features (or side-effects, depending on your point of view) of a well-decoupled SOLID application is the need to pass dependencies around. Your reputation will leap when you explain how IoC fits the Dependency Inversion Principle paradigm. And then wow the interviewers with the casual observation that the container manages not only the resolution of dependencies, but also the ability to manage their lifespans. Boast how you managed to build a system without using the new keyword on any dependencies!

Cloud computing: The cloud is already well established, but sadly, for many SA corporates, the move to the Cloud just hasn’t happened yet. There’s a good chance the company you are interviewing for has moved, or is looking to move into Azure, AWS or GCE. Most of the cloud providers have free trial periods with low-powered VM’s, databases and other offerings, which is an ideal way for you to get some hands-on experience on Cloud VM’s, Networking and Storage. Attending Cloud provider meetups and conferences is also a good way to get access not only to sage advice to further your cloud skills, but also get freebies on their data centres.

Containerisation: Although Docker and Kubernetes dominate this space, make sure you have an opinion of why containerisation is such a popular evolution in virtualisation, and be able to contrast this with Serverless and Hybrid approaches to deployment.

Quantum Computing: What if computers were 1000s of times faster! What would that do to our cryptography? What would that do to Crypto mining? Would it brick gazillions spent on Data Centre hardware overnight? Research some of these, and drop those fact-bombs in your interview. It’ll not only show initiative, but also your desire to learn and stay up to date.

Distributed Ledgers and Blockchains: There’s a lot more to blockchain than just cryptocurrencies - many large corporates are taking private (and confidential) distributed ledgers very seriously as a means of certifying the authenticity of transactions. If you have your finger on what’s going on there, you’ll be more likely to hold a conversation if this should come up.

Machine Learning: Perhaps the most frightening future tech of them all. We’re now able to train networks to solve problems that we couldn’t previously adequately describe, nor provide handcrafted algorithms to. If you haven’t already done so, the cloud providers have samples of their Cognitive Services online, and if you’re more mathematically inclined, then TensorFlow and R are worth a look. ML is already evolving away from a prototyping and into mainstream software development - don’t miss the boat!

#4: Skills for positions requiring Design and Architecture experience

Long gone are the days of needing to build a framework from scratch before any serious software project can start (hooray!). But, as always, it is beneficial to understand why contemporary frameworks are good for us, rather than mumbling “That’s just the way everyone does it” in the interview.

Have strong opinions that you can back: I believe that it’s important for software architects to have strong opinions that they are willing to defend. There’s no point just regurgitating “service location is an anti-pattern” or “use the strategy pattern” - you need to explain why doing so might be a good, or bad idea.

Understand the economics of the situation: In context, it might be quite OK for a 3-day prototype or proof-of-context spike to couple classes via new(), or to dispatch commands via a switch statement. But a big part of a software architect’s role is to understand the economics of the situation: Building 100% academically correct software could mean you miss the time-window of getting a product to market. In the race to balance quality versus delivery, some technical debt is inevitable; just make sure that the risks are understood and quantified, and make sure you know when to dig your heels in when the Technical Debt Levels move too high.

Fundamental Design Reading: Undoubtedly, each tech stack will have mandatory reading needed to gain mastery of each framework contained within it, and you’ll never be wasting time by investing time in reading books on Kafka integration patterns or Web UX journeys. However, in the more general practice of good software design, patterns, and architecture, the currency of the wisdom of certain authors hasn’t depreciated with time. Some which I have found are worth giving extra attention include:

• Donald Knuth
• Gang of Four
• Eric Evans
• Martin Fowler
• And, of course, there’s Uncle Bob too

The “hard” skills: What not to do

In closing, I’ve learnt that while it's important to know certain things, it's also important not to do other things. Here's a couple of the instant ‘turn-offs’ that you need to avoid during the technical interview.

Don’t be “meh”

When asked about your previous roles, saying things like “we let the junior guy write all the unit tests” or “only the Scrum Master knows how to work JIRA” could be interpreted as being a passenger on the team.

Take ownership, and show that you are motivated, no matter how small the role may have been. For example, “I was responsible for the design, performance and security of the file upload control” indicates pride and passion in your work.

Don’t give the “not my problem” cold shoulder

Not all software projects run smoothly, and throwing your teammates under the bus or leaving someone behind when the going gets tough shows a distinct lack of commitment - the Agile sprint isn’t done until all tasks are complete.

Instead of saying “The UI guy was slow, so we missed our deadline”, your new team mates want to hear things like “we finished the back-end APIs sooner than expected, so I rolled up my sleeves and skilled up on ReactJS so I could help out on the UI”.

Don’t list hot buzzwords on your CV without any experience

No matter how badly you want to acquire a certain skill by joining a company which is a market leader in the field, listing a technology in which you aren’t proficient in is asking for trouble. Many interviewers, myself included, make a habit of picking up on jargon.

If you’ve listed Neural Nets as a 5 out of 5 on your skill strengths indicator, be prepared to open your interview with “Hey, so I see that you are an ML ninja! So, what’s your opinion on Bayesian posterior inference?”

If you don’t know something, just say you don’t know - there’s no shame in not being able to answer every question. If you’ve just finished watching your first Pluralsight video on a topic, your depth of experience is a 1 out of 5 at best. In any case, everyone is aware that the breadth of tech today is immense, and it’s impossible to absorb all of it.

Bending the truth won’t just be a deal-breaker for the interview, it’s a reputation breaker which can tarnish your career. Hold your integrity above all else.

And what if the interview still isn’t going well?

Unless the job is for a junior position or internship, companies will be looking to hire for exact roles. For example, a front end developer with proven skills in Angular, a cloud-integration guru specialising in service bus, or a full stack team lead in the .Net stack. There’s no point trying to wing this part - you either have the experience, or you don’t.

That said, if it’s clear that the interview isn’t going well and your experience doesn’t match up to the company’s expectations, don’t give up - try to go the distance. It could well be that there’s another available position that is more suited to your skill-set available.

You won’t know that, however, if you don’t try.

Stuart Corrans is the CTO of Galena Hill Systems LLC, a Nevada-based startup in the financial services sector. They’ve just launched arene.io, a Cloud-based accounting analytics and collaboration platform, which uses Microsoft’s Azure Blockchain technology to certify the integrity of the data acquired by its users.

Stuart has over 25 years of experience in the software development industry, and has been involved in the technical recruitment process for many of the 30 or so companies that he has worked for. Stuart lives by the mantra : Learn something new everyday, and is a frequent lurker at Meetup groups in and around Cape Town.