This post is part of our new blog and video series dedicated to the “First 5 Years in Software Development.” This series was created specifically for early professionals coming out of school, as well as those who may be making a career change from another field or role into software development. Topics will include how to get your first development internship, tips for optimizing your resume, advice for your job search and interviews, navigating the corporate ladder, and more. Stay tuned for new posts and videos each month. 

As someone that’s been a developer for 8 years, I’ve participated in my fair share of interviews. After graduating, I spent 10 months finding my first position and ended up “stuck” in that position for five years before I figured out how to take charge of my career advancement. Within a year, I took a new position from a LinkedIn cold contact that included a 33% pay raise. I wrote this article to help others to figure out how to accelerate their first few years as a software engineer and start building a career. 

Before you can even get an interview, you must first do your due diligence to build your skills and refine the presentation of those skills on your resume, website, or portfolio. 

The interview process differs dramatically depending on the company and job you’re interviewing for. Some companies want you to interview for a full day, and others may opt for half a dozen interviews spread out over a week or longer. However, most interviews have a common set of questions related to your general technical knowledge, culture fit, peer interaction, prior experience, and likely some type of problem-solving puzzle. Let’s take a look at how to tackle these types of interview questions.

Pro Tip: If you want to study developer interviews as much as possible, you may want to investigate “Cracking the Coding Interview” by Gayle Laakmann McDowell.

General Technical Knowledge

While there’s a good bit of technical knowledge necessary to be a developer, it’s important that you understand more generalized principles regarding application deployment and interaction channels. 

Some common general knowledge questions you might get in an interview include:

1. How does a REST API work?
2. What is CI/CD and why is it important?
3. What are some basic ways to prevent application/website failure?

These questions tend to be centered around how something works in base principles. One way that I prepare for these questions is to simply use Wikipedia to look things up while reading job descriptions. I also tend to keep a list of terms that I’ve come across in a folder titled “meetings/documentation/online reading” to research later. This is very high-level research and shouldn’t take up much time. 

One of the worst answers I ever gave to a general technical knowledge question came when the interviewers asked me how my team was using Spring. Were we using Spring Framework or Springboot? I didn’t know, and I’d been advised once that I didn’t need to know about that stuff, just don’t mess with the xml files unless you know what you’re doing. I said something to the interviewer about “we just use spring configuration” because we had lots of secondary applications that were configured to run by altering xml files parked on the application server. 

Failing at this question would later lead me to dive into learning Spring Framework and Springboot. After completing the Java Brains playlists on both, I was more knowledgeable about Spring than anyone in my organization and able to help with much more advanced configuration things than others were able to understand. You must let your failures guide your growth. 

Culture Fit

When you work closely with a team, it’s important that everyone gets along. You don’t want any major personality conflicts. It can be quite costly to hire a person, train them, and then ultimately find out that they don’t jive well with their team members. This is why interviewers spend a significant amount of time asking “culture fit” questions, to see if your attitude, personality, work ethic/preferences mesh well with those you could potentially be working with.

Some common culture fit questions you might get while interviewing include: 

1. What about this role appeals to you most?
2. Tell me about a lesson you’ve learned from the workplace over the years.
3. If we asked your coworkers how they’d describe you, what would they say?

The thing about these types of questions is that you don’t exactly fail them. If a company doesn’t believe that you are a good fit with their culture, it likely means that you wouldn’t have enjoyed the job anyway. It’s a two-way street. You want to make sure that you are working for a company that is going to fit with your values, and they want to find an employee that fits with theirs. 

I personally tend to bring out my own culture fit concerns and questions as early as possible. For example, when answering question #1 above, I’d say something about their modern cloud-based tech stack, automated deployment process, and that they place an emphasis on life-work balance. This is because I have four kids and a wife that I love dearly, and I don’t enjoy spending nights and weekends doing work. If these things prevent a company from wanting to hire me, then it’s for the best. 

Regarding question #3, I once took the time to ask all my closest coworkers to list how they would describe me and what makes me different than every other developer. The experience allowed me to learn a lot about myself and helped me prepare to answer similar questions in the future. I wrote about this previously on my personal blog in a post titled, “Know Your Brand.”  

Peer Interaction

If you are someone that works well with others, then you can overcome a lot of technical knowledge deficiencies. On the other hand, a technical person that can’t get along with their peers well will often have major issues getting hired.

Some common peer interaction questions you might get during an interview include: 

1. Tell me about a time that you had a problem with a coworker and how you resolved it. 
2. What would you do if a manager assigned you a new task or project right before you were about to leave for the day?
3. How do you prefer to receive feedback on your performance from your managers and peers?

With these types of questions, there’s a lot more nuance than just right and wrong. In my opinion, the answers should show professionalism, a bit of compassion, and respect to authority. Again, we’re talking about personality and not something that is entirely clean cut, so answer honestly and let your personality come through. 

Prior Experience

I’ll be honest and say that a lot of developers feel that many of these questions are somewhat dumb. Ultimately, your ability to work within the framework of these sometimes silly-feeling questions can demonstrate your ability to think critically under pressure. 

One of the best ways to do this well is just to practice. There are many lists of questions that can be found online as well as suggestions for how you might approach an answer. I’d urge you to think through answering many of these questions on your own so that you have some examples prepared already. 

When you get any question like “explain a time when…” feel free to bring the answer around to relate to a previously discussed topic. This will allow you to tell multiple parts of the same story, and ultimately make yourself more human. Stories that you want to use in these questions will be the times that you faced issues and came out looking like the hero. 

What the interviewer really wants to know is how you face problems and whether you are willing to grow and learn to make things happen. To answer these questions, consider using the following formula: “the team had [x] need and I learned to do [y] in order to fill that need resulting in [z].” 

Some common prior experience questions you might get in an interview include:

1. What’s a time that you faced significant difficulty at work and how did you overcome it?
2. How do you normally learn about new things?
3. What kind of projects have you worked on before?

Problem Solving Questions

The most dreaded of all interview activities. It’s true that these can be challenging questions, but with practice, you can really help yourself stand out from other candidates.

These questions or tests can take the form of LeetCode puzzles, take home assignments, or whiteboard problems. The more that you know about data structures and algorithms, and the more coding puzzles that you’ve completed, the better you’ll be at completing these types of interviews. 

LeetCode (or similar) tasks can be the most frustrating, particularly the ones that you are supposed to do at home. I specifically remember doing the one for Amazon some years ago and there were two puzzles that should each take a half hour. If you are currently employed and have children, then it is highly likely that you’ll be doing as I did and working on this after you should have been in bed. That can be a draining process. Practicing coding puzzles repeatedly is ultimately the best thing to help you with these. 

Whiteboard interviews are not loved in the industry, but I believe that, if handled correctly, that they do a much better job of testing your ability to solve problems. When you’re on the job, you’ll have the ability to ask clarifying questions of whoever is assigned to the project, and that’s a big part of being successful in these interviews. Treat it like you are working collaboratively with the interviewer.

You want to talk through everything when doing these. “We need a function [x] that takes [y, z, w] arguments and returns [q]” is a wonderful strategy to get started with. It allows you to clarify the data that is available and needed. I also like to include “we’ll assume that there exists a function that does this other thing called [fubar]” and that can allow you to address the algorithm needed at a higher level than otherwise. If you are sorting something, then it’d be really helpful to have a function that compares the priority/order of two objects. Ultimately the thing being determined in this interview is what your thought process and problem solving approach looks like. 

Some common problem solving questions you might get while interviewing include:

1. Implement bubble sort on this very specific data.
2. How would you figure out if there was a loop in this graph structure?
3. What are some ways that you can break down a very large data set so that you can analyze it?

Final Tips for Nailing Your First Interview

Practice:  

There’s something to be said about mock interviews, but even just talking to other developers in any context can really help. Give yourself opportunities to practice by showing up to group meetups, giving lightning talks, attending code reviews, and finding online or in-person communities discussing coding challenges. 

Come Prepared:   

Recruiters like it when you’ve done your research and can relate a question back to the company motto or one of the brand pillars. It’s always a good idea to look at the company’s website and read through every bit of “about”, “mission”, or “bio” sections that are available. This helps you to make sure that the company aligns with your values and helps you to figure out what are the types of things that you should be highlighting as you talk about yourself. 

Ask Questions:    

Come ready to ask a few questions about the position or the direction of the company. Asking questions shows that you are also checking to see if the position is a good fit for you and is impressive to a hiring manager. There are many online lists of questions that you can ask, but in my experience, the best questions are the ones that are important to you. If you’ve had a really bad experience with working nights and weekends and you’d rather avoid that in the future, then I’d ask how often there is work outside of normal hours. 

Regardless of your values, you can always jump off with “describe what a typical day in this role looks like.” And then be sure to listen through the answer and see if there is anything that you want to hear more about. For me “we have a pretty good work/life balance, but sometimes when there’s a deadline, we do what we have to to finish” would naturally lead me to ask “how often in the last year have there been deadlines that required working outside of normal hours?” The answer here could help me decide whether I want to pursue the job or search elsewhere.

Final Thoughts:

The tips I’ve shared above were learned through my own experiences, and they have helped me immensely in my career. If even one tip or insight is helpful to you in your own job search, I will be very happy. I wish you the best of luck. May you find great roles and companies, and build a career that fulfills you.