8 Myths About Your First Software Engineering Interview
Preparing for your first set of software engineer interviews is like getting ready to venture into the unknown. What kinds of questions are asked for entry-level software engineer jobs? What skills should I demonstrate? Will I ever get a job offer?
One of the challenges in preparing for your software engineering interview is that many misperceptions surround the hiring process. To debunk some of these myths, we decided to list eight of the most common we’ve seen.
Want to talk to experienced software engineers, engineering managers, and hiring managers? Merit’s mentors can help you with mock interviewing, resume review, and breaking into tech. Sign up today to connect with a mentor who can help you launch and grow your software engineering career.
Myth #1: Coding is always the most important part of entry-level software engineering interviews.
Reality: It depends. Although all companies want to know you have basic coding skills, larger companies typically prioritize technical ability over other factors. Smaller companies, meanwhile, may care more about your ability to collaborate and work with a team. Larger companies of course still care about your soft skills, but they may place more weight on technical ability.
Software engineering jobs at smaller companies tend to be about more than just software development. Jai Sandhu, Engineering Manager at DoorDash, adds, “With smaller companies, there’s more weight on someone who can be more scrappy. The roles tend to be less well-defined. You’re expected to do a lot outside of coding.” This might take the form of ideating with product managers, participating in QA, attending customer interviews, and more.
Additionally, smaller companies may place an emphasis on cultural fit and if you share their company values. Because the number of employees is a lot smaller, a new hire will be interacting and collaborating with most if not all of the employees. One negative hire in a company of 50 people can have a much bigger impact than one negative hire in a company of 1,000 or more.
Charles Garrett, Engineering Manager at Pagoda, says that the ability to work with non-engineers is important because “You need to be able to grow to understand how to collaborate with people with cross-functional skills, working with design [and product] and get into that rhythm of the back-and-forth of working with people as you make incremental steps towards accomplishing some goal together, as opposed to working completely on your own in a silo.”
Myth #2: Every company does interviews totally differently.
Reality: Like myth #1, it depends, but in general, once a company reaches a certain size (~200+ employees), they’ll standardize their recruiting process to match those of other companies. An exception might be very big tech companies like Google or Amazon that may have created more customized interviews.
In general, if you’re looking at any company with more than 200 people, you’re most likely going to have an interview process that looks something like this:
- Call with the recruiter. They’ll tell you about the company and the role, and they’ll also gauge your interest and if your background meets the job requirements.
- Phone screen with the hiring manager and a coding exercise. The hiring manager is getting a basic sense of your coding skills and whether you’re a behavioral fit.
- Full “on-site.” (”On-site” can be a bit of a misnomer since many of these interviews can be conducted partially or completely remotely.) At this point, you’ll have several interviews back-to-back.
Depending on if you're interviewing for full-stack, front-end, back-end, or mobile, the live challenges may have different names or be focused on different skills:
- Second chat with the hiring manager
- Systems design challenge
- Coding challenge
- Behavioral interview with an engineer
- Behavioral interview with a non-engineer (product, design, etc.)
You may also have an additional take-home assignment, although these types of assignments are falling out of favor. A senior software engineer at a post-Series D company shared:
You're guaranteed to do a coding exercise by Phase 3, but in many orgs it'll occur during Phase 2, to make sure you can code (it is unlikely to be very hard but will probably test your reading comprehension of requirements and your familiarity with the syntax of your chosen language). Interviewers will look not only for you to complete the exercise in time, but also to use debugging skills to unblock yourself and would want to know how you might refactor the code after you've written it.
Myth #3: Asking your recruiter questions about the interview ahead of time might make them cancel it.
Reality: You may have lots of questions about what will happen in the interview: What type of coding challenge will be given? Can I use any language in them? What will each interviewer be looking for when they speak with me?
But you might be frightened to ask! What if by asking questions about what to expect in your interview, you say the wrong thing and the recruiter decides not to move forward with you?
By the time you’re scheduled for the full on-site interview, recruiters want to make sure you do well—it’s in their best interest. Often, recruiters’ job performance is measured partially on how well the candidates whom they source perform in interviews. It's unlikely that by asking a question in preparation would lead to a cancellation.
Recruiters may not be able to answer every question (they either may not know the answer or it’s company policy not to tell you), but they do want to help you succeed.
Myth #4: You must always learn the languages in a company’s stack.
Reality: It’s better to show proficiency at the languages you already know well than to try to learn a new one for a specific company. Unless a company doesn’t have the time or resources to train you in a new language, they'd rather focus on how you think and solve problems over the language you use.
Let’s say you know Javascript really well, but the company you’re interviewing at uses Dart. The interviewer would prefer to see you show off your Javascript knowledge than struggle through trying to use Dart.
Interviewers are looking for how you approach problems, how you debug code, and how you take feedback—and less about how well you know the company’s language(s).
Chloe Isacke, Software Engineering Manager at Retirable, says, “I don’t feel very prescriptive about languages or frameworks; I’m not really necessarily looking for someone who has experience in our tech stack. We really care about engineers who are mission-aligned and have the same culture and values alignment. That can be the most important thing: drive and interest in the problem we’re trying to solve.”
If you’re not sure if the company you’re interviewing with wants you to know the languages in their stack, ask the recruiter if the company has a preference on which language you use in the interview.
A notable exception: If you’re interviewing to be a specific kind of software engineer, like middleware or iOS, you’ll want to know the languages that are common in that area.
Myth #5: If you’re a bootcamp grad, interviewers don’t want to hear about your experience before you went to bootcamp.
Reality: When you’re interviewing for your first job after bootcamp, interviewers really want to hear about your work experience before bootcamp. As mentioned before, it’s not just coding ability that matters in these interviews. You need to show off your soft skills (organization, collaboration, ability to accept feedback, etc.).
If you’ve worked at other companies, you can definitely highlight times you handled interpersonal conflict, delivered a project with a team, accepted or given difficult feedback, and collaborated with people outside your department.
Arjun Kannan, co-founder of ResiDesk, adds, “Any life experience you can bring to the way that you present yourself, even outside of the bootcamp, is still relevant. You don't have to erase your history from before the bootcamp to be successful at getting a software engineering job.”
Myth #6: Only software engineers will have a say on if you’re hired.
Reality: More often than not, you’ll have at least one interview with a non-engineer. This person may be a product manager, a designer, or other engineering-adjacent role. These folks will usually want to check if you can work with other folks beyond engineers and communicate well.
To prep for these kinds of interviews, read up on what product managers or designers do or chat with other folks in that role to get a sense of what their day-to-day is like.
Especially at early-stage companies that are still building new products, they want to know you have skills beyond coding that will help you work well with product managers, designers, and other engineers. Isacke explains:
Earlier-stage companies are looking for more "product engineers"—people who come in and have at least an opinion about product and design and can take initiative. They’re well-rounded, not just in terms of the stack they can work on. They’re comfortable talking to customers and collaborating with others. That becomes a lot less emphasized for [later-stage] companies—they want engineers to come in and execute the existing product.
Myth #7: Interviewers don’t want you to ask questions during the interview.
Reality: One of the biggest things interviewers look for is if you’ve researched the company, you’re genuinely interested in the role, and you want to know more. Without exception, every engineering manager we’ve spoken to told us it’s a red flag if the interviewee doesn’t ask any questions or asks vague, generic questions.
Asking questions in an interview is one of the best ways to learn what it’s really like to work at a company and determine if the role is a good fit.
To prepare your questions for the interview, you may need to do a little homework by writing down 2-3 questions you can’t find the answers to online. Interviewers appreciate it when you ask questions that aren’t easily answered on the company’s website or blog.
If you’re not sure what questions to ask, you can think of these three broad categories to get you started:
- The company itself: the business model, the direction of the company, its long-term strategy
- The team: how the team works together, its operational process (do they use Kanban? Agile?), its practices (frequency of deployments, what types of tests are written)
- Yourself: What would I be doing in the first 30, 60, 90 days? How will my success be measured?
Isacke shares, “You can bomb an interview, but if you ask good questions at the end, you can completely change course. You have so little control over what technical and cultural questions you’ll get asked, but you’ll know what you can ask at the end.”
Myth #8: Only “real-world” development experience counts.
Reality: If you haven’t yet worked as a software engineer, you may feel in despair that you can’t get experience because you don’t have experience. But you don’t have to have worked as an engineer to land the job. Highlighting side projects you’ve worked on can help you demonstrate your interests and your ability to think about building products as a whole. Make sure it’s unique to you and something that genuinely interests you.
Kannan provides some additional advice on side projects:
Highlight your side projects in a way that shows not just the fact that you did the extra work, but that it’s yours, because it seems like everybody and their mom has a GitHub repo right now and they all have projects; it's really easy to clone things and work on a few small things and say that it's your side project. But try [to] have something that was fun for you, because if it comes up, especially with an entry-level job, most people are looking for evidence that you can actually figure out how to do things without needing 100% guidance. Sharing the side projects is significantly easier if you can also demonstrate that you took initiative and you had something to talk about with those projects.
In conclusion
Demystifying the software engineer interview is one way you can go into your interviews with more confidence. Although knowing everything about an interview ahead of time is impossible, you can go in knowing more about what you can expect and how to be successful.
One of the best ways to feel more prepared is to do mock interviews. The more engineering managers and software engineers you speak to, the more you’ll learn about the kinds of questions will be asked for entry-level software engineer jobs and can practice your answers.
Merit has many mentors available to help you with mock interviewing. When you sign up for Merit, you get instant access—for free—to hundreds of tech mentors.