8 tech interview types and how to prep
The best thing you can do is ask a friend or a stranger for help. But there are also some great resources out there that could help.
I stumbled on this post from Ceora, and it got me thinking of the many ways the tech interview could look like for candidates.
My first thought was that I would likely ask what the tech interview would be. Companies usually share what the process will be like; it is no problem to ask. And if it is not clear, do ask for clarifications.
I will cover the types of technical interviews I experienced and the resources I would use to practice if I choose to continue the process.
Note, in-person could mean meeting in the office or an online discussion like google meet or zoom, etc. I will cover some practical tips for online interviews at the end.
Structure
Usually, it starts with people introducing themselves and asking for a quick intro. Then there is the tech part, and sometimes there is time left at the end for your question.
Have a quick 2-minute intro of yourself. You should add something about hobbies in Sweden, but that might be different in other cultures. Keep it broad and straightforward; there will be time to go deeper into the conversations afterward.
Then there is the technical part which is covered below. Remember to:
- Think out loud — people want to see how you think
- Write things down or draw on a whiteboard or any digital means
- Ask many questions! Clarify things, check-in if you are going in the right direction, and ask how they would have done it.
And it often ends with 5–10 min of allocated time for you to ask questions. It does not mean you should keep all questions to the end; instead, this is for other concerns, such as asking about the teams’ culture and how they work together.
Interviews are a 2-way street, you interview them as well!
Here are some tech interview types I experienced and how to prep technically.
1. Timed algorithm test
A timed algorithm test on specialized websites. Usually, interviewers can see almost every letter you type in a timeline, like a video. They will know when you copy-paste big chunks of code. You will still do it because it is more comfortable to write code in an IDE. If that is a problem, run! Dodged bullet.
For these, I use one of these to practice:
To get more familiar with algorithms, you can check out one of these guides:
- Google algorithms course
- https://geeksforgeeks.org/introduction-to-algorithms
- https://leetcode.com/study-plan/algorithm
- https://medium.com/basecs
Or this video course: https://youtu.be/8hly31xKli0
2. In-person algorithm test
I still use the above websites and maybe dry-run with friends, so I get used to explaining things aloud. Or https://pramp.com is pretty nice.
Use the whiteboard to write things down. Ask many questions!
3. Refactoring/Adding to existing code
You get this horrible code and need to restructure and fix the issues. Often it is in person or online. Start simple and unravel the thread. Ask many questions, and if something is not relevant, move on. The Pragmatic Programmer or Refactoring are great books that could help prepare. They are great books even if you do not have an interview!
Also read up on best practices like SOLID, DRY, KISS, YANGI, etc.
- S — Single-responsibility Principle
O — Open-closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle - DRY — Don’t Repeat Yourself
- KISS — Keep It Simple, Stupid
- YANGI — You aren’t gonna need it
4. Qwizz websites
like https://testdome.com/questions, I would check the website and sample questions first to understand if I need to review specific terms that I do not know by heart or review theory/books. It is not my fav because I do not memorize things.
5. In-person discussions
There are also the in-person questions; you can check sample questions websites:
- https://www.glassdoor.com/Interview this is extra great since you can see if anything shows up for the specific company rather than generics
- https://tryexponent.com/questions
- https://careercup.com/page
6. In-person system design interviews
You need to draw boxes on a whiteboard and talk about how they are connected. I usually check out the company tech stack and see if they have blogs etc.
You can practice with a friend or watch videos like the Introduction to System Design series.
Key tip, make sure you understand the requirements and users! There could be different types of users, e.g., end-users, finance department, or administrators. The questions you ask are usually more important than the specific technologies you mention.
Sometimes when you are very attached to technology, it could be a bad thing because people want a person that uses the right tool for their needs. Try to use concepts rather than tech: Async messaging rather than Kafka/RabbitMq/PubSub, or DB rather than Postgres/Dynamo.
Be ready to talk +/- about potential technology choices, like why is a relational DB more suited than a NoSQL/document database or the other way around?
Pro-tip, you can also ask back, “What do you think would work best?” or “What do you use at <company-name> ?"
Here are some more helpful prep resources
7. Home assignment
It is similar to the system design usually. Do ask clarifying questions if you have any. Here are some things to include.
README.md with: — system diagram (helps explain during the interview). I use http://miro.com or http://mermaid-js.github.io
- clear instructions on how to run the system and tests locally
- a short overview of the system and design choices
- a wishlist of things you would have liked to add but down prioritized XD
Do add tests! For your own sake, use git or some versioning system. Make sure it requires the least amount of things installed. Ideally, it is all containerized. I usually go a step further and add a simple test runner on my private repo. It keeps track of it for me when I break stuff.
These are my favorite because it does not make me practice things that I do not use daily, but there are the most time-intensive, and sometimes I do not have the energy.
It is also problematic since sometimes people do not have the time, e.g., new parents who already juggle kids and a full-time job.
You can always ask the company if you can instead walk through a past project or tweak the process in some other way. I have seen it work.
Find example tests here: https://devskills.co/coding-tests
8. Debugging a system
Something went wrong, and you need to find out where the bug is. People want to hear about how you think and where you look first. Ask about metrics/logs, etc. Take it as a conversation. Talk about the customer impact and how to notify the customers.
Think about:
- Potential changes to the system that might have caused the failure
- Deadlocks, bottlenecks, and other performance issues and how to detect them
- Asynchronous architecture patterns and degraded performance vs. being down
- Resilient systems, eventual consistency
- Rate limiting, circuit breakers, and similar mechanisms
- WAF (web application firewall), Load balancers
- Malicious intent, potential attacks, and countermeasures
Online interview checks
When you have an interview through video conferences, you should prep some extra things. Have a way to whiteboard, e.g., I used http://miro.com in the past. — do dry runs with friends. It feels different than in-person.
Ask about the structure, and check before the interview that you can share the screen and have video and sound.
- Google Meet, if you have not used it in your browser before, requires you to allow access.
- Zoom, you usually need to install a client, so that it might take some time.
Other great resources
Cracking the coding interview
Do check out “Cracking the coding interview” book by Gayle L. McDowell https://crackingthecodinginterview.com. It is a good read, regardless if you are interviewing currently or not! It covers system design, algorithms, and practical tips on how to present yourself.
There are also some free resources on the page.
Free code camp
Free Code Camp is a free resource where there are many tips and guides. It also covers much more than just interviews, e.g., structured learning.
In conclusion
Regardless of what happens in the interview, keep in mind that one might be a fantastic developer and still fail interviews without practice. So learn what you can from this experience and let it go after.
Disclaimer, this is more for backend type of interviews. Always ask the people what the interview process would be in detail so that you can prepare. Good luck!
