What are the best ways for someone to prepare for a technical interview? originally appeared on Quora - the knowledge sharing network where compelling questions are answered by people with unique insights.
Answer by Avi Flombaum, Co-founder and Dean at Flatiron School, on Quora.
Technical interviews are where you get to meet potential teammates and collaborate with other developers to solve problems.
Interviewers may approach the tech portion differently but the objective is always the same: assess whether you are the right person to join their team.
That means you'll be presented with coding challenges to tackle, and be expected to be able to work through those problems, but, but also that, even when the interview is over, you still have an opportunity to show the interviewers why you're awesome. (More on that later.)
Formats
There are a number of different formats for technical interviewing. You may encounter one, some, or all of these formats during your interviewing journey. Every company interviews in a different way, some may start with a code challenge while others start with whiteboarding and save the code challenge for the end. Be ready for anything!
Here is a list of the types of interviews you can expect and should be prepared for.
- At-home coding challenges
- Technical phone screens
- Trivia
- Pair-programming
- In-person technical interviews
- Trivia
- Pair-programming
- Whiteboarding
Coding Challenges
The gist here is a company will send you a "take home" challenge where they ask you to build an app in an allotted amount of time, sometimes in a specific language, sometimes in a language of your choice. Flatiron School's online course has an entire unit in our Career Prep curriculum that reviews etiquette for these assignments. But at a minimum, you'll want to:
Make sure you know the due date. If there's no due date, assume it's due within a week - remember, the company is talking with other candidates while they're waiting to get your challenge back. If the company doesn't communicate a due date for you, communicate to them the date by which you'll return it - and don't be late.
Send two versions. First, send the best version you can get finished by the due date (or within the week). Then, take another few days and go several steps farther. Add features, increase complexity, refactor, make it pretty...do something to demonstrate your dedication to the process and your desire to go above and beyond. This is an easy way to make yourself stand out: Nearly nobody does this. You should.
Technical Phone Screens
Typically there are two types of technical phone screens:
1. Trivia: Essentially a Q&A session. The interviewer will quiz you on terminology, like "What's the difference between == and === in JavaScript?", and "What does MVC stand for and how does it work?"
To do well, you'll need to study. An easy way to find interview questions is simply to google `Interview Questions
Note that this style of interview is becoming less common than pair-programming, but still exists (and you should still be prepared for it!).
2. Pair-programming: sites like CoderPad have recently enabled remote developers to share code in real-time. This has shifted many technical interview processes from the Q&A format to a more collaborative exercise.
Typically, the interviewer will ask you to solve an algorithmic problem and ask you to code a solution - just like how our students in Flatiron School's online and in-person programs solve labs. You'll be able to view each other's code on-screen and make edits in real-time. If you get stuck, they'll likely give you hints. If you finish quickly, s/he might ask you to optimize your answer and do even better. (In that scenario, what she's doing here is implicitly asking you about Big-O and how efficient your solution is. Make sure to read up on Big-O notation.)
The point of pair-programming is to gauge how you solve problems, how you communicate, and how easy it is to work with you.
You should feel comfortable Googling anything you need to. The interviewer will stop you if it's not okay. Always try, and always communicate your thinking out loud. Practice doing this with a friend, or on video. If you're a student in Flatiron School's online or in-person programs, you'll have a formal practice interview in this style before you ever have a real one.
Both formats are typical for first-round interviews and usually last 30-60 minutes.
In-person interviews tend to come later in the process once you've passed a phone screen and/or completed a technical phone interview or code challenge. In-person technical interviews are often a mix of trivia and whiteboarding or pair programming.
1. Trivia we've already covered. Instead of being asked over the phone or Hangout, you'll be asked questions in person.
2. Pair-programming. Pair-programming we also covered earlier but this time it's in person. An added bonus here is that you'll develop a strong understanding of what it might be like to work with that person.
3. Whiteboarding: This is the most traditional type of technical interview and is where you are asked to solve an algorithm question using a marker and a whiteboard. You might be asked a question like: "Given an array_of_ints, find the highest_product you can get from three of the integers."
Then you stand at a whiteboard discussing the right solution with your interviewer while writing out the code by hand. Interviewers want to see that you can code the solution without a computer and communicate effectively.
If you can't remember the method, just ask. Most of the time, it's not a memorization test.
Feel free to have magic methods that remove some of the incidental complexities. For example, if I was designing an algorithm to find if a number was prime, and I needed a method to find if a number was divisible by 1 through 10, I would just say "ok I have a magic, is divisible method." Sometimes the interviewer will say no, that you have to implement that magic method; other times they'll be fine with it.
Be vocal! Walk your interviewer through your thought process and ask questions throughout the process to ensure you fully understand what's being asked of you.
Across the board, a big piece of critical feedback employers often have is that candidates don't talk enough in technical interviews. Talk. Ask questions. Don't be that candidate - more often than not, your interviewer is happy to help you think through the problem at hand - and he'll appreciate that you're being a communicative "team member." After all, that's part of what these interviews are testing.
Admit when you don't know something
When you're stumped, try and compare it to something you do know (e.g. "So Tree Maps are like Hash Maps, let me talk about hash maps..."
If you come across an algorithm you don't know and you are asked to implement it, ask your interviewer to explain it, then do your best to directly transfer what they said into real code. Don't do any optimizations the first time around.
If you simply don't know the answer to a question, be honest and admit you don't know. Don't lie or try to BS your way through it. Interviewers already know the right answer before they ask you the question - so they'll also know if you're faking it.
A graceful way to answer is, "I'm sorry, I don't know the answer to that but I'll take some time to learn about it after this interview". Then follow up, and prove beyond a shadow of a doubt that you actually did go and learn that thing. Better yet, write a blog post about it (without mentioning the company), and send it to the interviewer.
What to Do if You Make a Mistake and How to Stay Calm
It's likely you'll make a few mistakes during the interview.
You might have a syntax error when you run your code during the pair-programming portion.
You might not know the answer to one of the trivia questions.
You might run out of space while whiteboarding.
There a million other things that might go wrong. Interviewing - technical or otherwise - is stressful. The trick to doing well is staying calm and maintaining your composure.
Every developer knows that you don't just wake up one day, build an entire application from scratch, and run it without a single bug. Real-life development is iterative and you're allowed to make mistakes in an interview so don't beat yourself up if you get something wrong.
If you don't know the answer to one (or some) of the trivia questions, that's okay. Just admit you don't know and the interviewer will move on.
You might have been asked an ambiguous algorithm question and don't know where to start. The interviewer may have done that intentionally. Don't be afraid to ask questions and probe for more information. It's also okay to take a minute and think about the problem before you attempt to solve it. What's not ok is to give up.
Last but not least...
Have Fun With It
Junior developers often get anxious when it comes to technical interviews. It's normal. You may feel like you have a lot riding on the interview but the best way to succeed is to have as much fun as you can.
Treat technical interviews as if you are already on the team. Ask questions like you would in your group projects. Treat your interviewer like s/he's your partner and you are collaborating to build a fun new app.
If you think of tech interviews as less about being evaluated and more about working with another person, you'll remove any doubt you had and end up exuding the passion for problem solving that got you into coding in the first place.
Knock 'em dead.
Action Items
Brush up on skills and concepts likely to be asked in technical interviews, and on attitudes and strategies that will help you to succeed. There are a million resources out there, but here are some of our favorites:
- Sign up for Project Euler and start solving problems.
- Sign up for Interview Cake and start solving problems.
- Sign up for Interviewing.io and start practicing for interviews.
- Become familiar with Big-O.
- Find a whiteboard, pick a few questions out of Project Euler or Interview Cake, and test yourself. If you have any developer friends, ask them to do a mock whiteboard interview with you.
- Read this blog post: How to Make the Most Out of Your Technical Interview
- Read these coding interview tips
- Check out this blog on how to pass a programming interview