When you are applying to a tech company, most likely you will get into a series of online coding tests, live coding tests, or even system design interviews.
Hypothetically, there would be those kinds of rounds you will be facing:
- Online coding/take-home test.
- "Tell me about yourself" round.
- Live coding/pair-programming test.
- System design/whiteboard exercise test.
Depending on the size and type of company you are interviewing at, the way they interview might differ. If the members would be still around 10~20 people, you could expect only two rounds of interviews (sometimes including an interview with HR). If the members are on >20 people or if you are applying for some higher-level position, you could expect you would having 3~4 rounds of interviews.
Let's get started immediately on breaking those down.
These can range from completing timed exercises on HackerRank to completing a small project with written instructions from the interviewer themselves.
Regardless of the style of take-home assignment, there are a few things I think you should keep in mind to increase your chances of success:
- Ensure you are in a distraction-free area for the entire allotted time
- Put any distraction-prone devices away
- Read all instructions to the problem(s), and then read them again If your assignment is timed and you don't think you will have enough time to finish, write comments throughout the assignment with what your next steps would be if you had more time.
Specifically, if it's a Hackerrank-type of a test, you only need to prepare yourself to refresh some basics such as Fibonacci sequence, etc.
If it's a take-home test, make sure you put documentation or explained your code. It will show that you have good attention to detail.
This round could be with HR, or an intro with a tech lead.
If you are talking with HR. Make sure you point out those things:
- Ethos or interests you share with the company
- What excites you about software development
- Future goals that (hopefully) this company can help fulfill (that is, technical and professional growth)
If you are interviewing with a tech lead, they would most likely ask about your previous experience. An effective framework for answering these types of questions is:
- Give a quick overview of what the project is and the problem it solves.
- Mention the technologies you used in this project.
- Communicate any metrics that demonstrate any positive impact (like time-saving metrics, open-source contributors, number of active users).
If you tend to talk fast, take a deep breath before you answer and try to speak slowly and clearly. And try to be enthusiastic and answer questions fully, without rambling too much. Also, please make sure you put up an answer in a well-structured sentence.
This session is usually the problem you are given is generally something you will see on the job at this company.
There are a few things to keep in mind if you have a session like this:
- Try to stay calm and remember that you are interviewing here for a reason, they like you and see promise in you.
- Communicate out loud as much as possible, even if you think you are talking too much. It’s better to over-communicate in these exercises than to sit in silence typing away at the keyboard.
- Don’t be afraid to ask questions, they’re on your side! The interviewer has probably left out critical details on purpose to test your communication skills while working with other developers.
Ultimately, try and be conscious of the fact that this company sees promise in you on a personal and technical level. Be yourself and be confident!
Sometimes a company would prefer to take a look at your technical skills and ability to break down complex problems in more of an abstract way. The most common way of testing a candidate this way is by having them complete a system design/whiteboard exercise.
This method of interviewing might be the most talked about, and the most feared. If you are asked to use a whiteboard to solve a question remember this: they are usually far more interested in how you communicate your problem-solving process, not that you can solve the problem.
If the problem they give you seems really hard, that isn't because they are trying to stump you. They want to get a feel for how you tackle a hard problem. If you don’t end up solving the problem, that doesn't mean you blew your chance.
If you keep these things in mind during this exercise, it will increase your chances of impressing your interviewer:
- Repeat the question back to the interviewer
- Ask clarifying question about edge cases
- Confirm optimal results of the problem
- Write your code legibly (if it needed to code)
- Communicate each step you take
If you answered the question successfully by the time the session ends, ask your interviewer if that was the solution they commonly got. If not, ask what other candidates have done or what you could have done differently. This shows that you are engaged and curious.
Ultimately, you could master a system design interview by enrolling in this course.
You could also read an e-book on Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems.
If you want freebies, you could take a look at this Github repo
Don't hesitate on asking the HR/recruiter what will be upcoming rounds of interviews would be. They would happily help you out!
If you failed on the first interview, that means you are learning! Passing a series of technical interviews isn't easy, and it's perfectly understandable.
Consider your 1st interview series process as a drill, and improve again on to the next one!
Good luck with your upcoming interviews!