Hi everyone! In this article we're going to talk a bit about technical interviews. I'll share a few tips that, based on my experience, might help you go through these interviews successfully.

I originally wrote this article more than a year ago, before getting my first job offer as a developer.

I'm sharing this with you now because I recently went through another interview process. And I found that the same concepts and thoughts that helped me get my first job offer allowed me to pass all the interviews successfully again. 🙂

My Background

I took up coding more or less a year ago. I started learning out of pure curiosity, and as I learned more about it and was able to build personal projects, I just fell in love with it.

I got so obsessed and passionate about it that I dedicated all the free time I had to coding, reading about code, watching videos about code, and just learning as much as I possible could, because for me it was fun and interesting!

Time passed and at a point I started imagining myself working as a developer. First it was like a blurry thought, and then I started thinking about it seriously and learning about what I needed to do to get to that point.

My learning journey and the approach I took towards becoming a dev will probably be the subject of another article, but my point is that I made it! I recently got an offer for my first job as a full time developer and I couldn’t be happier about it.

And there were many things and learning experiences I had to go through to get to this point, but I’d say the toughest one – and the one I was less prepared for – was technical interviews.

What are Technical Interviews Like?

I come from a social sciences background, and most of the time, within that field, there’s nothing too “technical” to talk about during interviews. Employers normally hire you based on your experience and behavior during interviews.

But in the coding field it’s really different. Experience is valuable, of course, but employers also value projects you can show to them, theoretical knowledge about different programming topics, and, most of all, the problem solving skills you can show off during technical interviews.

In almost all selection processes I went through, there was a technical interview in which an interviewer tossed me a problem and I had to solve it live with them looking at me the whole time.

This is a standard practice for coding jobs, but I wasn’t prepared at all. I failed miserably more than once, and these experiences were some of the most embarrassing and frustrating moments in my professional life so far.

At times I felt stupid for even thinking I’d be capable of switching careers at almost 30. I thought I just wasn’t smart enough. But luckily I kept going, researched about technical interviews, learned, practiced, and kept failing until I didn’t fail anymore.

Technical interviews are tough and can be really stressful if you’re not prepared correctly. Also, even though I successfully passed a selection process, I know I still have a lot to learn about this and that I’ll need to perfect this skill to further grow my career in the future. So here are my main tips for nailing your technical interviews.

1. Prepare for the Interview

This is important for all kind of interviews, but for technical interviews I think it’s crucial. Your chances of passing these evaluations are way lower if you don’t prepare correctly for them.

Here are some ideas that allowed me to better prepare for these interviews.

Do Your Research

Find out about technical interviews in general, how are they normally organized, what interviewers ask and what do they intend to measure, what kind of problems do companies toss at you, and what are the best approaches towards interviews.

The internet is an infinite resource of knowledge, so don’t waste it! Google about everything you can and take advantage of the experience of the thousands of people who have gone through similar situations and share their experiences.

Practice Solving Problems

Problem solving is a skill just like any other. There is specific knowledge you’ll need to get good at it, but most of it is practice and getting your brain to be comfortable in that situation.

There are tons of websites that contain the types of problems you’ll see during interviews. freeCodeCamp has an amazing course designed for this. Some other cool resources are hackerrank.com, leetcode.com, codewars.com, exercism.io, app.codesignal.com, and algoexpert.io.

Solve as many problems as you can from any of these sites and you’ll start getting good at them.

And when you practice, at first it’s okay to just worry about solving the problem. But once you get comfortable enough, a great idea is to try to make your practice as similar as possible to an actual interview. And by this I mean setting a timer, explaining your solution out loud, analyzing your final algorithm and refactoring…just basically following all the steps you’d normally follow in an actual interview.

If your practice is similar to the actual situation, once you get to that situation you’ll feel more confident because in some way you’ve already been there.

Build a Theoretical Foundation

Besides actually practicing, learning theoretical concepts about algorithms and data structures is a great idea to get better at solving these problems.

Think about it as adding tools to your toolbox. The more tools and concepts you have in your mind, the more problems will sound familiar or ring a bell in your brain, and from that you'll be more able to arrive at a solution.

There are many resources on the internet, some free and some paid. A course about data structures and algorithms is pretty much a must for any programmer, so I encourage you to find a good one. Here are a couple you can start with:

Of course also theoretical knowledge about your programming language of choice and any other tools in your stack (frameworks, libraries, databases, and so on) is also very important.

Imitate Others

It’s ok to run into problems you don’t know how to solve or to come up with solutions that are not the best suited ones.

In these type of situations, or always actually, it’s a good idea to take a look at how other people solved that same problem and learn from them. What approach did they take? What ideas did they have? Did they get stuck? How did they move towards the solution?

Analyze their solution and their behavior, identify what works for them, think if that could work for you and if the answer is yes, copy them! It’s crucial that you deeply understand why their solution works and how their logic works. You want to internalize the logical approach, not the code, as that’s just an after effect.

Looking at problem solutions and videos of mock interviews is a good idea to get this kind of data.

Understand What Kind of Interview You'll Have

I mentioned the most classic type of technical interview is the one based on algorithms and data structures, in which the interviewer will give you a problem to solve through an algorithm.

But I found that there're also interviews that are mostly theoretical, in the sense that the interviewer will ask questions to measure your knowledge about a given programming language, framework, library, design and architecture patterns, and so on.

Another kind of interview is where the interviewer shows you an actual project or asks you to build one. During the interview you discuss the decisions you made to build it or implement new features/modifications on it.

Each kind of interview is different and might require different preparation, so it's always a good idea to ask the company what will the interview be based on, and prepare accordingly.

2. Breathe and Think Things Through

Once you've seen and gone through a ton of examples and start feeling somewhat confident around coding problems, it’s time to get to the deeper stuff.

Here are some tips that helped me go through the interviews successfully.

Don’t code

This sounds crazy right? The best approach to solving most coding problems is actually not coding, or at least not right away.

No matter how anxious or secure you are about the idea you have in mind, I find it better to always take a step back and make sure you understand things deeply before going to the details and breaking out the code.

So how do you do that?

Understand the Problem

The first step to solving a problem is actually understanding it. And to understand it, the best idea is to “make it yours”, and internalize it.

A good idea is to read the exercise twice, repeat it again in your own words, and go through multiple examples (simple ones, complex ones, examples with null or invalid inputs…).

No matter how silly, complex or simple the problem may seem, this helps you make sure you understand it properly and gives your brain data and time to come up with solution ideas.

Make Sure You Understood It

Repetitive? Yeah, but effective. Check and make sure you understood what you need to do and how your function will work.

Ask yourself, what are the inputs going to be? What will be the output? Check for edge cases. Will you always receive the same input or could you expect different formats? Do you have to be prepared for strange cases or does the exercise restrict the kind of situation you’ll encounter?

It’s better to clear out all this things before even starting to think about a solution.

Explore Your Toolbox

I said that learning theoretical concepts and practicing is like adding tools to your problem solving toolbox. When you see a new problem, it’s a good idea to explore that toolbox and see if any of the concepts or solutions you’ve used in the past could work here.

Could it help to use some sort of counter? What about implementing some sort of data structure to help you out? Could you use pointers or a sliding window? Would it be a good idea to take a divide and conquer approach? What about recursion? Could sorting the input help for anything?

You don’t necessarily have to know the exact path to take, but comparing the problem to previous patterns you’ve seen can help spark ideas in your mind.

Of course the more you practice solving problems and learning about possible solutions, the more patterns you’ll have to remember and compare.

Break Down the Problem

Once you’ve analyzed the problem deeply, hopefully you’ll have at least an idea of how to tackle it, or where to start.

A great idea here is to try to think about the different steps you need to take to get to your solution and write down those steps to analyze them, check if your logic is correct, and later use them as little memory helpers and “instructions” for you to translate into code.

Simplifying your solution through steps and specially writing them down will often help you identify flaws in your logic or cases you didn’t think about before.

This is great because you’re at a stage when it’s really easy to modify your approach or lean towards a different idea. You didn’t waste time coding or getting yourself into a maze of logic that doesn’t actually work.

Simplify the Problem

Specially when facing complex and difficult problems, a good idea is to first ignore the main difficulty of the problem and try to solve a similar, simpler version of it.

When you nail that solution, bring the main difficulty back and see if you can translate your solution to it.

Visualize the Problem

Complex problems are sometimes difficult to get your head around. Having a whiteboard, either a physical or a digital one, is always a great idea.

Visually stimulating your brain by drawing up the problem or an idea can be a good approach to buy yourself some time and see if that perspective shows you some data you didn’t notice.

Start to Write Your Code

So once you have a clear idea of the steps you’ll need to cover to get to the solution, it’s time for translating that into code. This should be the simple part if you’re comfortable enough with the language.

A thought to keep in mind here is that if you can’t remember something very specific, don’t let that hold you down – pseudo code it and carry on with the rest of the solution.

Talk to your interviewer and see if they can help you with that part, or ask if they'll let you Google it. In most cases this will be ok and the important thing will be to show that you nailed the correct logic to solve the problem.

Test Your Code

Test your solution at every step and at the end. There’s nothing more annoying than writing a ton of code and later seeing it fail without knowing the exact cause.

Test your code and your logic at every step of the solution, as this will allow you to catch bugs earlier and will save you from wasting time and effort.

Of course testing at the end is important to check if your solution actually works! So throw your function different inputs and edge cases to see if it behaves as expected.

Analyze the Solution

Once you've gotten to the solution, you’re not done yet. It’s a great idea to show your interviewer you can analyze what you did too.

Ask yourself and tell them, what’s the big O complexity of your solution? Can you think of a way to improve the performance or the memory usage of your algorithm? Is there a way to make your function easier to read and understand?

Even if you can’t think about how to code it exactly, it’s great to show them that you’re the kind of developer who is always going to look for improvements and not settle for something that just works.

Improve Your Solution

Of course, if you can find ways to optimize your solution and know how to code it, do it!

And about this, in a coding interview situation you’ll rarely come up with the perfect solution for a problem. You’re under pressure and on the clock, so it’s perfectly ok to come up with a so-so solution and then refactor it until it reaches an acceptable level.

It’s often better to show you can solve the problem even if not in the perfect way than spend all your time just thinking about the perfect solution.

Talk to Your Interviewer

Talk with your interviewer during the whole process. What your interviewer is trying to measure is your problem solving ability and your level of comfort with your programming language of choice.

That is a hard thing to measure if you don’t open your mouth and just code away.

It’s crucial that you talk to your interviewer and let them know what you’re thinking, what is your thought process, what ideas are you having, how are you understanding the problem, what logic are you going to follow with your solution and why are you making decisions.

Talk to them, ask questions, explain yourself, and if you get stuck or don’t know how to go on, explain to them exactly the thing that is giving you trouble. In most cases you’ll get some help and more importantly you’ll show them you’re actually trying to work towards a solution.

Listen to Your Interviewer

When you’re being given the problem to solve – and specially if you get tips or feedback from your interviewers – pay attention! No matter if you think you already have the best idea or if there’s something that’s driving you crazy and need to solve right now, just drop it and listen to what you’re being told.

If you don’t listen to feedback, you’re giving a very negative signal to your possible future employers. Think about it: would you like to work with someone that doesn’t listen to feedback? Besides, feedback will certainly help you solve your problem, so listen!

3. Control Your Emotions

This for me was the toughest part of the interviewing process, and it's something I didn’t really find a lot of information about when researching technical interviews.

Dealing with the anxiety and frustration these situations can provoke is hard, but also a crucial step to improve your performance.

So here are some things that have helped me in this regard.

Prepare Your Body and Mind

Interviews are stressful situations in which you have to deal with expectations and perform to reach those expectations while being judged by other people.

I’ve always felt uncomfortable in these type of situations so I’m quite familiar with the type of anxiety you might feel.

Something that helps me is try to think about it like the moment of a game for a sports player or when actors get out on stage. You normally see these people trying to warm up and focus before they start to perform, right? There’s a reason for that – and it’s that this preparation actually enhances performance and gets you ready to give your best.

It may sound stupid at first, but stretching, warming up your voice, meditating, imagining the moment in your mind and picturing yourself being successful in the moment are all things that will push you towards doing nicely in this important moment.

Be Confident

Easier said than done, right? Absolutely. Confidence for most people isn’t something you can just turn off and on, but something you build along the way and comes with lots of practice, studying, and preparation behind it.

You'll build confidence with the work you do prior to the interview, but once you’re in the moment it’s important to remember that you want to show the interviewers you have confidence in yourself as a coder and that you trust yourself to solve any problem you face.

This doesn’t mean you have to know absolutely everything and be able to solve any complex problem absolutely by yourself. Rather, it means that you won’t panic when you face something you don’t know how to solve at first, and that you have the ability to slowly analyze the problem, break it down, and work towards a solution.

Slow Down

Stress, anxiety, and the wish to show that you can solve the problem can make you rush more than you need to. And rushing can lead to missing key information, flaws in your logic, bugs in your code, and errors in general.

So take your time, actually, take more time than you actually need. Analyze the heck out of the problem, talk slowly, code slowly, think slowly, and remember to breath. Things are easier to deal with when you take your time and slow-mo the process.

Don’t Take it Personally – or Do...

You’ll mess up at some point, that’s a certainty. Especially in your first interviews, you’ll probably fail and feel miserable about it. It’s just the way it is, and it's a step that is needed for you to understand where you need to improve.

A key issue here is how you deal with that frustration. I could tell you to think about it as a process, to not get mad when you fail, to be patient… But if you’re an anxious and self demanding person as I am, you’ll be very frustrated when you fail, and there’s nothing you can do to avoid it.

But how do you deal with that? Do you get depressed and quit coding forever? Do you get scared of interviews and never apply for a job ever again?

Personally, I get very mad at myself when I fail at something or find out I don’t know something I "was supposed" to know. I get mad at myself for not preparing correctly or for missing things, and even though that anger feels bad at first, later on is something that pushes me forward.

I feel so bad about it that I make absolutely sure I won't fail at that again, and I practice as hard as I can to avoid being in that situation again.

Different approaches work for different people, but the thing is to handle your emotions in a way that pushes you forward and not backwards.

Learn from Your Mistakes

As it’s a certainty you’ll mess up, the smart thing to do is to learn from the errors you made and try to not make them again.

Always try to take note of the problems you were presented and your solutions, analyze your mistakes, analyze other possible approaches you could have taken, what optimizations you didn’t see, and what key concepts you didn’t remember at that moment.

Also always ask your interviewers for feedback about what you could have done better. This information is gold if you get the best of it.

Have Fun

If you love coding, you probably have lots of fun doing it. Never forget that, no matter the context.

In interviews, try to approach each problem with curiosity rather than fear of failing. Try to show your interviewers you’re enthusiastic about problems, because you’re probably going to work with similar stuff on a daily basis.

Plus if you’re having fun and thinking in a positive way, you’ll be more relaxed and your mind will be clearer, which of course helps your problem solving skills.

Keep Going

If you pass or if you fail, at the end it doesn’t matter, in the sense that your approach and behavior should stay the same.

Just as code can always be improved, so can you as a programmer. You should always keep learning, keep getting better, keep practicing, keep facing stuff you didn’t know anything about and eventually overcoming it.

So don’t get too high if you pass or too low if you miss – just keep coding and keep learning.

Roundup

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on LinkedIn or Twitter.

See you later!