7 Easy Ways to Shine in Your Next Coding Interview

Updated on | Sign up for learn to code tips

Nervous about your next big job interview?

With tech skills in such high demand, it can be tough to know how to stand out from the crowd in interviews. In this special guest post, Yaphi Berhanu, founder of Simple Steps Code, gives you some simple techniques to impress recruiters without learning any new tech skills.

Note: If you’re trying to prepare for a virtual interview, rather than an in-person one, check out this post too to learn about the remote interview process and get some top tips for success.

Recommended resource: Interview Cake

Here’s Yaphi!


Job interviews can be scary.

It’s normal to have doubts and worries before the big day. What if you don’t know enough? What if you say the wrong things? What if you embarrass yourself?

Breathe easy. I’m here with good news.

There are several things you can say and do to sound instantly more impressive with the knowledge you already have. Having been on both sides of the interview table, I can assure you these tips work.

While the advice in this article is not a substitute for knowing your stuff, it will help set you apart from other candidates. It’ll also protect you from getting stuck and having blank moments during the interview.

By the end, I aim to give you more confidence in tackling your interviews.

Tip 1: Frame Answers in Terms of Who Will Be Impacted

When answering an interview question, people often give the technical solution without thinking about who the solution might affect.

This is a missed opportunity.

For example, consider the question, “What’s one way to make a website load faster?”

Answer A:

“I would compress images to make a website load faster.”

Answer B:

“I would compress images to make a website load faster. That’s really important because faster sites create a better experience for the users, so they’re more likely to stay on the site. That directly affects revenue.”

Both answers are correct, but Answer B looks much better despite showing the same level of technical knowledge.

So what’s the difference?

Answer A gives a solution, while Answer B explains who that solution affects and why. By framing your answers this way, you show an ability to put your work in context and understand the reasons behind decisions. In Answer B, the candidate has shown empathy for the users and a strategic mindset for the business. Not bad for two extra sentences!

You can apply these insights to any stage of your interview. For example, when discussing your skills, experience, or personal projects, try asking yourself, “Who does this affect?” A good guideline is to consider the users, the business, and the team.

Phone connected globe

Discussing a code demo you built?

Talk about your learning process. This shows you’re able to pick up new things, which is a crucial skill that will save time for your team.

Discussing a personal project?

Go over what you did well and what you would have done differently in terms of the users, the business, and the team. This shows awareness and growth in your thinking.

Tip 2: Name Things Clearly

In the heat of a coding interview, it can be tempting to give shorthand names to JavaScript variables, CSS classes, or whatever else you might be naming.

Resist this temptation.

At first, you’ll save some time by naming a function “se” instead of “submitEmail” for example, but you’ll waste much more time trying to keep track of what “se” means later on.


Here are the benefits of clear naming:

  • Clear names help you keep track of things. This frees up brainpower to work on a problem instead of remembering a bunch of abbreviations.
  • Clear names help your interviewer see your thought process. This is especially important because interviewers tend to care more about the thought process than the answer. An added benefit is that if you don’t finish a question, an interviewer who has followed your process will be able to give you a good amount of partial credit.
  • Clear names show that you write understandable code, which is crucial on a team where multiple people work on the same codebase.

Tip 3: Lay Out the Puzzle Pieces

In interviews, too many people jump straight into an answer without first taking a step back to assess the situation. This approach makes it too easy to get lost.

Instead, try laying out the following pieces in verbal or written form:

  • What information do you have?
  • What information is missing?
  • Are there diagrams you can draw to simplify your thinking?
Puzzle piece

Here are the benefits of laying out the pieces before jumping into an answer:

  • You’ll narrow down exactly what you need to solve.
  • You’ll have an easier time keeping track of progress so you won’t get lost.
  • The interviewer will be able to see your thought process.
  • Connections will start to appear among separate points.
  • Gaps in the information will reveal themselves, making it easier to ask clarifying questions.
  • Instead of stalling at the beginning of a question, you’ll have a structured and logical way to make progress. This will give you time to think and help you feel more confident.

Tip 4: If You Don’t Know, Say How You’d Find Out

Sometimes, you’ll run into a question you’re not sure how to answer. This is an opportunity to show how you find new information.

Start with what you know, and narrow down the missing parts as much as possible. Then you can discuss specific search terms and reference materials you might use. For example, if you’re not sure of the difference between “substr” and “substring” in JavaScript, you can talk about how you’d look them up in the MDN.

Next you can talk about what sorts of code snippets you’d write to test concepts and answer your own questions. For example, if you’re not sure how a certain CSS position will look, what code would you write to test that?

By discussing how you find new information, you can actually impress an interviewer more than by knowing the answers right away. Technology is constantly changing, and so how you learn is arguably more important than what you know.

Tip 5: Narrow It Down, Then Ask

Suppose a question completely stumps you. You’ve laid out all the information, you’ve found the gaps, you’ve drawn diagrams, and you’ve talked about how you’d find some of the missing info, but it’s not enough.

This is a great time to ask a question.

Question mark

Since you’ve done the work of laying out the available information, you’ll have an easier time being specific in what you ask. When your question is specific, you’re more likely to get a helpful answer while showing competence in the process.

By asking for help when you’re stuck, you also show that you’re willing to learn and willing to admit when you don’t know something. This sets a collaborative mood, which makes it easier for your interviewer to envision you on the team. It also says good things about your personality.

You don’t have to wait until you’re stumped to ask a question. In fact, it is useful to ask questions early to check assumptions and clarify requirements. A quick clarification in the beginning can save you from going too far on the wrong track. This is especially important as you’ll encounter many situations in any job where a quick question at the beginning can prevent tons of wasted effort later on.

Tip 6: Mention Input Validation If It Makes Sense

Input validation means making sure the input is what you’d expect. For example, if a form asks for someone’s age, you can validate the input by checking that it consists of numbers and not letters.

Input validation is a quick win that lets you get immediate points before you’ve started to figure out an answer to an interview question. You won’t necessarily have to validate input during an interview, but at least asking about it shows that you pay attention to these things. As a result, you boost the interviewer’s confidence that you won’t write buggy code.

Another benefit of mentioning input validation is that it builds momentum. Instead of stalling at the beginning of a question, you have immediate steps you can take to score points while buying time to think. This approach also helps build comfort in talking through your thought process.

Not every question will have an opportunity for input validation, but on the questions that do, give it a mention.

Tip 7: Prepare A 30-Second Opening Story

You can gain a huge advantage with a quick overview of your experience and how it relates to the company you’re applying for.


A quick, relevant intro lets you dictate how you’re perceived instead of leaving it up to your interviewers and hoping they give you the right questions. Here’s how this approach might sound:

Interviewer: “Tell me a bit about your background.”

You: “Okay, so in terms of front-end development, I’m very interested in responsive websites and JavaScript performance. [Optional sentence: I’ve worked on A, B, and C, and I’d like to try more of Z.] I’m excited to work with your company because I’ve noticed you do a great job with responsiveness and performance on your homepage. I think we can make your site load even faster by compressing the masthead images and combining CSS files where possible, and I understand there might be constraints we need to work around. Either way, I’m excited to come in and see where I can make the biggest impact. If you want, I’d be happy to do a quick walk-through of my portfolio.”

Let’s break down the elements of this introduction.

Lead off with the concepts, tools, or subjects you’re interested in. The phrasing is important. By saying you’re interested in a particular concept, you communicate understanding and enthusiasm without having to rate yourself. You get to display competence without doing the dance of “I’d say I’m an X/10 at JavaScript,” or “I’ve been doing this for X years.”

What's your story

Briefly mention your experience if it makes sense for you. When doing this, pick key highlights that can fit into a sentence or so. For example, “I worked at A, B, and C, and I was most excited about doing Z.” If you don’t have coding work experience, you can mention a relevant personal project. The point is to bring up something concrete you’ve done so that your interviewer will see you’ve done something relevant to them.
Say what you like about the company and why you’re excited to work there. The more specific you can be, the better. This immediately shows preparation, competence, relevance, and enthusiasm.

Mention one thing you can do for the company. For example, you might bring up improvements to performance, user experience, code readability, or maintainability. Maybe you know about a big upcoming company goal, and you can mention how you’ll help with that. It also helps to mention constraints because it shows awareness that there might have been outside factors preventing the team from making the suggested improvements in the first place.

End with your enthusiasm to get started, and transition into your portfolio. In the worst case, they’ll say they don’t have time to look at it, and you’ll look extra prepared. Most of the time, you’ll get a yes, which is great. Showing your portfolio lets you present your best work on your terms. You can draw attention to your strengths in a memorable way rather than wishing the interview focused on your good points.

A crisp opening story is crucial in setting the tone of your interview. It’s the difference between a professional introducing themselves versus a student nervously showing up for a test.

Feel free to mix and match these five elements or remove them as needed, but whatever you do, keep your intro short. You don’t want to start rambling and have them cut you off to move on. Aim for no more than 30 seconds.


Part of what makes interviews scary is the uncertainty about what might happen.

The best defense is to focus on the things you can control. For example, a strong intro can ensure that you cover your good points instead of hoping your interviewer asks the right questions.

Whenever possible, show that you’re thinking of the users, the business, and the team. This will frame you as a smart, practical thinker.

If you ever get stuck, start by talking through what you already know. Then identify the gaps, ask questions, and explain how you’d find out the things you don’t know.

With these tips, I hope you’ll be able to walk into your next interview with confidence.

If you happen to be interested in front-end web development, feel free to check out my quick, step-by-step guide on how to get into the field.

About The AuthorYaphi Berhanu

Yaphi Berhanu is the founder of Simple Steps Code, which helps people become front-end web developers without feeling overwhelmed by what they need to learn. He enjoys making complex topics easy to understand, and he likes sharing secrets that help people accelerate their progress.