What is a technical job interview? What sort of questions are you likely to get asked by hiring managers when you’re applying for web developer or software engineering roles after coding bootcamp? Although Dev Bootcamp is no longer open, this is still great advice! Former instructors, Mark Siemers and Anil Kulkarni, join our panel to discuss what to expect in a technical job interview, examples of common technical interview questions, and how students can thoroughly prepare to succeed in a coding interview and get the job. Read the article or watch our video Q&A.
- A technical interview is unique to the tech industry and consists of technical coding challenges, brainteasers, whiteboarding problems, and language-specific questions.
- You can expect to answer questions in a phone interview, an in-person whiteboarding session, pair-programming, or a take-home assignment.
- Regardless of format, expect 4 types of questions.
- There are 3 secrets to acing a technical interview, and none of those involve getting the correct answer.
- At Dev Bootcamp, students practiced whiteboarding, mock interviews with hiring partners, and had access to the DBC Careers Team (plus Mark & Anil share their favorite online resources to get practice before your interview).
Meet Your Panel:
- Mark Siemers is a former instructor at Dev Bootcamp San Diego and has worked as a software developer at QuintEvents and Bloomberg.
- Anil Kulkarni is a former instructor at Dev Bootcamp Seattle. In addition to working for Microsoft, Anil was the first employee at Textio, so he’s seen both sides of the technical interview.
What is a technical interview? What should somebody expect?
Anil: The technical interview (or coding interview) is unique to the tech industry. Hiring managers for web developer or software engineer roles will often require candidates to answer technical questions, in addition to gauging culture fit like in a traditional job interview.
A technical interview might start out with a group conversation, and then throughout the process you'll probably spend about an hour on average with a number of different interviewers. You’ll be asked one to three technical questions, and work through those questions with their team.
Every company is going to focus on different things and may have a different style, but generally, these are the four types of questions you can expect:
1. Implement a Well-Known Algorithm
These are questions that have been solved, but the interviewer wants to know that you understand how they work and that you could implement them on your own if you needed to. Then the interviewer might ask you to switch and solve it iteratively or recursively, to see if you can make that switch in your mind and think about problems in two different ways.
A well-known algorithm can be as simple as find the maximum in a list:
2. Implement a Trivial Algorithm
Even if a question seems totally nonsensical, it’s probably related to something you've learned. They won't ask you to solve a rocket science problem if that's not your background.
“When I was interviewing at Microsoft, I had to solve a maze with some restrictions. They wanted to see how I could take some of my foundations and work through the problem to solve the specific task”- Anil
3. Solve a Brainteaser
"If you stacked one dollar bills from the street to the top of this building, what is the volume of those dollar bills and would it fit under your desk?” What assumptions do you make? What prior knowledge do you use? How do you make all that work together to come up with the solution
Now, does the interviewer care if it's correct? Probably not. It probably won't be strictly technical; you won't write a function, you don't have to know syntax, you don't have to whiteboard it, you just have to talk through how you would figure out the problem as a human.
4. Answer a Language-Specific Question
A company may be heavily based in a specific technology stack like Rails, and may feel that in order to be productive, you should already have those skills. Usually, the job posting will say require “X years of experience,” but these language-specific questions may be a way of sussing out how much you actually know.
What’s the difference between a technical interview and a traditional interview that we’ve all been through?
Anil: Unlike an interview for a job outside of tech, where you may talk about the things you already know, a technical interview isn’t as much about the “right” answer. Rather, it’s about your thought process, how you approach problems and how you work with a team. As an engineer, you spend a lot of your day not knowing the right answer, but finding your way to it. Technical interviews are trying to suss that out.
Mark: In a non-technical interview, you talk about your past and your accomplishments. When I was coming out of business school, the STAR interview (Situation, Task, Action, Results) was hot. In a technical interview, it doesn't matter what you did in your past. It's about your present. How do you work through a problem? Instead of recalling facts about yourself, you’ll be presented with a problem, and you’ll try to display how you work through it.
Should a bootcamp grad be surprised or hesitant if they are not asked to do a technical interview? Is that a red flag?
Mark: That would really depend on what else is involved in the application process. Did you get an overnight code challenge or do you have a GitHub account where the company can see your code? If someone hires you without seeing any of your code or any of your thought process, I would consider that a red flag. If they don’t have other mechanisms, like HackerRank or online tools to automatically assess technical skills, then that sounds like the company is either desperate or doesn't know what it’s doing.
Is it cool to ask the interviewer for guidance ahead of time – like what technology or language they should brush up on?
Mark: We have plenty of students that go after C#, Java, etc jobs. We try to teach you to learn how to learn. Picking up your second and third language will be an expedited process. We absolutely see people that get jobs straight out of Dev Bootcamp in a completely different language.
In fact, none of our students’ final projects are built in Rails! Everybody chooses to build iOS apps in Swift or they use a tool like Ionic. They are hungry to learn something new and build something a little bit different than what they've learned throughout the curriculum. So if someone knows that they’re interviewing for a C# shop, then they can research the language, spend two weeks brushing up on C#, and hopefully be prepared for the interview.
What's the best way to handle a question that you flat out do not know the answer to? Do you have advice for that situation?
Anil: I had a conversation about this yesterday! One part of answering a question is knowing your own boundaries. If you just ramble and clearly have no idea, then that’s a red flag for an interviewer. There is so much value in saying, “Listen, I’ve never used this method before.” That’s a totally reasonable starting place.
No matter what the problem is, you have some familiarity with it. Find what you're comfortable with and then just start exploring outwards, asking questions. Apply the thought process to how you would solve the problem.
Mark: If you're asked about a language or a framework that you don't know, you're probably being asked by someone that has potentially years of experience in it. You're not going to be able to fake your way through that, so definitely own your ignorance.
You could even ask for some guidance like, "How would I change the method signature to match this new language? What do I need to do to make sure that it's the right return statement? Do I have this type of data structure available?" Do not try to fake your way through it. It will look much worse than admitting your ignorance.
In what formats might a job candidate be asked to answer questions in a technical interview?
Mark: This is going to be completely company-dependent, but here are a few ways you could be asked to answer questions in a technical interview:
- You could be asked to whiteboard in front of 1-3 people, and maybe spend a full day at the company’s office.
- Others might give you an overnight assignment, which you complete remotely. A remote assignment more closely resembles your actual job; there's less pressure, you can research answers, look at Stack Overflow etc.
- You may have a phone interview, where you’re asked some simpler questions that you can answer verbally.
- As more of these tools are available online to give (and grade) coding challenges remotely, you’ll see those incorporated into your interviews. Technology is evolving and companies have varying levels of adoption.
Remember that if you’re invited for a technical interview, you can ask, "What's the process? What's the first round of technical? What's the second round of technical?" There are no hard and fast rules, but most companies will eventually have you do an in-person whiteboarding session so it will be hard to avoid that entirely.
What's the craziest interview questions that you've ever been asked in a technical interview?
Mark: I got the Die Hard question! Bruce Willis and Samuel L Jackson are in Central Park, they have a three-gallon jug and a five-gallon jug, and a bomb's going to explode if they don’t get exactly four gallons. And I remember getting this question and being like, "Why can't I remember what Bruce Willis did??” But then I realized that if I just knew the answer from the movie, then this would be a trivia question. Since I actually had to work through it, it was way more helpful for the interviewer. And actually, though nerve-wracking, more fun for me.
Anil: When I was working at Microsoft, I interviewed for Bing, and had to go through the full interview loop again. One of the questions was “How would you implement Bing?” I had to step back and think about what it even means for a search engine to work. The follow-up was, "Create a search sort algorithm!" Entire companies are formed to answer these questions. That was a tough one.
(that are not the correct answer)
Showing that you’re genuinely curious about how to solve a problem lets the interviewer know that you're going to be excited about the job. Even if problems are hard, you're going to be a net benefit to the team. Even if you lack some technical expertise at the time of the interview, they know that your curiosity is going to drive you and bring energy to the team.
If you leave the interview and the team is more excited than when they started, you're in a really good place.
2. Showing your thought process in the interview
The whole tech industry is about being creative. Unlike a math formula, where there's one right answer, a lot of computer science is about art and solving problems in new ways. In the same way that nobody knows every programming language, nobody will know every perfect solution to a problem. When I'm interviewing a candidate, I’m not looking for the correct answer; I want to see that they can solve the problems we’ll face in the future.
By communicating your thought process:
In any job, you’re going to get stuck. If you can't communicate your thought process, your team members will have to read your code (and read your mind) to figure out what you are trying to do. If you can communicate your thought process, you can expedite the solution.
3. Ability to break down a huge problem
Remember: What are technical interviewers not looking for? The perfect solution!
Nobody is a human compiler, so if you're writing on a whiteboard, your interviewer is not going to highlight every single syntax error. It doesn't even matter if you give the correct answer. Most software developers are wrong one hundred times until that last time when you're right. What’s more important is the process, communication, curiosity, and motivation to work through those problems. The perfect solution is an afterthought.
How does Dev Bootcamp prepare students for their technical interviews?
Anil: At the Seattle campus we start with “interview credits” at skilled which is an online service for students to get practice and feedback with technical interviews. Every weekend, students get to practice whiteboarding with a partner from Microsoft who comes into the classroom.
Dev Bootcamp is all about building the foundation and learning how to learn, so that when you get an unfamiliar interview question, you don't just stare at it blankly because you don’t know the exact answer. Actually, the whole coding bootcamp space does a good job of preparing folks to take whatever they do know and get started in the right direction.
Mark: All Dev Bootcamp campuses have a career team on site. In Seattle, Lacey is just killing it, doing great things, and Kevin works in our San Diego campus. In San Diego, we have partnerships with Intuit and other local San Diego companies. Dev Bootcamp also has a larger careers team, working on more global initiatives.
In the Dev Bootcamp curriculum, we don't jump straight into web development. The first week is 100% algorithms. You learn concepts iteratively, recursively, etc, so that when you're studying for a technical interview, it's not the first time that you've broken down an old-school, algorithmic problem.
In San Diego we do Marker Mondays or Whiteboard Wednesdays (I love alliteration), and our current students will whiteboard in front of the rest of the class of 10 to 20 people! That makes a real interview with two to three people less nerve-wracking.
What's your advice to employers who are hiring bootcamp grads?
Anil: That is such a good question and it's one that I wish folks would ask more often. As employers, we have to come up with solutions rather than taking the same old hammer and applying it to a new problem. The software industry is changing and companies that change with it will win; the ones that don't will not have the talent they need going forward.
The bias in technical interviews is that graduates of a traditional four-year CS program will focus a lot on underlying math and get a very deep and layered approach to CS. Compare that type of applicant to a bootcamp grad, whose strengths are that they can make things, they're hands on, they’re problem solvers. When I got a job at Microsoft, I didn't actually know how to write software. I knew the theory behind it, and could speak really well to algorithms and the running time of programs. But if you actually asked me to make a Rails app, I wouldn't know how.
A good employer will look at the strengths of a coding bootcamper. They don’t actually care if these candidates can make a super mathy search algorithm. There are so many jobs out there, where you have a lot of tasks that are going to have real consumer benefits to your company, and they just involve solving problems. The students who leave Dev Bootcamp with the best ability to learn and grow and make things are the ones that do the best.
Mark: I would hesitate to say that any employer should change their interview for a bootcamp grad versus a CS grad. I think they should change their interview for the job they're trying to fill. If you need an algorithm writer, then ask about algorithms. But if you need someone who can develop applications, then ask about how to develop applications.
Do you think that technical interviews (ie. whiteboarding, etc) are accurate measures of a developer’s potential?
Anil: We’ve been talking about typical technical interview questions today, but that's not an endorsement of the current process. FizzBuzz and BubbleSort are terrible questions to ask a web developer because you'll never do that on the job. In what other industry do you ask about things that you do zero times on a job?
David Heinemeier Hansson, the creator of Ruby on Rails, tweeted in February, “Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time.” There was a time and a place for implementing sorting algorithms but there are so many widely available libraries now; it would be silly to write your own.
Could you share your favorite resources for practicing technical interview questions?
Mark: My first plug is for this Git repo called "Hiring Without Whiteboards," which is a collection of companies that don't use the traditional whiteboard interview. Use that as a resource to see what companies you want to interview for.
To practice for the whiteboarding or technical interviews in general, the resources I've used in the past are Project Euler (good for learning new languages and solving problems differently), HackerRank, Codewars, Exercism.io etc.
4 Benefits to Learning React
Should you learn ReactJS? See tips from a Sabio Grad!
5 Signs You Should be a UX/UI Designer
After interviewing 2000+ applicants, DESIGNATION's Will Shandling knows what makes a great designer.
How to Kick Imposter Syndrome
How do you overcome imposter syndrome during and after coding bootcamp?