Doing well on tech interviews is one of the latest obstacles full-stack software developers encounter before they get hired.
For every step in the hiring process, there’s a particular purpose, and this includes:
- Phone screens for discovering your general fit
- Behavioral interviews to ensure you have interpersonal skills
- Reference assessments to know how you have dealt with quarrels, stress, and teamwork
- Evaluation of how well your programming skills meet the company’s needs and the role’s responsibilities
Many developers have shared their painful tech interview stories like whiteboarding compiler-ready code, doing FizzBuzz in COBOL while blindfolded, programming on an unfamiliar computer, and inverting binary trees.
However, there have been adjustments in the methods used for assessing developers in tech interviews compared to the old styles used a few years ago. You can have a collaborative discussion or a take-home assignment instead of whiteboarding “Hello World!” in 10 languages, or the old-school Google-style brain teasers like, how many students would this classroom contain? In this regard, you get familiar and prepared for the kind of work you’d be doing when you finally get the job.
No tech interviewer would want you to fail, even if they look discouraging. The interviewers are just trying to test your problem-solving skills so that they’ll be delighted with hiring you when you succeed. For the tech interviewers, hiring you implies that they can resume their original jobs. The productivity of the company will increase, and everybody enjoys more success and money in the industry.
Know the Basics First
As resumes are about describing your ability, tech interviews are about demonstrating it to someone (interviewer).
Towards the interview, your plan should be the same for every question interviewers ask you. You should understand the problem, provide a solution, describe it, and perform it. If you’re a skilled engineer, you’d know how to prepare yourself to perform better in the interview.
But you still need to do some assignments ahead of a tech interview. Review the company software stack. For example, you should know how to operate with Ruby if it’s a Ruby shop. Check out the company’s StackShare and public GitHub repos for the kind of languages and libraries they are using.
To refresh your coding skills, complete LeetCode’s top Interview Questions or HackerRank’s Interview, or take a copy of Cracking the Coding Interview (where you’ll find 150 Programming Interview Questions and Answers along with the solution manual).
You can also check Devpost for some great videos about preparing for coding interviews, acing your tech interviews, and whiteboarding a game of Battleship. Dress professionally and comfortably for your interviews, which can be through a video chat from home or visiting the office. There’s no way you can think straight when you’re worried about your tight shoes or in an untidy collar.
Note that once you start the interview, if you don’t know an answer, get something wrong, or freeze up, be sincere and admit it. However, it isn’t a sin to be dumb for some seconds, so you need to think about the problem before explaining it.
Try to ask questions as you discuss the problem with your interviewer and reconsider your approach. This scope is like testing your work for some credits as you demonstrate it from the way you think, and it may likely turn the situation in your favor.
Four Technical Challenges to Prepare for and Ace
Depending on the company and the role, some tech interviews can be face-to-face or virtual, and some might not even need writing code.
Here are the four basic types of tests you need to approach and prepare for, and each step evaluates the different skills you’ll need on the job, respectively.
Live Coding Test
This test is most common in tech interviews, where you’ll need to write working code in about 30-40 minutes.
For instance, when they give you some broken code to solve, you’ll need to firstly identify the bug, then fix it, pass the test suite, and describe what you did all through. This type of test is well-known with Test Driven Development (TDD) teams where you need to fix trivia issues. The test is to know how you can read a test spec and identify the code blocks or bugs affecting it.
In this exercise, the interviewer can join you via video chat or be in the same room with you. You may not have access to your ideal environment. You can be given an unfamiliar computer or limited to an Integrated Development Environment (IDE).
The process you use matters even if you can’t fix the bug. If you’re stuck, ask questions and discuss your approach with the interviewer.
If you want to get yourself prepared and ace this type of test, you need to know how to write code outside your ideal environment. It means practicing writing code without the following:
- Dual-screen setup
- Custom dotfile aliases
- Fancy key bindings
However, if you haven’t written live coding tests before, this is a great opportunity. Try some problems from the TDD Community of Practice or try some Coding Dojo Katas.
You can also plan your tech interview by asking the language you’ll be coding in, or maybe you’re free to choose one, as you won’t love to find yourself doing Go or Rust when you have already prepared for Python.
This type of test offers many benefits by giving you access to Stack Overflow, Google, and your personal computer for demonstrating your coding skills.
Just like live coding tests, you’ll need to prepare for a take-home assignment when given. But the only difference is the way you deliver your results.
For example, they can ask you to do a test suite, operate a Sudoku validator, and read a short product spec. Firstly, you should know that validating a Sudoku board isn’t that tough. It’s your operation that will prove how best you approach bugs, track, and decode them as required.
Time management is one of the most important things to consider in an interview. No matter the specific amount of time a company gives you to complete your take-home assignment, you should submit your code within 3-4 days or given a limited time. Present your solution in no more than 4 hours.
More so, create enough time to check and edit your work before presenting the solution. In your result, direct your interviewer through your approach and be ready for questions. Show the interviewer your assumptions, decisions, and changes you’d like to make in the future.
There is no particular way to approach a problem. Do your best and present your result to the best of your knowledge. Open up as interviewers would be interested in knowing the method you used for your presentation.
Many candidates with excellent solutions fail by fixating on code during presentations. If you want to overcome this challenge, practice your presentation for a non-tech audience like your parents, uncles, or grandparents.
Explain the problems, your proposed solution, and how you carried it out to them. With that, you’ll be able to create a short-remarkable story for your presentation.
While live coding and take-home assignments are practical assessments, there are theoretical tests for designing something where you’ll be whiteboarding.
They can ask you to design a messaging app with some conditions like, make it web-based and text-only. Or ask, “Which data will you need to run it, and how would you build it?”
From your answer, the interviewers can increase the scope of the test and ask you to reason through the interface, networking, and refactoring. It promotes you from creating a simple concept to building a standard app.
Even when you have to design something that has nothing to do with the company’s product, keep on. The interviewer wants to judge how you respond to below-standard product specs and changing requirements. They will challenge the assumptions and decisions you have made as you progress. For example, suppose you decide to use SQL for data storage. In that case, the interviewer can include some new tech requirements that’ll be complex for you to complete without joins.
Also, they’ll evaluate your temperament just like your solution, and be ready to adapt. Don’t see your solution as the best and only. If you can’t bear being criticized or take feedback, then you aren’t ready to take the job.
As a full-stack developer, you don’t need to be highly skilled at data administration, low-latency networking, or UI/UX. But you need to understand and explain an application’s full-stack professionally.
To get started, practice by selecting and carefully thinking about a previous project you have completed. The following will guide you through:
- Check how the front end, back end, data, and user interface (UI) interact with each other
- How would you structure them if you were to start afresh?
- Do you prefer using different tools?
- Select the trade-offs you would like to consider
In essence, refactoring projects helps you identify the areas that need changing viewpoints and improvements. At home, you can talk through the problems loud and clear so that you’ll be fully prepared to do the same with your interviewer.
Many companies don’t care about your years of experience. They only want to test if you know the fundamentals (which is the computer science trivia).
For example, they might ask some questions like, “How can you complete this program repeatedly? (or ask you questions about big O notation).
Most interviewers in small companies where the tech stacks are narrow, and new hires need to swing into action often ask questions on a specific programming language. You would find it tricky if you’re new to the language. It doesn’t matter much if you’re not good at the language in which they test you. Your ability to approach a code is what interviewers want to see. Besides, most languages have similar constructs, and their logic hasn’t changed.
The trivia test may look inane a few years ago to candidates without programming traditional backgrounds, including the self-taught developers, those who switched careers, and those who went to Bootcamp.
It means you’re keen on and knowledgeable about the origin of software engineering. Spend more time to learn the fundamentals of the following:
- Control flow
- Data structures
- String manipulation
- Common sorting algorithm
- Object-oriented programming (OOP)
Though you might not necessarily have to implement a Radix sort in five languages, you should know what it’s all about and its limitations.
If you want to refresh yourself, check out the class materials like notes, lectures, videos, exams, and more, for free online learning from MIT (read through lectures 1-12) and Stanford (read through weeks 3-5).
Most Importantly, Do Well During Your Probationary Period
You are subject to a probationary time even after you get the job. You may not find it in your offer letter. Capital is limited, software engineers are expensive, and if you can’t help improve the company’s growth, then you’re not doing well.
Before you can get along effectively with the company’s new tech, teams, people, and systems, it’ll take some time. You need to continue presenting your results for 6-8 months, because if you perform well during the interview and you can’t prove it in your work, you may lose the job.
However, you need to build your communication skills if you want to prepare yourself for success during and after this period.
Sit down with your manager during your first few days and sketch out a plan for your first week, first month, and first six months. It will help prepare you to work towards the milestones and expectations you have built. You can report on your progress by following that up with a weekly or bi-weekly one-on-ones plan. Highlight what you have achieved, show where you need help, and expect feedback.
In no time, you’ll fully become a member of the company’s team and help the next developers set up for tech interviews.
You may likely get many trivia and live coding tests earlier in your career when interviewing for full-stack software developer roles. If you have no work history, recruiters will evaluate what you’re able to do presently and teach you everything you need to know about the job later.
But the tech goal of your tech interviews is different if you’re more experienced. Recruiters will test if your skills are up-to-date, how you mix with the team and your adaptability.
You may even find a short tech interview stressful. But performing well, irrespective of the forms it takes – can save you and your recruiter from mismatched possibilities.
From the above tech interview tests, you can identify the type of challenge you’re tackling. So do your take-home assignment, walk through the door with confidence, and demonstrate what you’ve learned and prepared for so far. When you’re through, have it in your mind that you did great.