How to get Software Engineering offers from top-tech companies in Australia — Part 3: Technical interviews, Algorithms and Data Structures
Other articles in the series:
Part 1 — Interview Format, Online Presence, Recruiter Screen
Part 2 — Non-technical interviews
Part 3— Technical Interviews — Algorithms and Data Structures (you are here)
Part 4— Technical Interviews — System Design (coming soon!)
Part 5— Negotiating (coming soon!)
Interviewing at tech companies can feel a lot like solving rubik’s cubes while hula hooping on a skateboard. On one hand, it’s a niche talent that you can use to impress your friends. On the other hand, it’s a skill that obliquely demonstrates your competencies as a software engineer.
Unfortunately, employers don’t have an easy job evaluating your skills as a software engineer. Fortunately for you, learning how to interview well is a skill that can be developed, and you can leverage interview prep to increase your skills, your job prospects, your salary, and your lifestyle.
Here’s how you can get Software Engineering offers from top tech companies in Australia.
For the entirety of your interview process, I would recommend the book Cracking the Coding Interview (this is an affiliate link, just fyi). This book contains a bank of technical interview questions which are great for ramping up for the technical interviews (as well as a bunch of resources for the non-technical phases of the interviews).
I’ll endeavour to point you to the most important parts of the book so you can optimise your prep time.
Technical Interviews overview
From Part 2 you would have prepared for the recruiter screen, values and leadership interviews. While Part 2 was all about preparing your responses and holding them in the back of your mind, technical interviews are all about learning and applying principles.
Technical interviews generally follow this breakdown:
- Algorithms
- Data structures
- System Design
Each is their own interview, and will be scheduled for an hour and focus on a single problem. Keep this in mind when selecting problems for practice. It’s very unlikely that you will be tasked with reinventing Dijkstra’s algorithm or other time-consuming / knowledge based problems.
Instead, you’ll be given a problem that you’ll be expected to solve within your interview timeframe, and there will be additional aspects of the problem given to challenge you if you solve the first one quickly enough.
How to Prepare
For algorithms and data structures, Cracking the Coding interview is an invaluable resource. Each major topic is covered with an introductory section which explains the principles and strategies for solving the problems. I recommend going through at least 5 questions from each section.
Solve problems in your Editor, not on paper
Cracking the Coding Interview recommends writing the solutions on paper. In my view, this is dated advice. Since remote work has become ubiquitous, it’s much more common to have interviews over video calls, rather than in-person on whiteboards. As such, you’ll almost always have access to your IDE, and will be expected to use it proficiently.
A note about IDEs
Both Atlassian and Canva use Java and IntelliJ for their development. IntelliJ is available on a trial basis, free you’re a student, and there’s also a free community edition. Getting used to using IntelliJ goes a long way in interviews for several reasons.
Firstly, it’s the editor that your interviewer probably uses, this means you get bonus points for familiarity. Additionally, it’s the editor you’ll likely use on the job. As well, it has a lot of built-in support for Java, testing, and debugging.
Ultimately, you’ll want to use whatever editor you’re most comfortable with. At the interview you’ll be sharing your screen, so taking time to do these problems on your computer, within an IDE, will mean you’ll be prepared for the interview environment.
Your workspace
I recommend setting up a Gradle project with JUnit, and creating a class and test suite for each problem. When you get used to this project set up, it will immediately translate to the interview environment, and allow you to spend your interview time solving the coding problems, rather than struggling with the setup.
Big O
Big O, or complexity, is a concept you’ll be quizzed on across the algorithm and data structure interviews. You will be expected to understand the time and space complexity that your code operates in, how to improve it, as well as when to make the tradeoff between them.
As such, it’s important to go over the Big O section of Cracking the Coding Interview and understand the concept clearly enough that you can evaluate the time/space complexity of your code on demand.
Data Structures
If you’re following Cracking the Coding interview, I recommend starting with the Data Structures sections first, these include:
- Arrays and Strings
- Linked Lists
- Stacks and Queues
- Trees and Graphs
If you’ve been away from Computer Science from some time, these topics are a gentle refresher.
It’s important that you understand the principles of the basic data structures. Not only is there a specific interview on data structures, but you will also be expected to use them proficiently in your algorithms interview as well.
In your interview, you’ll be expected to understand and use the built-in data structures for your language — you won’t be implementing them from scratch.
In Java, this is known as the Java Collections Framework. Based on the Data Structure interface (ie. Set, Queue, List, etc), there are several implementations which you can pick from (ie. HashSet, PriorityQueue, ArrayList).
Rather than implementing a data structure from scratch, you’ll be expected to know which data structure to use based on the coding problem and which implementation in Java fits the problem best. For example, if you recognise that your problem needs a Set, do you choose a LinkedHashSet, or just a HashSet, and why?
I would recommend making a cheatsheet for yourself from https://www.interviewcake.com/data-structures-reference. This is a great reference of the data structure’s strengths and weaknesses, as well as their time and space complexity.
Ultimately, the data structure interview will consist of a problem that can be solved in various ways, but is best solved with usually a single data structure. Knowing which data structures are good for which situations is crucial here, as well as knowing how to interact with them in the most time/space efficient ways.
The best way to prepare is to understand the principles of the data structure first. This can be gleaned from the introductory pages of each section of Cracking the Coding interview. Then, solve at least 5 problems from each section, making sure to accompany each problem with a test (more on testing later).
Algorithms
The algorithms section of Cracking the Coding Interview include:
- Threads and Locks
- Recursion and Dynamic programming
- Sorting and searching
Within Cracking the Coding interview, they also mention bit manipulation and “Math and Logic puzzles”. Most companies won’t expect you to know bitwise operators unless it’s specific to the role. As well, most company’s interviews won’t have time for intricate math and logic puzzles. As such, I recommend skipping these sections.
The algorithms interview will be a problem much like the ones you’ll see in these Cracking the Coding Interview sections, with the twist that they may be a bit more “real world” — as in, they’ll likely be more relevant to your role, the company, and their problem domain.
The best way to prepare is to understand the principles of the particular section, for example: the implications of multi-threaded programming, when to use top down or bottom up dynamic programming, etc. This can be gleaned from the introductory pages of each section. Then, attempt at least 5 problems, making sure to accompany each problem with a test suite.
A note on Testing
For software engineers, testing can be an afterthought. At top-tech companies, testing is a first-class citizen and is required to accompany any code you write.
Most software engineers will write the implementation code, and then go back to writing the tests. The problem with this approach is that it requires willpower, diligence, and relies on the engineer to remember to go back. Unfortunately this approach means that tests are often half-baked, low value, low coverage, false-positive, or completely forgotten.
Instead, I recommend practicing Test-Driven Development (TDD). This is a fancy way of saying, “Write the tests first.”
TDD involves writing a test for a slice of behaviour you want to see from your implementation. When the test fails for the right reason, then you can implement just enough code for the test to pass. From there, you can refactor the code so it’s more readable and maintainable. Then you write the next test, and so on. This is known as a red-green-refactor cycle, and is the core of Test-Driven Development.
The reasons why this is a killer move on your interviews:
- It shows you care about writing quality tests. Tests written first will fail for the right reasons, this way you avoid false-positive tests.
- It allows you to proactively demonstrate your testing ability, which is evaluated as part of your interview.
- It automatically ensures you have the happy path and edge cases covered by tests.
The downside to Test-Driven development is that if your red-green-refactor cycles are too granular (as in the increments of behaviour you’re testing for are very small), this can chew up more time on your interview.
To combat this, ensure the behaviour you’re testing for is close to the end result. Don’t write a test that asserts that you can instantiate your class. Write a test that instantiates your class, calls the method, and expects the output for a given use-case.
If you’re not familiar with testing, or TDD, your prep time is your opportunity. Rather than diving into the implementation on your practice problems, start with a test for the happy path, and drive the implementation with Red-Green-Refactor cycles. Make sure to include edge case tests.
Ultimately, your interviewer doesn’t care if you write the tests first or not. They do care, however, that your tests actually assert the correct behaviour, and ensure your code is working. TDD, in my opinion, just happens to be the best way to ensure this.
Evaluating your solution
Not only is the interviewer looking to see if you can solve the problem in the timeframe, but also will look at the following aspects:
- Code quality
Is your code readable, maintainable, refactored? Are variables and methods named clearly? Does the program flow make sense? - Testing
Have you covered the happy path and edge cases? Are your tests passing for the right reason? - Adaptability / Flexibility
How do you handle challenges to your approach? Are you open minded to other solutions? - Big O
Do you understand the performance implications of your code? Are there areas you can improve? - Decision making process
What tradeoffs are you making, and can you explain your reasoning?
Are you explaining your thought process out loud as you navigate the problem? - Resourcefulness
When you get stuck, are you able to unblock yourself? Do you use Google and your interviewer as a reference? (this is a good thing!) - Use of data structures
Do you use the appropriate data structures? Do you understand the implications of the implementation of the data structure you chose? - Production worthy
Could this code go into production? Can you point out areas you would want to improve first? Edge cases you haven’t covered?
Knowledge Tests
Depending on the company, certain topics might be more heavily weighted for knowledge testing. Canva, for example, cares a lot about concurrency and multi-threaded environments. Since they’re a Java shop, they might also test you on Java specifics.
Here is a list of areas that are good to review based on the company’s profile.
- Java language basics, like overloading vs. overriding
- Java Collections Framework — understanding what each concrete implementation does, and when to use it
- Stream API — Including parallel streams
- Completable Futures
- Concurrent Datatypes — understanding what each concrete implementation does, and when to use it
- Concurrency Models — Parallel Streams vs. Assembly Line vs. ForkJoinPool
- Threads and Locks, Intrinsic locks, Synchronisation
- New Java Features (like Record, Lambdas, Diamond anonymous generics, etc)
In my Interview Prep Template, I’ve planned out each section from Cracking the Coding interview that you’ll want to cover, as well as included a comprehensive list of the concepts / data structures to understand for knowledge tests.
This template includes everything from the previous parts of this article series, including everything you need to know for the recruiter screen, getting your online presence up-to-date, as well as the non-technical interviews.
My sincere hope is that this Interview Prep Template and article series helps you prepare and be successful for your interviewing.
Conclusion
Preparing the the algorithms and data structures interviews is all about learning the fundamental principles, and knowing when to apply them. Internalising these principles only comes through practice. The more practice the better, but my recommendation is to solve at least 5 problems per section.
The best way to practice with these problems is to understand the principles from the opening pages of the section in Cracking The Coding interview, and then attempt the problems yourself, without looking at the solutions, and driving your implementation with tests.
Develop an intuition about which data structures to use, and when, and know which concrete class to use. Notice patterns in the problems which hint algorithms for you to use. Understand the different approaches you could take and their implications for Big O, as applied to both time and space complexity.
With this practice your interviews become much easier, since this is exactly what is tested. You’ll have “done the work”, and earned your confidence.
While practicing for the algorithm and data structure interviews, you can prepare for the System Design Interviews in tandem, which will be covered in the next part of this article series.
See you in the next article!
Next article:
Part 4 — Technical Interviews — System Design (coming soon!)
Other articles in this series:
Part 1 — Interview Format, Online Presence, Recruiter Screen
Part 2 — Non-technical interviews
Part 4 — Technical Interviews — System Design (coming soon!)
Part 5 — Negotiating (coming soon!)