The hunt for your first job can be a stressful time in your life. You’ve invested a huge amount of time and energy into learning the skills you think you need to start your journey in the world of professional software development, you’ve made some fantastic projects along the way, but who knows what those pesky interviewers are going to ask you in a “technical interview”.
Well, a technical interview could mean a number of different things - an hour of questions, writing some code (either on a whiteboard or in an online editor), or a walk through one of your projects. What I intend to set out below are some topics to help you prepare what ever comes your way.
🗒️ Throughout this page I’ll use the terms app, service or project interchangeably. What I mean by this is a thing of some kind that you’ve built.
Let’s start with the project walkthrough and some of the areas you might want to touch on. The topics below are also a great starting point for “an hour of questions” style interviews.
This style of interview requires you to think about a project that you’ve worked on and answer questions on the design and implementation.
First things first, how do you decide which of your projects you should chose? When I’m interviewing I’m really looking for a project that fits two criteria:
If you find yourself building lots of “hello world” or todo list apps to show your versatility in learning frameworks or languages, a better investment with your time might be to create a single, more complex application so you can show your depth.
So, you’ve picked a project that you’re happy talking about in depth - what sort of topics should you prepare?
Most of the questions in this area will be around why you made certain choices when building your application. You may not have considered any of these things when designing your application so it’s a good idea to retrospectively review some decisions you may have made. “Because this is the technology I know” is an alright answer, but companies will be looking for candidates that are able to see how the tools and technology they know fit into a wider ecosystem. There are a million and one frameworks and tools to solve a problem so you’re going to need to know how to pick the one that fits the job best.
I’ve included a non-exhaustive list of questions below, some may not be applicable to your project depending on its design.
If you’ve learnt to programme via a bootcamp or you’re self-taught you may have never needed to write tests but you’ve probably had a lesson or two covering them. Testing is a really important tool for ensuring the software you write:
It’s my opinion that you don’t need to have written tests to get your first job, but you should have an understanding of why they are important and an idea of the different types of testing. A couple of key questions to answer would be:
A few types of tests to look into at unit tests, acceptance tests, integration tests, and performance tests.
Lastly, one often overlooked use of tests is to document your code. Unit tests can often provide information on the way a method is expected to be used and the kind of data the original programmer anticipated might be used. Next time you’re trying to understand someone else’s code, take a look at the tests.
Depending on the type of applications you’ve written, you may have never had to think about scale. Code running on even the most basic laptop can support enough users to test your code, share with friends, and potentially even publish to the internet. Writing software for a business will take you beyond that and it’s important that you know how to think about scaling software.
The best place to start when thinking about performance is to look at your application and try to work out which part will break first. Will your server manage with 100 times the number of requests it’s got at the moment? What about 1000 times? How about your database? Focus in on the weakest part of your application and how might you improve its capacity.
To scale an application there are two main approaches:
Vertical scaling: this is the simplest form of scaling and it involves increasing the power of the machine your code is running on. Got 500Mb of RAM? Make it 1Gb. This is useful for parts of your application that store data (or manage state as some people would refer to it.) It’s the easiest way to add capacity without too much difficultly. A word of caution with this approach - you can only go so big before cost becomes the prohibitive factor.
Horizontal scaling: this involves running multiple copies (or instances) of your code on replica machines. Have one server running your back-end? Try two. This is a really effective way of splitting the load across different instances. When horizontally scaling your application you’ll need to think about balancing the load on each machine, and handily there are services called Load Balancers to do exactly that for you.
Similarly to the point on testing, I wouldn’t expect early career candidates to have experience in scaling an application but understanding how software scales is important to know.
Lastly. you should be aware of how to deploy software. Like the other sections, a surface understanding of the type of services you might use to get your application in front of users. Here’s a short list of topics:
In short, the points above should take you beyond thinking about writing code and into the other problems you’ll face running software at scale. Take all of this with a pinch of salt. Not every company is going to ask you the same questions and have the same expectations of a junior engineer, but understanding how to get your code, your apps, your products in front of people is very powerful knowledge indeed.
Best of luck, you’re just getting started on an exciting and potentially rewarding journey! 🚀