If you’re a junior, mid-level, or self-taught developer who keeps getting rejected and you don’t fully understand why, I hope this helps.

Here’s what I’ll cover:

1. My 18-Month Job Search Struggle

2. The Interview Problem I Didn’t Expect

3. Discovering Active Recall and Flashcards

4. My Interview Preparation System

5. The Results

6. Changing How I Looked for Jobs

7. Turning My System Into a Small Tool

8. Lessons I learned

9. Final Thoughts

My 18-Month Job Search Struggle

For 18 months, I was trying to land a remote or relocation web developer job.

During that time:

• I applied to more than 1,000 positions

• I went through around 20–30 interviews

• I failed most of them

It was exhausting. I felt like I was putting in a lot of effort but getting almost no results. Over time, I started doubting my skills and wondering whether I would ever find a job I’d actually be satisfied with.

What made this even more confusing was that a few years earlier, in 2021, I had found a remote job at a US company in just three weeks – with almost no experience

Something clearly wasn’t working anymore.

The Interview Problem I Didn’t Expect

After dozens of interviews, I noticed a pattern: I wasn’t failing because I couldn’t solve complex algorithm problems or build features under pressure. I was failing on basic technical questions.

Questions like:

• “What are portals in React?”

• “Can you explain how an HTTP GET request works?”

These were not hard questions. They were things I had learned before. But during interviews, under pressure, I just couldn’t recall. Or simply I skipped it during preparation because there were no systems in place.

That’s when I realized the real issue: I didn’t have a problem understanding concepts. I had a problem recalling them quickly.

My first instinct was to study more. More tutorials, more articles, more videos.

But passive learning didn’t fix the problem. I still froze during interviews. What I actually needed was a way to train my memory, not just consume information.

Discovering Active Recall and Flashcards

That’s when I came across flashcards and the concept of active recall.

Active recall means testing yourself repeatedly on what you’ve learned instead of just rereading material. You try to answer a question from memory first, then check the answer. This approach has been backed by research for more than a century.

I started practicing small, specific concepts this way, like:

• React fundamentals

• JavaScript basics

• HTTP methods

• Browser behavior

I repeated them until recalling the answer felt automatic.

This made a huge difference during interviews.

Flashcards help you cut through the noise and actually learn what matters. It's not just about memorizing facts – it's about really understanding, remembering fast, and building a solid base in every concept you study.

So to help you prepare for your interviews, I’ve taken years of experience and scientific learning methods and turned them into a tool and approach that gives you the right info at the right time.

My Interview Preparation System

Once I found the right learning method, I built a simple system around it.

Step 1: Ask What to Prepare For

Instead of guessing what to study, I started asking recruiters directly:

“What topics should I prepare for the technical interview?”

Surprisingly, many of them replied with a clear list, which helped me focus only on what actually mattered and avoid over-preparing random topics. In my experience, many HR reps are quite helpful to job applicants.

For example, when I applied for a position as a Frontend Web Developer in React, the HR specialist advised me to focus mainly on React and JavaScript. So I prepared for all the popular questions around hoisting (JS), the event loop (JS), how react works under the hood, what props are and how they work, and so on.

Overall, that interview went well – but when I got a question on React Portals, I couldn’t explain it properly. And so I didn’t get the position. But I don’t blame myself for this one, as that’s a very rare topic. 😊

I also applied for another Front End Developer role where the HR specialist advised me to prepare mainly for questions about GSAP, Framer Motion, and React/Next JS. This made sense, as the company mainly builds modern animated websites.

In my interview, the theory round went well, but I failed the take home assignment. I realized then that I didn’t have enough skills in these areas.

At another company, I asked HR about the cultural interview, which was the last round. The rep said: ”No worries, all the hard work is done from your side. Prep for just a human dialog.”

And for the last application I submitted (and after which I actually got the job offer), the HR specialist told me to strongly prepare for CSS – especially Flexbox and Grid. This made sense, as the position was for an HTML markup developer. And so I practiced all the ins and outs for these topics, even the more rare ones.

I use the same approach for each round of interviews.

Step 2: Use Flashcards (With AI Carefully)

I used ChatGPT to generate flashcards for each topic and reviewed them daily.

One important thing I learned: AI can be wrong sometimes. To reduce mistakes, I started adding links to official documentation in my prompts so the answers were grounded in reliable sources.

I kept sessions short and consistent. That consistency mattered more than long study sessions.

AI mistakes was the reason I created 99cards.dev

Here is the prompt I use in ChatGPT:

You are a web development expert with 20 years of experience. Your task is to help me to prepare for the interview.

Prepare 10 flashcards on CSS Flexbox topics. Format one question with four answers. One answer is correct.

You're going to serve all the questions one by one. After I answer, you give me feedback and then give me the next question.

Note that you should tweak your prompts for your needs, and based on what you need to review.

You can experiment with various factors, such as:

• Difficulty: beginner or advanced

• Specificity: from vague (for example: I want to practice with CSS) to highly specific (for example: I want to practice with the flex property in CSS Flexbox)

• Number of questions: sweet spot is between 10 and 20

• Add context: good practice is to add links to official docs, as it decreases the chances of AI hallucination

Here is a typical flashcard created by ChatGPT:

If you provide an answer, you’ll get feedback like this:

The Results

After a few weeks, interviews felt very different.

I was calmer. I answered basic questions without panicking. I could explain concepts clearly and confidently.

In my final interview process, I passed four rounds in a row and scored 95% on the technical test.

Soon after, I received an offer: $5,500 per month and a paid relocation package for my family and me.

For the first time in a long while, my effort finally matched the results.

Changing How I Looked for Jobs

About six weeks before getting the offer, I also changed where I searched for jobs.

Instead of relying only on large job platforms, I started using smaller communities like Telegram job groups.

This helped for two reasons:

1. Less competition: many smaller companies post roles there with fewer applicants

2. Direct communication: I could message recruiters before applying

Before submitting an application, I would ask:

“I saw this position. Here’s my CV and LinkedIn. Am I a good fit?”

If the answer was yes, I applied. If not, I moved on immediately.

This saved me a lot of time and energy.

Turning My System Into a Small Tool

While preparing for interviews, I created thousands of flashcards for myself. Managing them in notes became difficult, so I eventually turned them into a small tool called 99cards.dev.

It’s simply a collection of fact-checked web development flashcards grouped by topic, based on the same approach that helped me stop failing basic interview questions.

Here are some screenshots from the app:

Lessons I Learned

Here are a few takeaways from this experience:

• Failing interviews doesn’t always mean you lack skills

• Passive learning is not enough for interview prep

• Being able to recall basics quickly matters a lot

• Job searching is a skill, not just a numbers game

• Consistency beats cramming every time

Final Thoughts

If you’re struggling with interviews right now, especially as a junior, mid-level, or self-taught developer, don’t assume you’re bad at what you do.

In my case, the problem wasn’t effort or talent. It was preparation and approach.

I also created a free interview checklist based on my experience, covering HR, technical, behavioral, system design, live coding, take-home tasks, algorithms, and cultural fit.

I hope this story saves you some time and stress.

You’re often just one good interview away.
— Ilyas

No matter how experienced of a developer you are, being interviewed for a new job is always stressful. This is certainly true from my own experience.

In my case, I have been working professionally as a Software Developer for two and a half years, and I've had to face developer interviews five times already.

I have seen people focus too much on learning specific algorithmic problems, or training in online platforms specialized in interview challenges. But there is another side to interviews which I think is as important – and people pay less attention to it.

So, if you want to know how I think you should focus your training for interviews, grab a cup of coffee and get comfortable.

It's going to be a bit of a ride ride (but don't worry – Python examples included!).

Here's what we'll cover:

1. Do algorithms and data structures matter for interviews?
2. Focus on a collaborative approach
3. Try doing a mock interview
   – The initial example interview problem
   – The second example interview problem
   – The hardest example interview problem
4. Final words

Let's dive in.

Do Algorithms and Data Structures Matter for Interviews?

The short answer is Yes.

Knowing about Data Structures and Algorithms will often help you get a job. Also, the benefits of having a solid algorithmic background include the capacity to make better decisions when faced with a challenging problem.

In real life, algorithmic problems won't appear like the statements in the academic exercises you might study. Still, the more trained you are the most likely you are to be able to recognize an application of a Balanced Binary Tree or a Shortest Path algorithm in disguise.

With this in mind, I would recommend not training Data Structures and Algorithms solely for the interviews that you want to excel at. The design of algorithms and how to use the right data structures are topics beautiful enough to be studied just for the pleasure of knowing.

The scope of an interview is very limited. Instead, focus on the problem-solving part of the issue. Try to understand how to use an algorithm (or variations of it) for similar tasks. Study all the variants, and learn to recognize them in different situations. This will help you face new tasks with an open mind.

Also, don't memorize solutions. It won't take you anywhere. It is very easy for an experienced developer to ask the right questions that will put you on display if you only train for very specific topics.

Take a problem and try to solve it using different methods. Try to solve harder problems every time. Get out of your comfort zone.

It will pay off.

Focus on a Collaborative Approach

Most people train for their interviews on websites like Leetcode. There is no problem with that. These websites are good for training your problem-solving skills.

I have been participating in Competitive Programming contests for the last eight years at least, and I have always benefited from these online resources.

But there is one thing that's hard to understand for most software engineers wanting to perform well in an interview. They don't train for the most important aspect of software development: Collaboration.

Usually, when you are faced with a problem in an online platform, it comes with some constraints on the maximum values for some input. It also might have some time and memory limits that require you to adjust your solutions to be more or less efficient. But this is not how it will be in real life.

It is not obvious how to map these constraints to real-life scenarios. They usually come in the form of very specific requests from a client, or very specific characteristics of the team.

In a real project, the team will collaborate to determine what these constraints will be. You have to analyze your use cases, the time you have for the task, who is the final user, how many people will be working on it, and so on...

After a series of discussions, you will reach a consensus and finally start implementing a solution that suits your needs. And this solution doesn't even have to be the more efficient in some cases, but the fastest to implement, for example.

This is what interviewers want to see from candidates during the interviews as well.

You don't jump straight to implementing the best solution you know for the problem you are facing. Instead, you should use your interviewers as a valuable resource, treat them as if they were your teammates (in the end, you want them to be). Ask questions about how the team prefers the solution for the problem to be implemented.

This will lead to a very fruitful discussion where you can showcase your coding abilities and your collaborative skills. You could start proposing simple solutions and walk your interviewers through the process of how the solution can be improved using the best Aces up your sleeve.

As a final note on online training, I would recommend doing individual and team training. Use websites such as Codeforces or AtCoder, which have a huge set of interesting (and challenging) problems, and try to compete against yourself every day.

Don't focus on your rating. I have done that before, and it only holds you back.

Try Doing a Mock Interview

If you reached this point in the article, I would like to propose a little exercise. Let's have a mock interview where I will act as the interviewer. I will tell you how I think the candidate (you) should answer every question and perform each task.

Of course, we will focus only on the programming challenge part. Other aspects of interviews, such as talking about previous experiences, are also important, but we will try to cover that in another article.

So, if you feel ready enough, let's go!

The Initial Example Interview Problem

Let's start with the task that you will be solving. Keep in mind that if you and I are ever in this situation, I won't be using this same example, but of course, I will be using the same methodology 😉.

The statement of the problem is the following:

"Given an integer number X, find out if it is a prime number."

You might be tempted to go for the best solution you know to solve this problem. I think that this approach, as I explained before, isn't always correct.

Instead, what I would like to know are the different approaches to solving this problem. Also, I would like you to ask about the requirements for this task. Something like:

• Should we aim for performance or to solve it faster?
• Should we make a solution that is easy to understand for other developers?

Usually, some aspects to consider when creating the first solution for a problem are:

• Easy vs Hard: Should we make an easy-to-implement solution even if it is not perfect, or should we go for a more robust solution that will be difficult to implement?
• Naïve vs Efficient: Should we deliver a working, naïve solution first and then a more efficient one, or should we go straight to efficient?

Evaluate what your team wants to optimize for. Reach a consensus, and implement the agreed solution.

In my case, I would be glad if you proposed the easiest, fastest-to-implement, correct solution that you can think of and then guide me through the process of how to improve that solution.

An example of a very good initial solution to this problem is something like the following:

# naive.py

def is_prime(x: int) -> bool:
    if x in [0, 1]:
        return False
    for i in range(2, x):
        if x % i == 0:
            return False
    return True

As you can see, this function is correct. Since a prime number is an integer only divisible by the number 1 and itself, it makes sense to iterate from 2 to x - 1 looking for a divisor of x. If we find one, we can immediately return False. Otherwise, we return True. As edge cases, the numbers 0 and 1 are not prime by definition.

This is a good starting point!

Now, before diving into optimizing this method, you can discuss the style of the code. Is it Pythonic enough? Do we care about it? Is it readable?

All these questions might not seem important at first but, since we work as a team, they do matter. Having a coding style is important because it makes it easier for every team member to understand each other's code, and it will speed up reviews and refactoring. Also, the code is more often read than written, so readability counts!

You might be tempted to show off your Python skills and rewrite the previous function as follows:

# pythonic_naive.py

def is_prime(x: int) -> bool:
    return False if x in {0, 1} else all(x % i != 0 for i in range(2, x))

I think this is a good, pythonic way to write this function. But, since the team is the most important thing here, this change should be discussed.

It might be the case that some team members are not so skilled in Python. Maybe, in this case, we should optimize for readability instead and keep the function as we first wrote it.

A more interesting addition, before getting into performance, would be adding docstrings to the function. As I said before, this code is most likely to be read by your team members in the future. It is important, then, to make it easier for them (and your future self) to understand what this function is doing.

Maybe changing the function to something like the following will add more value:

# naive.py

def is_prime(x: int) -> bool:
    """This function takes an integer `x` as
    argument and checks whether is prime or not.

    Args:
        x (int): The integer number to test for primality.

    Returns:
        bool: True if the number `x` is prime, False otherwise.
    """
    if x in [0, 1]:
        return False
    for i in range(2, x):
        if x % i == 0:
            return False
    return True

First Optimization

Until this point, we have an initial solution that works. We have discussed important topics such as code styling, readability, and documentation for developers. These are all important things to consider when working as a team.

But we still haven't talked about the performance of the solution! So, it's probably time for that.

At this moment, you should probably bring up that this function can be implemented so it runs much faster. And now is when you showcase all that algorithmic knowledge inside you.

The previous solution has a time complexity of O(x), where x is the input integer the function takes as an argument. This can be optimized to O(sqrt(x)) with the following code:

# sqrt.py

import math

def is_prime(x: int) -> bool:
    if x in [0, 1]:
        return False
    for i in range(2, int(math.sqrt(x)) + 1):
        if x % i == 0:
            return False
    return True

Or even like this, without importing the math library:

# sqrt.py

def is_prime(x: int) -> bool:
    if x in [0, 1]:
        return False
    i = 2
    while i**2 <= x:
        if x % i == 0:
            return False
        i += 1
    return True

I would be ok with either alternative.

I omitted the docstrings in the previous implementation for the sake of making the actual code changes clearer. But, it would be great to include the time complexity of the function in the documentation for developers. The more information you can give about your code, the better it will be for your team members and yourself.

You are doing great so far. Let's continue!

The Second Example Interview Problem

So far, I have been able to evaluate that you have the necessary collaborative skills to take on easy tasks with the team. Now it's time to complicate things a little.

This is the statement of the second problem I would propose:

"Given two integer numbers L and R, count how many prime integers are in the interval [L, R]."

Once again, I would recommend discussing what priorities the team has set regarding this task. Start simple and walk through the process of improving an initial solution. Emphasize that premature optimization is not a good practice.

Also, discuss the possibility of using the solution that you implemented for the previous task to solve this one. It makes sense that if we have a function that tells whether an integer is a prime number or not we can use it for every number in a range.

And this is something that you will have to do in real life. Usually, when a new task shows up, the team should look into the maintained projects to see what can be reused to speed up the implementation process. If you don't do this, you might end up coding duplicated functionalities.

That being said, a good initial solution for this task could be something like this:

# range_primes.py

from sqrt import is_prime

def count_primes(l: int, r: int) -> int:
    primes = 0
    for i in range(l, r + 1):
        if is_prime(i):
            primes += 1
    return primes

This is perfectly fine, and you have shown that you can reuse previous functionality to build new ones. As in the first example, you might be tempted to show off your Python skills and write this function like this:

# range_primes.py

from sqrt import is_prime

def count_primes(l: int, r: int) -> int:
    return sum(bool(is_prime(i)) for i in range(l, r + 1))

I recommend not going for this Pythonic implementation as your first option. Leave it for discussion, evaluate the readability of the code, and maybe analyze the differences in performance. Don't forget the docstrings!

The next section is when things get interesting. Keep reading. We are on the final step...

The Hardest Example Interview Problem

Remember when I said previously that the constraints present in competitive programming websites are hard to map to real-life requirements?

Here is how I would present a difficult challenge for you to determine those constraints and implement the best solution that you can:

"Suppose a client wants us to provide the functionality of calculating prime numbers in a range as a service. They want the focus to be on performance because they plan to use this service very often. How would you implement it?"

If you have been practicing your algorithmic skills for interviews, you have probably solved problems similar to this one a few times. The main difference here is the change in context.

Instead of giving you precise instructions, numeric constraints, and input or output formats, I gave you a broader description of the task. And my goal here is the same as before: get you to interact with me as if we were teammates figuring out how to solve this problem from the little information we know.

Hopefully, after exchanging a few questions and answers, we can translate the previous, more ambiguous statement into something much more familiar:

"Given a set of queries of the form [L, R], answer, for each query, how many integer numbers inside that range are prime."

And this makes sense because the client wanted to use this service very often, as stated in the description.

We want to focus on performance. That should be our main concern when implementing the solution. But still, the best way to get to an optimal solution is to start with a simple one, analyze if we meet our performance requirements, and keep improving gradually. Let's see the entire example.

We could start by using the solution we implemented in the previous step. Is it good enough?

Let's assume that the maximum range of numbers we will have as an argument to our function is [1, 10^6]. Also, realistically, let's assume that the number of queries our service will answer per minute is around 10^5.

Our previous solution has a time complexity of O(sqrt(n)) to determine if a number is a prime. If we were to do that for every number in the range, the complexity goes up to O(n * sqrt(n)). On top of that, if we do that for every query, we will end up with an even higher time complexity of O(q * n * sqrt(n)).

Substitute the previous variables with the highest possible values they can have, and you will get that this solution will take around 10^14 operations to answer all the queries. Assuming that a computer can perform around 10^8 elementary operations per second, it will take approximately 10^6 seconds to complete all of them.

Note: Convert 10^6 seconds to days. You will be amazed 🤯.

This solution is unfeasible if the goal is to prioritize the performance of our solution. Let's see how we can improve it.

At this point, what I would expect is for you to take out the best of the training that you've had on all those online platforms, and show me an impressive solution. This is the time to showcase all your analytical and algorithmic skills.

But only now, because I know that you are a team player.

The Final Solution

Since this is a mock interview, I am very interested in knowing your approach to solving this last problem efficiently. Let me know how you would implement the solution or share your code on GitHub – don't be shy.

I guarantee you one thing: if you can make it to this point in real interviews, probably it won't matter too much if you don't know the optimal solution to this problem. It doesn't mean that you shouldn't try your best to solve it, but rest assured that you have done a very good job already.

That's it! Now I want to see your code.

Final Words

In this article, I tried to summarize some of the aspects I consider to be the most important in coding interviews. I placed special emphasis on the collaborative part because I think most people underestimate how important this skill is. It is a must, especially if you want to work on a team with other developers.

I tried to guide you through a mock interview where I explained the thought process I would follow when faced with a standard coding task in an interview. I hope this exercise was useful and that it can help you in your next interview (as a candidate or as an interviewer).

Share your thoughts on this mock interview, and let's start a fruitful discussion.

See you soon! 👋

Sources

• Code examples used in the article can be found here.
• Hint for the last problem: implementation of the Sieve of Eratosthenes algorithm.

👋 Hello, I'm Alberto, Software Developer at doWhile, Competitive Programmer, Teacher, and Fitness Enthusiast.

🧡 If you liked this article, consider sharing it.

🔗 All links | Twitter | LinkedIn

• How I taught myself new skills

• How did I know that learning to code at 37 was not “too late”

• How I prepared for big tech coding interviews

• How I analyzed and minimized the risk of career change

• How I worked out that software engineering was “right” for me

• What languages I focused on

• Whether being a FANG/FAMGA software engineer is right for everybody (hint: tempting to think so but I saw plenty of evidence of it not being right for some people’s goals)

Note: I think “FAANG/FAMGA” is limiting, and prefer to refer to “big tech”since there are many highly prestigious companies other than the usual 4-5 everyone obsesses about.

Why I Wrote This Article

Each of those questions I listed above deserve their own article, even though I know our contemporary culture prefers “tweet-sized tips”. However, meaningful skills can’t be internalized from a few hundred characters.

So today I am going to share with you my answer to one of those questions – the approach I adopted when:

1. I made that first jump in careers from lawyer to coder at 38, and

2. How I prepared for big tech interviews at the ripe ol’ age of 39, with less than 2 years of coding behind me.

If you want me to write on any of the other questions I always get, please let me know! I’m going to put my contact details in this post somewhere, and the only way to find it will be to go through the article. 😊 That is also to encourage you to carefully read this article rather than skimming for a “quick tip”.

Uncovering the Real Goal

I hold the following opinions: getting coding interviews is harder than learning to code. Doing well at the interviews is often just as hard as getting the interviews. Behavioral interviews are hard if you don’t have solid experience – but your competition does.

When I made the switch I had zero coding background. Later, when I set my sights on Big Tech, I knew I’d be competing with PhDs, people who’d been coding since their teens (often 20+ years), and folks who'd achieved a lot more technically than I had in my one brief year’s experience as a developer.

And I had the added challenge of applying for big tech from outside the United States.

So I had to develop a plan that went well beyond just “learning to code”.

First, let me explain why I concluded that “learning to code” is the easy part, even though I’d tried and failed to learn to code 4 times, between 2012 and 2018.

This insight came to me in late 2018, when my startup was struggling. I had lost tens of thousands of dollars building my startup. I had no income for over 2 years.

And I decided to pull out over $40K from my mortgage. Why? I got into a top-rated bootcamp in San Francisco.

I left my family behind, and relocated to the US. I was meant to be there for over 14 weeks, but I withdrew from this top-rated bootcamp in week 1, and returned to Australia.

I had been super excited about the adventure (and scared from all the debt). But I developed grave doubts about the bootcamp strategy. I noticed that my instructors and the program were designed to help people "learn to code" rather than "becoming a coder".

From my experience on the hiring side in 3 other industries and 4 countries, I knew this was a mistake.

Learning to code is just a form of “literacy”. And literacy is not skill.

I was living proof: each of the 4 times I focused on “learning to code” I succeeded in a narrow sense. Whether it was HTML or Java or writing a simple Android app from a book, I always succeeded at learning how to read and write the basics. But I had no idea how to actually build anything useful. I was completely hopeless at applying my knowledge – I had no real “skill”.

In this century we don't get hired for what we know. We get hired for skill.

I quickly saw several reasons why a coding bootcamp was the wrong strategy for me.

This expensive bootcamp would likely give me some basic skills, the kind that may even get me an “entry level” job. But I could see things were going to be rushed, standardized, and focused on "getting out the other end".

I didn't want to "tick a box". I wanted skill. Competence. Confidence.

Moreover, bootcamps seemed to prepare everyone for entry level "junior developer" jobs.

I was 37 and I didn’t want to settle for an “entry-level job” mindset. Plus I don't believe anyone with 3 + years of experience is "junior" even if they're a total newbie in the field.

Then I discovered that several instructors and teaching assistants at the bootcamp were former students who hadn’t yet found jobs. They had never changed careers – many had never had a "career" as such. The job-search counselors had never even been on the interviewing side in tech.

How was I going to learn to do something from people who’d never done what I needed to do?

And then there was geography. Students based in San Francisco had advantages, whereas people coming from other parts of the US did not find work that easily and ran out of money in the long months after graduating and before getting their first job. Heck, I was based in Australia...how was this going to work for me?

I looked at my explicit goal. It was not to "learn to code" – it was to build a career that fulfilled me.

Plus, when researching bootcamps, I could see a path to learning “part time”. That seemed like a much more sustainable strategy to me because I could find a job and learn at night and on weekends. After over 2 years of no income, I needed to have cashflow in order to keep fear at bay, and focus on becoming a professional coder.

As the legendary businessman Harvey Firestone said:

“Having a surplus is the greatest aid to business judgment that I know.”

Having income while studying would give me the confidence to make better judgments. Better judgments are important for a career that is fulfilling in the long term.

I had no doubt that I would "learn to code" if I did 3-4 months in the bootcamp.

But would I learn enough for a good team to pay me money for my skills? I no longer believed bootcamps and online coding websites would help me achieve that.

Learning to code would not get me far. I had to be good enough to beat my competitors who had coding degrees, prior experience and networks. I wanted a career in code.

So I left the bootcamp, wrote off about $9,000 and returned to Australia. Sure, I had gained rudimentary coding literacy to pass the entrance test for the bootcamp. But I was very far from competent.

This analysis may be hard to understand if you’re new to the workplace. Another way to truly understand it is to notice that many of us play music, but aren’t in a band. As my mentor said:

"Michael Jordan didn’t want to learn to play basketball. He wanted to be in the NBA. Huge difference."

How to Use Your Advantages & Disadvantages

That one insight made all the difference. Within 8 months, in 2019, I got all 4 developer jobs I applied for. I simply followed the program I’d developed with the help of my (non-technical!) coach.

Don't be misled though. I had unexpected advantages. I benefited from 2 major advantages that initially appeared to be disadvantages.

This was not my first career change, and for almost a decade, I had been on the hiring side in previous careers. Today I’ve been on the hiring side in engineering too, and the patterns are very similar.

My biggest advantage was that I was no longer thinking about the job market challenge as a candidate. I was thinking about this from the perspective of the hiring manager. That had a significant impact on my plan because I had experience of how hiring managers think – their constraints, priorities, values, business needs, dislikes, red flags...

My experience (age?) helped me understand what impact I could deliver to a team and organization, and to identify the right people that I could learn from, who could help me with ideas, guidance, suggestions and referrals. What was a disadvantage was now an advantage – a career changer's advantage.

On the point of advantages, I want to call out something important.

The easiest thing in the world is to dismiss others for having “killer” advantages. It's easy to shrug and say "Of course – that’s why they succeeded". It’s easy to not notice that everyone has very compelling and serious disadvantages.

For me, my “disadvantages” were:

• Geography – I don’t live in the US or one of the other tech hubs

• No formal computer science qualifications

• Zero technical background

• A mortgage and financial responsibilities

• My “age” – learning new skills when you’re pushing 40 is harder than when you’re 25

• Cultural and social expectations, judgment, negativity

• Recruiters and bosses being younger than I was and uncertain of how to deal with me

• Compared to other candidates, people viewed my change as very, very “risky”

• I was going to earn less in engineering than I would as a lawyer

Every day I hear from people who let any one of these things stop them. While I cannot comment on whether or not they’re real reasons, I can say that if we argue for our limitations, we get to keep them.

Clinging on to our disadvantages does not help us overcome them.

With the help of my coach and a ton of mindset/psychology training, I was able to dig into my disadvantages and convert a few of them (not many!) into major advantages. And that’s when I realized that my experience with how interviewing, recruitment, and resourcing works would help me a lot in formulating a strategy.

Priority one: career change

When learning to code and intentionally setting the goal of becoming a professional coder, I found that I kept switching to short-term thinking and obsessing about my first role.

I wanted my first role to be glorious, to prove all my critics wrong, to pay me a gazillion dollars and save me from having to deal with self doubt and struggle for the rest of my life.

But I had to train myself to view things differently. My first role must be one that makes me learn and grow, and set me up for future success no matter what happened. It needed to pay fair market rates, but I was happy to take a slightly lower salary if the team was fantastic and the growth/learning was solid. It did not need to be my dream job.

I was very explicit in the tradeoffs I’d make:

• Team matters more than brand

• Team matters more than money

• Brand matters more than money (as it would set me up for future opportunities)

• Money matters more than stock (this was for my first dev role, as this would make my continued learning plan sustainable, even though stock may give me more financial upside)

• But, learning mattered more than brand or money – as learning more would save me time which is better than saving me money

• I would not trade off between team and learning. I needed both (but I was more likely to get reliable signals on the team than I would on the actual learning/growth I’d get on the job)

“Nailing it” or being comfortable was not a priority. My priority was to successfully change careers.

Accepting a rubbish coding job (and there are plenty of them…) would not be a “successful” career change for me. But equally I didn’t have to get into big tech (ever) for my career change to be “successful”. This was very personal – success to me meant loving the work I do and learning a lot doing it. Period.

How I Made a Customized Plan

After analyzing my advantages and "convertible" disadvantages, the next thing I needed to develop was a customized plan. I needed one that was tailored to me, that I could believe in.

I needed a plan that took into account my specific context, which includes my temperament, experience, beliefs, values, goals and skills.

Note that I’ve still not talked about the technical interviews, the algorithms and data structures, and so on. When developing my plan, I had to focus on all the many pieces that had nothing to do with my coding skills or technical capability.

It would also need to account for my psychological “runway” – how much time was I prepared to invest in this career change, before I’d give up, lose hope, or change my mind? I could not answer that without understanding how long it was going to take me to learn the minimum required skills.

To understand that, I needed to research and analyze what the minimum set of engineering skills that the market would value were.

And to understand that, I needed to analyze the dozens of engineering domains in the market, and which ones would suit my temperament, interest/passion and advantages. And from that analysis I’d need to pick the domains that I would focus on and exclude all others.

I'd have to find the overlap between my interests, my ability and what the market valued.

Again, my experience on the hiring side of the market gave me some (small but important) advantages. I knew that pure technical skill would not be enough – that’s just the starting point. the “invitation to the dance”.

I also knew that good teams don’t just hire for raw technical skill, they hire for essential non-technical attributes as well. What those traits are depend on the technical domain, the team culture, the current composition of the team, and so on.

Yes, you're right. A custom plan is extremely multi-dimensional, and getting things right is only moderately helpful, whereas getting things wrong can result in a giant loss of direction and waste of time.

Since I was almost halfway through my career, I was determined not to repeat past mistakes. I was going to be:

• Highly specific in my goals.

• Highly intentional in my choices and actions.

• Focused on what I wanted, paying no attention to the things I did not want.

• Willing to change myself, my habits and negative beliefs, so that I could change the world around me.

• Ready to focus on building a rewarding and fulfilling career rather than just “getting the next job”.

• Ready to focus on delivering value for my future team rather than a “what’s in it for me” mindset.

• Willing to play the long game – think in 5-10-25 year horizons rather than the next few weeks.

I must confess, doing these things consistently was much harder than I anticipated. I slipped up a lot, especially on the first three. But since I had my custom plan written down, I let that be my guide and the sole source of truth for what I needed to do.

My plan required me to focus on fundamental programming skills, and then narrow it down to the segment that I felt matched my long-term goals and skills. For me, this was web development. This meant completely and ruthlessly avoiding all the “shiny new things” and doing things like Python or Java.

And tutorials and endless videos were not going to make me beat the competition. I calculated that the minimum set of skills I’d need to develop for my city would require 900-1100 hours of focused coding, practicing the right things in the right sequence.

Preparing the plan took several weeks. I kept refining and strengthening it and didn’t rush it artificially. I am very inspired by Abraham Lincoln (another lawyer who changed careers!) and he once said “Give me six hours to chop down a tree and I will spend the first four sharpening the axe”.

I was so tempted to dive right into my plan and get “busy” but I’d learned that being busy was so not the same as being effective. Once the plan felt as complete as it could be with the information I had at my disposal, I turned to executing on that plan, with total focus.

This meant a lot of sacrifice, and many, many days of self doubt, battling the temptation to switch, and learning to manage my energy. I developed some amazing habits during this time, but they were only obvious to me in hindsight. During those 6 months of work, I was constantly assailed by uncertainty, fear and occasional loss of hope.

Later on, I adapted this planning process to create a plan for Big Tech and especially for Google. That plan took another 500-600 hours of intentional study that was completely different from my plan to become a developer. More on that later.

Early Results, and then…Google SWE

Another lesson I’d learned from 4 years of trial, error, and failure was that I was very likely to change plans midway, switch resources, courses or focus.

This is a much more serious problem than we realize because every time we switch focus or plans we throw out the hard work we’ve done, go back to square 1 and…start…all…over…again.

Imagine if you were driving from A to B and kept taking U-turns and going back and restarting. You’d never get anywhere.

But I’d made myself a promise (it’s easier to keep a single promise than to keep a bunch of them!): I was going to complete my plan and then decide whether I would keep going. This time I wasn’t going to stop until I completed my plan.

I didn’t have to like doing it. I just had to like the possibilities that lay at the end of doing it.

My plan had a specific time when I would start interviewing even if I didn’t feel ready for interviews. But to get to that stage I had to get good at generating interview opportunities.

Again, my past experience in other careers helped me. I applied all my learnings over 18 years and secured 4 interviews within a few weeks, and got all 4 offers even though there were plenty of candidates with more experience, skill, and qualifications than I had.

It wasn’t because I was better at coding. I don’t see how that could be, given that I’d only been in the game for a few months.

I believe I got all 4 offers because during the interview process I demonstrated that I was a better candidate for the hiring manager. This approach was critical in how I presented myself.

Getting the offers is great, but I had an unexpected problem. Since my plan required me to be highly intentional about the kind of work I’d pursue, all 4 roles I’d applied for were the ones I really believed would be a fantastic start to my new career. How was I going to choose?

Yes it’s a great problem to have, but that doesn’t make the decision easy!

To resolve this problem intelligently, I learned to ask myself a very important question:

Do I know this or do I simply think this?

Very often we make decisions based on assumptions and beliefs that are completely untested, and we mistake our opinions or fantasies for reality. What we actually know is way less than what we believe without truly knowing.

Being intentional required me to focus on what I know rather than what I wished, or merely thought. I had to either find evidence to back my thoughts, or disregard thoughts for what I knew.

That framework developed my analytical powers and helped me choose the right first role in early 2019. I turned 39 around that time.

Till today I continue to use this know vs think framework in my personal decision making as well as in my engineering decision making. I find it to be an excellent framework for analyzing tradeoffs in complex decisions.

Looking back, I learned a TON about sticking to my plan, revisiting my goals, self-awareness and practicing being intentional.

A few months into my new role, I noticed that a lot of lawyers were starting to reach out and ask me how I did this. Curiously, many of them were people who insisted I was making a huge mistake and that wanting to learn to code at this stage was immature and foolhardy.

Now they wanted to “learn to code”. And that made me think.

What else have others said is “not possible”? Do they know that or do they just think that?

And my goals hadn’t changed. For me learning, growth, and team were still more important than brand or money. But I was almost 40 and I also wanted to explore life in a way that I’d never had the courage to do in the first half of my career.

So I decided to set myself a stretch goal: I was going to find out what being a software engineer at Big Tech was like. I’d worked in huge companies before and I knew that it isn’t for everyone – that’s the reason I went into startup and smaller companies in the first place.

But wouldn’t I learn and grow SO much by being surrounded by some of the “best” people in their field, from engineering to product and sales? Did I know this? Or did I just think it?

I did the research and found that on average people were happy in Big Tech. But I also found that most people were not as intentional as I was. So I confined my research to people who were very intentional about their careers. And they (almost universally) said they grew a lot from Big Tech, even if they decided to leave. Leaving Big Tech was also intentional, in pursuit of their end goals.

So I decided to try for big tech (including 3 of the FAMGA companies) and several others, in Silicon Valley, New York, and Seattle. I was still based in Australia, so this was a massive challenge.

I re-designed my plan. Several of the steps were the same but the coding curriculum would have to be massively overhauled. I also needed to find out how US big tech recruitment is done, and be worthy of a referral.

About 7 months later, I started generating interviews. I worked very hard to prove myself worthy of referrals for those 7 months, and people offered to give me referrals based on my efforts and proven commitment.

I got referred to Meta (it was called Facebook then) but I didn't get the interview as my skills were not the right match. This was a massive learning for me as I thought I’d been careful to only apply for roles where my skills matched – and I was wrong.

That was when I realized that sometimes the position description is written in ways that mean one thing for the hiring company but means very different things outside that company. This is because different organizations use the same words to mean different things. Both the hiring side and the candidate side can be unaware of this!

All these learnings added up. Within 3 months I got offers from 2 big tech companies, and missed out on a third at the final interview because I just didn’t know how to write a filesystem from scratch (I didn’t understand much about the Linux world at all!).

And then I got an offer from Google.

Again, I was faced with a very difficult decision. Google is a cultural force that is very hard to be objective about. But I really wanted to stay true to my goals, my plan, and my intentions.

Trying to separate what I knew from what I thought was EXTREMELY hard when it came to Google. But I was absolutely sure about one thing: the team I’d interviewed with were amazing people.

And this is where I believe luck matters. No matter what people say about skills, brains, smarts and all that stuff, luck and "magic" have a role in life.

My interviewers from Google were friendly, kind, cheerful and highly focused engineers. They were not looking to prove I sucked. They wanted to help me prove I was good. They answered my questions with enthusiasm, and I felt like collaborators from the first minute.

Is this a Google thing? Maybe. But later, when training to be a technical interviewer at Google, I witnessed a very wide variety of interviewer/hiring manager styles and beliefs. I saw candidates with great skill losing their nerve, struggle to communicate their process, and so on. And I came to appreciate the role of chance in all this.

So yes – I was lucky that I had the kind of interviewers I did, and that on interview day I happened to know how to work through the code.

This is also where my ultra-focused preparation on type of work and relevant skills paid off. There are a very large number of engineering roles at Big Tech that I would never have been suited to (like the one at Meta). Even with my prior experience in other careers, I had no idea how HUGE the engineering world is, and how many flavors and types there are, and how hard it is to tell them apart.

By forcing myself to be highly intentional and not randomly and blindly applying for big tech engineering roles, I improved my chances in small but important ways. I dug deep into each role and researched them carefully by speaking to friends in the industry (again – my age and experience was an asset because I had built relationships over 15+ years never expecting that they’d be so useful later on!).

For each offer I got, I had researched the role deeply, and prepared for the technical interviews well. On interview day the stars were aligned, and things worked out. Though I don’t think I “nailed” my interviews, I did well enough to communicate that I was a suitable candidate for the team’s needs.

Which leads me to the question: How did I prepare for the Big Tech interviews?

How to Prepare for Big Tech Interviews

Answer: In two phases that took me over 500 hours to execute.

Phase 1: Learn the Realities and Competitive Landscape

If I wanted to tackle Big Tech, from another country, with less than a year of industry experience, and 15+ years in an unrelated career, with no Computer Science degree, I needed to have a very clear view of the realities, especially the competitive landscape.

This means there was room for informed hope, but no room for dreamy-eyed, pie-in-the-sky magical and wishful thinking.

Hard truths (see my initial YouTube Videos on this here). Hard realities. Hard work.

I had to fully internalize and appreciate the following:

• Coding is just the starting point. Not the ending point. Learning to code was the first step of many, one small piece of a much larger puzzle. In other words, it is necessary, but not sufficient to get a coding job (and especially at big tech).

• My biggest enemy would be my own mind. It would either let the negativity of others get me down, or it would turn against me and undermine my own confidence. I had to build the habits that would help me have a resilient mindset. I focused on recovering from setbacks rather than avoiding them.

• My competitors would likely not be career changers. Or if they were, they’d be from closely related fields like computer engineering, mechanical engineering, or electronics engineering. The vast majority would have technical qualifications, maybe even PhDs (this turned out to be true!), and several years of industry experience.

• As an outlier and a “wildcard”, the hardest part would be getting the interviews. Learning algorithms and data structures would be easier. And “cracking the coding interview” (whatever that means…) would be easier too. Why? Code is deterministic – identical code generally produces identical results. But life is not deterministic, and getting interviews is highly subjective. In the job market, identical actions do not produce identical results.

• I needed to shape myself into the kind of person seasoned engineers would want to work with

• I assumed most of my competitors would have at least 3 -5 years of experience. I couldn't catch up with them, let alone overtake them. Instead, I needed to outperform them on non-technical skills and compare favorably (if not outperform them) on the technical stuff.

• I had to communicate better than the others. If I didn’t know something, I’d need to say so and then communicate how I’d solve it if given the right time and opportunity. I also had to communicate to show interviewers that I understood their business needs and wasn’t just focusing on my selfish dreams.

• Which means I had to really work on understanding what the hiring team valued, was looking for, wanted, and needed.

• I could not control my competitors (their skill, their performance, how much they knew, and so on), or what my interviewer was thinking, wanting, what they valued, or whether they liked career changers or not. I could not control most things. I could only optimize my effort, my focus, my psychology, and how much learning I extract out of each experience, good or bad. I could only control my choices and actions. So focusing on anything outside that would be a waste of precious energy.

• I had to accept the role of luck. Jordan, Tendulkar, Federer – they’ve all had bad days. I would too. Or maybe I'd do great, but on the day someone else would do better. Or someone else would just be a better fit for what the team needed. No harm, no foul. I’ve made those hard decisions on the interviewing side countless times myself, so I know how these things work.

• If I was successful at more than 1 offer I would need to pre-think and pre-agree with myself about what signals and factors I would use to decide (I’d learned from my experience of choosing between my first 4 offers!).
  If you’re wondering how I knew how to do all this…I didn’t. Not all at once. What you’re reading is a summary in hindsight. But I had to work most of this out in “real time” based on “first principles thinking”. And I worked with my mentor to tighten them up as I went along. It took a lot of time and I was so impatient to “start coding”. But …I knew what advice Abraham Lincoln would give me…

Phase 2: How I Chose My Learning Resources

I know everyone thinks there is a secret “magic bullet” out there. Some blog, video, resource, tutorial, podcast, PDF cheatsheet…_something…_that will unlock the entire “secret” and make us instantly learn things.

Nope.

I’ll bang on about this till the day I die – information is a commodity.

Learning is hard, but it’s made much harder because there is too much free information.

We all fall into the trap of thinking there is some missing piece of information. There isn’t.

Why? Because no matter where you live, what language you speak, what color your eyes, skin, or hair are, what gender you identify with – all resources are going to teach you things that “work”. They’re all “the same” at a very fundamental level.

They have to be, because that’s how computers work.

If you and I write an identical function in JavaScript or Python or Java, we are going to get identical results. That’s how computers work – they’re deterministic algorithms.

But life (and interviewing) is most decidedly not deterministic. Identical effort, grades, skill, intelligence will not produce identical results.

Again, I had to teach myself to learn. I had to teach myself to shift my attention away from resources/blogs/websites/courses and put my attention on building solid mental models, identifying relevant skills, drilling down on concepts rather than code implementations, applying what I already knew in new ways, reasoning, problem solving, and communicating my reasoning while I reasoned.

Now you’re going to be surprised by the resources I used for my Google and other Big Tech interviews.

Yes, I used Leetcode, Algoexpert, InterviewCake and Jenny’s CS Lectures and perhaps a few others. But I didn’t complete a single one of them.

This wasn’t because I switched or lost focus. I was being intentional. I realized that they all teach the same thing, but with slightly different styles and content. So I used these resources to learn concepts and mixed and matched all these resources based on my analyses of interview patterns.

My reasoning was simple. Having been on the hiring side, I know that every year the quality of candidates (at good companies) improves. I personally think that focusing on the company is a huge mistake – we should focus on the team, people and kind of work.

But the world works a certain way, and because of that, everyone rushes to the big companies. This increases competition which makes it harder for hiring managers to assess candidates.

The only way for hiring managers to deal with this is to raise the bar, making it harder for candidates. The overall number of candidates keeps increasing, but the “pool” of candidates that get invited to the interview stays within a narrow range – usually 2 -10 people. Regardless of how many hundreds apply that’s about the number that will even get a chance to interview.

Therefore, the number of candidates that don’t hear back or meet with rejection increases, especially in bull markets.

If the competition is increasing and the resources on the internet are also increasing, but the shortlisted number stays more or less constant, then “learning more” cannot be the solution. Everyone is “learning more”, so relative to the competition there is no change.

I also realized that Big Tech would have lists of interview questions (this is “efficient” as interviewing is very time consuming, and so it makes sense to save time by having a question bank that interviewers could use). Naturally, they would not use these questions if they were “leaked” – that would defeat the interview process.

So, logically, hiring managers will not ask questions that are available on Leetcode or Algoexpert or other sites. This produces a kind of “arms race” – the more questions are made publicly available, the more questions in the question bank are changed. That results in more innovation and variance in questions and hiring strategies.

This left me only one choice. I had to learn to solve problems using mental models and by classifying them. Chances are I was never going to be asked to sort a Linked List or to implement Dijkstra’s shortest path algorithm. Instead, I would need to know how to apply these sorts of algorithms to “real world”, practical problems.

Often real world problems don’t look, sound, or smell like the practice questions we study. Practice questions and competitive coding questions tend to be “neatly” packaged up with clear constraints.

But as an interviewer, I wanted to know how the candidate thinks, reasons, analyses, interprets information, and collaborates. Solving the problem is a bonus. Often they have the right solution but run out of time – but ask great questions and clearly know how to tackle the problem. These candidates can still get the offer.

Later, as an engineer at Google, I could always tell if someone knew how to solve something even if they were unable to solve it in time. Equally, it’s immediately obvious when a candidate does not know how to solve something (and that's OK – we are all learning).

By adopting my approach of understanding problem types and solutions rather than specific code implementation, I could focus on learning to reason rather than learning to write specific algorithms.

This approach meant that I completed less than 40% of Algoexpert (and back then it had half the questions it has now). I also did maybe 50-60 questions from Leetcode and most of them weren’t the “hard” ones.

I figured that “hard” questions would probably show up in 45 minute interviews about 20% of the time which means 80% of the time they’d be easy or medium questions. So it made sense to optimize for the 80% given I was still relatively new to engineering and the hard problems would get in the way of understanding easy and medium ones.

I used these resources to recognise patterns rather than just “complete” and get a certification. That’s why I didn’t complete any of them. And no, I didn’t use “Cracking the coding interview” either.

Along the way I also started a systematic process of understanding system design questions. I documented system design preparation in a long form blog on the essential concepts for system design interview questions.

I also decided to focus on one language: JavaScript. It wasn’t the best for interviewing (seasoned engineers discourage it on Quora and elsewhere) but I didn’t see how it mattered. The purpose of the interview was not to test my choice of languages – it was to test my ability to think abstractly and solve complex computer science-y problems.

The language is just a tool (another core belief I hold). In fact, using an untyped language like JS would give me opportunities to talk about its limitations or strengths, which is an opportunity to demonstrate that I understand the tradeoffs in language choices. That way, I could showcase broader knowledge and insight without actually having to implement it all in code.

But a lot of the resources I learned from used Java or C++. These languages are the dominant languages at Google. So being forced to read these languages and understand the principles forced me to not focus too much on “spitting out the code” and more on reasoning through the code so that I could write it.

That was my entire plan. Practice, Pattern Recognition, Mental Models/First Principle Thinking, System Design, doing fewer things really well, and focusing on getting interviews rather than just learning more code.

How to Stand Out During Interviews

As I mentioned, we all have advantages and disadvantages. And we all think our disadvantages are special and huge and our advantages are common, unremarkable, and probably not of much use.

This is not true. Logically, if we all think our disadvantages are severe, then we should all succumb to them. Yet some people overcome them. Only to find that others had it even worse and overcame those.

It’s way better to focus on what we can do well. For me, I truly believed that I could add a lot of value to the team. I don’t care about being the smartest or the best. But I care about being an outstanding learner, and maintaining my growth mindset at all costs.

And so I tried to use this to stand out as best I could. I learned to ask really good questions of recruiters, interviewers, and hiring managers.

But there was a deeper reason for this. Asking good questions was my way of interviewing the company. Like I said, I didn’t want to repeat the mistakes of the first half of my career. So asking really good questions was important for me to assess whether the company was a fit for me and not just the other way around.

Since I had decided that I was going to value the team and the learning over all else, I never asked about the compensation until the recruiter raised it. It was going to be lower than what I earned as a lawyer anyway!

Instead I focused very hard on learning about the team, its dynamics, its group beliefs and values, how the manager solved problems (especially people problems), what the team was interested in, what the company division was interested in, how its balance sheet was doing, what its strategy was, what its resource allocation and budgeting looked like, and so on.

All these things were things I'd learned in other industries, as an individual contributor, as a manager, executive, founder and so on.

And all of these things also showed that I was being highly intentional. I was genuinely interested in the team, and the company, its product and its future. This wasn’t just another job I was applying for. This was active and personal…not passive and opportunistic.

And I believe that helped me stand out. Maybe not for all the roles I interviewed for, but for many of the offers I got.

When I was on the hiring side, I’d always prefer candidates who were genuinely interested in the role, the people, the product and the company. Those that showed up just “to get a job” didn’t have the kind of energy and drive we wanted.

Interview Planning and Strategy

The last aspect of my roadmap required me to deeply understand the different types of coding interview processes.

This included technical and non-technical interviews, the format of interviews, the way companies organize them, run them, plan them, staff them, evaluate them, and weigh them. But it also required me to understand my strengths and weaknesses.

When going for Big Tech in the US I was aiming for 2-3 interviews per month – a huge goal given that I was not even in the US and was in a timezone that was 17 hours ahead of the west coast.

I had to plan and structure interviews at weird hours so I could accommodate my day job as a developer and also my study time. Some interviews took 6 hours, some took 10 or more. Some were “pair programming for a day” type interviews.

All this took a ton of planning, and mental training. I had to be careful to get the right sleep, the right exercise, maintain my mindset and confidence, deliver on my day job, be there for my family, study and maintain focus on my goals.

For this, I had to be honest with myself at what I was good at. For example, I am not a morning person. But I can endure late nights. So I structured interviews, work, sleep, or even exercise accordingly.

There were some interviews that were scheduled at 2am or after, and I wouldn’t sleep before (as I really am not good at waking up on time!). So I’d do a full workout at 1am to get my energy and focus up, then interview, then sleep till 10 am, then go to work and manage my schedule accordingly.

I would also be careful to plan interviews so that I wasn’t doing two of them back to back unless they were very similar and time bound. For example, doing a take-home test and doing a timed test in the same week require different planning from doing a take-home and a live-coding interview – all while managing work and family.

To schedule the interviews appropriately I’d work closely with the recruiter and be very transparent with them. This had two advantages: I gained credibility and trust with the recruiter for being collaborative and communicative, and they also got to see that I had other opportunities going, which increased the value of my candidacy. Competition is a good thing.

Concluding Thoughts

I am sure many of you were expecting this article to give “insider” tips and a specific set of languages, and DSA questions to learn. I believe I’ve given you something much better. Rather than giving you fish, I am showing you how to fish.

Apart from the ethics of it, insider tips are of limited value, especially in Big Tech. In huge companies things can be vastly different from team to team and city to city. You need to understand the principles of recruitment and career development, rather than just the specific languages and algorithms. Assuming that all interviews are the same is a big mistake.

And as for our obsession with data structures and algorithms…managing your career is the ultimate algorithm. Your mind is the ultimate data structure. Learn how to work with both and you’ll always do well, despite the occasional failures. Powerful ideas aren’t grandiose – they’re elegantly minimal.

If you have read this article you will have noticed some of the things I linked to include multiple ways to reach me. You can also get invited to my webinars, mini-courses and newsletters if you want to go beyond just “learning to code” and learn how to build a career that is right for you.

Perhaps the most important message I can leave you with is that it is a mistake to obsess about big tech. Yes, they’re great to be part of, but if we believe they’re the only thing that is right for us we will miss out on all the other amazing opportunities.

Big Tech has glamor because of cultural trends these days. Sure, it’s nice to work for a great organization, but plenty of great organizations are not well known. Plus what is “great” for one person is pain for another.

Your number one priority is to be happy, fulfilled, and live the life that you want. This is not derived from a company. This comes from the people you spend time with (especially colleagues) and the kind of work you do. Big Tech companies have their share of bad managers, teammates, and work, just like any other company.

If you build skill, stack a great plan on top of the right mindset, and train yourself to set the right goals, you can achieve much more than you dreamed of – with or without Big Tech.

Post Script

If you would like to learn more about my journey from lawyer to software engineer, check out episode 53 of the freeCodeCamp podcast and also Episode 207 of "Lessons from a Quitter". These provide the blueprint for my career change.

If you are interested in teaching yourself to code, changing careers and becoming a professional coder, or becoming your own technical co-founder, please reach out here. You can also check out my free webinar on Career Change to Code if that is what you're dreaming of.

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:

• Data Structures Explained

• Learn Data Structures from a Google Engineer

• Learn Algorithms and Data Structures in Python

• Learn about Algorithms and Data Structures

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!

In the words of RealToughCandy, everyone wants a "one-stop shop" when it comes to learning.

She uses this term to describe Educative.io, but Educative.io costs $60 a month unless you choose to commit to its annual plan. So it's not a free resource, which means it's not available to everyone.

If money were not a factor, you might buy a copy of Cracking the Coding Interview, get a LeetCode Premium subscription, and sign up for access to Grokking the Coding Interview before scheduling some mock interviews.

Now, websites like LeetCode are interesting because they provide an excellent resource for free. A large percentage of LeetCode questions are free, the discussions section provides free solutions where the best code/explanations are voted to the top, and the platform itself can run hundreds of test cases in seconds.

Many people argue that LeetCode premium is not worth it, though writers like Yangshun Tay beg to differ. What interests me about LeetCode is not their premium option, but that they make so much of their service available without it.

All that being said, there are a number of quality free resources you can use to prepare for your coding interviews. Let's go through my favorites now.

Best Free Resources for Coding Interview Prep

Without further ado, here are the best free resources I have found for coding interview preparation:

freeCodeCamp articles

The 30-minute guide to rocking your next coding interview is a free article available on FreeCodeCamp. Half the value here is in curated lists of LeetCode questions to match every major topic

Here's another great (and extensive) guide that focuses on JavaScript interviews and goes through all the JS basics you'll need to know. It includes tons of code samples, and moves through the material in an approachable way.

Cracking the Coding Interview

Cracking the Coding Interview is still one of the best resources out there for interview prep, even in 2021. I have heard some people say that it is no longer sufficient, but I have had two coding interviews that were taken out of the book almost verbatim.

Unfortunately, this is not a free resource...but here is a LeetCode forum that maps every CTCI question to a LeetCode one.

The reason this is acceptable is that they are not perfect mappings. For example, the LeetCode String Compression problem is not exactly the same as its CTCI equivalent because it has an added constraint. It is actually harder than the CTCI version

If you do choose to purchase Cracking the Coding Interview, the solutions are all freely available on GitHub. They are in multiple programming languages, in case you are not a Java developer.

McDowell herself built the repository and committed the Java portion to it, so it is very unlikely the repository will removed due to copyright infringement.

BaseCS

BaseCS is a great collection of articles that explain computer science fundamentals, from hash tables to sorting algorithms, with custom illustrations, well-written analogies, and light-hearted explanations.

Best of all, every single article is free from the Medium paywall. Had they not been, Joshi probably could have pocketed hundreds, if not thousands of dollars from all her readers.

Educative.io

The Educative.io course on 14 coding patterns is not free, but a summary is available on HackerNoon and written by an Educative.io cofounder...presumably as either a gesture of goodwill, or a "free sample".

LeetCode questions sorted by programming pattern

Here is a public LeetCode post that maps all 14 coding patterns to respective lists of LeetCode problems.

InterviewNoodle – still in development

Arslan Ahmad is building a consolidated collection of interview preparation articles on Medium called InterviewNoodle. Just weeks ago, I would have written that this resource is very incomplete, but he has added so much content that I actually think he may now want to divide it into sections.

This, like Educative.io, is meant to be a “one-stop shop.” That Arslan Ahmad is the founder of Design Gurus increased my respect for him exponentially, since this means he is attempting to build a free version of an Educative course that makes him money.

Currently the Medium pages on this publication are not paywall blocked. This could be a coincidence, but for now it's a great resource.

The rest of this article will cover additional resources, though the ones above are my favorites.

Additional Coding Interview Prep Resources

An Interview Primer

If you don't know what to expect in a coding interview, the "30-minute guide" from freeCodeCamp linked above is a great "primer". Still, it is rather lengthy – even though it takes 30 minutes to just read through it, it would take much longer to actually review and go through its "General tips" section.

This might be just what you're looking for if you want to be really thorough. But what other options do you have?

"Confessions from a Big Tech Hiring Manager" is my single favorite video. It's by "Pragmatic Engineer," and is all about the interview process.

This video has useful and practical advice, but it also conveys the perfect attitude. He argues that you should think of every failed interview as a learning opportunity.

Other Interview Prep articles

"If software engineering is in demand, why is it so hard to get a software engineering job?" This is a tongue-in-cheek overview of the coding interview process.

If you read it, you should probably ignore the "string compression" story, which does not add much to the article.

The other side of the software engineer interview is a kind of sequel to the article above, summarizing and responding to Pragmatic Engineer's thoughts.

The Responses I Got From A Software Developer Candidate That Made Me Hire Him is an article that provides more insight on the interviewer's perspective, but unlike the two above it is behind Medium's paywall.

What's the Interview Process Like, In a Nutshell?

If I were asked to summarize all the resources above to you, here's what I would share:

• I would say that you typically get between 30 minutes to an hour to solve a coding question.
• You typically get a choice of programming language like C++, Python, Java, or JavaScript, but not always...in some instances you do not have a choice.
• Outside of the coding portion, they are free to ask you pretty much anything, from language-specific questions to favorite projects, but any interview with a coding portion tends to be dominated by it.

And here's some general advice to consider: you are going to be dealing with people who may be pretty tired of interviews. Smile if you can. Try to show enthusiasm. Have a conversation, and try to talk to the interviewer the way you might communicate if the two of you were pair programming, but they were more senior.

How to Start Your Interview Prep

I think that for most people starting out in this interview prep process, LeetCode is pretty hard. Here are two possible starting problems, though the best point of entry is admittedly Cracking the Coding Interview.

• FizzBuzz on LeetCode. I recommend it because it should not require any additional interview preparation, and will help you familiarize yourself with the LeetCode platform.
• Here's an article about FizzBuzz on InterviewNoodle so you can learn more what that's about.
• Jewels and Stones on LeetCode. If you are not able to solve this on your first try, then you will have to learn a technique that is useful in many coding interview problems.

Learn about hashmaps

There are many more data structures than just hashmaps, but I see these come up in coding interviews so often that I think they deserve their own section.

• Valid Anagram is another good LeetCode "starting point." It does not necessarily require a hashmap, but something that acts like a hashmap
• Here is Nick White solving Valid Anagram
• This is Alex Lee using hashmaps in Java. He does not explain the internals of how they actually work, but he provides practical advice on how to actually use them.

What to do after you cover the basics

After you get started preparing and are comfortable with the basics, I would refer back to the resources above.

The 30-Minute Guide and Cracking the Coding Interview (again, there are free LeetCode problem mappings if you do not own Cracking the Coding Interview) both cover computer science fundamentals. And 14 coding patterns goes a little bit further.

Closing Thoughts

There is a lot more work to be done when it comes to coding interview preparation resources. It is relatively easy for me to simply point to good resources in an aggregate post, but actually providing comprehensive reviews or my own resource would require an order of magnitude more effort. I haven't gotten there yet.

So for now, there is certainly a gap. The most comprehensive content, in my opinion, can be found in Cracking the Coding Interview and this Educative.io course. And that's not to mention the plethora of resources someone with a lot of money could afford, from coaches, to coding interview bootcamps, to expensive mock interviews in which the interviewers provide detailed feedback.

That the people behind Educative.io and its "coding interview patterns" course have made efforts to provide free resources, like InterviewNoodle and a HackerNoon article, count for a lot to me.

I personally don't really use sites like GeeksforGeeks or interview resources on Github that are written exclusively in markdown. It would be very useful to build a platform with detailed blog-style explanations and embedded coding platforms, but at that point you would essentially be recreating Educative.io.

Medium provides an interesting case: Some of the best writers can be found here, but they are incentivized to put things behind a paywall. Anyone, in theory, can put up articles without a paywall on Medium the way BaseCS has. But few Medium writers seem to do this anymore.

We need more high-quality articles. We need practice problem lists that are continually updated. We need great YouTube content creators, like Nick White, to continue to provide clear problem explanations.

Efforts by BaseCS were largely successful, and my one wish is that it had continued to produce content...but this was all produced by a single person with a full-time job, a podcast, a YouTube channel, and apparently no compensation from Medium.

Not everyone has the same level of access to educational coding interview resources, so I admire the people who have done everything in their power to create free alternatives.

Yangshun Tay, author of "The 30-minute guide to rocking your next coding interview", sent me a personal email a few months after this article was published and shared some more helpful resources.

• Here's a link to the main Tech Interview Handbook Website, which contains in-depth and structured guides that can really help you prep for interviews.
• Additionally, he's published Grind75 which generates study plans based on time left, which could also be of interest to your readers.

The Tech Interview Handbook currently has about 69,000 stars on GitHub, and the website is the closest thing I have seen to a free, "one-stop-shop" software engineer interview resource.

Grind75 is designed to be a better version of Blind75, a popular list Yangshun also made that received 3200 upvotes on a LeetCode discussion.

I hope these help you out! Happy prepping.

I just joined Cisco Systems, India as a Senior Software Engineer (SDE III) on July 28, 2021. I am working with the Cisco Customer Experience team as a UI developer.

The entire journey from applying for the job to accepting the offer was two months long. I wish to share my interview experience which will help you prepare for a senior-level UI engineer role.

What you will get out of this article?

In this article, I will talk about my journey, from getting the job referral to accepting the offer.

I will talk about the different rounds of the interview process that I went through and the questions I was asked in them. The questions I share here will help you get ready for Angular development roles.

I will also share some of the questions you can ask the interviewer and the HR rep which will help you to know more about the company and the project.

So, lets’ get started!

How I Discovered the Job Posting

The first part of a job search is to get your résumé selected for the role you are looking for. I found out about this opportunity from a tweet shared by Alex Okrushko.

I have been following Alex for the last two years. He used to work with the Firebase team at Google and he is also a part of the NgRx team. I admire him for his immense contribution to the Angular community.

Alex is currently working as the Principal UI Architect at Cisco.

When he shared that they were looking for a UI developer, I realized that it would be the best opportunity to work directly with him. I sent a message over Twitter and he asked me to share my résumé. He was primarily looking for developers with strong Angular skills.

The First Round of Interviews

One week after sharing my résumé with Alex, I received an email for the first round of interviews.

The first step in the interview process was a take-home assignment via Devskiller. The invitation from Devskiller mentioned that I had seven days to complete the assignment. The total time allotted for this round was 2.5 hours. Once the test starts, you cannot stop it, so it has to be a single sitting of 2.5 hours.

I was given an Angular project with some bugs in it. There was a total of 11 unit test cases in the project. I was expected to fix all the bugs and make all the test cases green.

I started the test around 10:30pm (after my dinner) and finished it around 12:45am. I am most productive at night, so I chose that time. I was able to fix all the bugs and all the 11 test cases were green too. I slept happily that night 😊

Angular Concepts Covered in this Round

The first round of interviews was majorly based around the following Angular concepts:

• Data binding
• Event handling
• State ownership and flows
• Forms and form validations
• Observables
• Unit tests using Jasmine
• Attribute directives
• Structural directives - NgIf & NgFor

Alex verified my solution based on bug fixes, unit test status, and coding style. He was impressed with my performance in the first round and so I moved on to round two of the interview.

The Second Round of the Interview

I got the email asking for my availability for the second round of the interview. I was facing some health issues at that time, so I asked to schedule a week later and the interviewer was happy to do so.

The second round was also a project-based interview via Devskiller. I was given an Angular project and there are four questions based on that. All the questions are based on debugging and bug fixes. The total time allotted for this round was 1 hour.

The difference compared to the first round was that this time I was supposed to do a live coding session by sharing my screen with Alex. I was expected to explain the What, Why, and How of the code I was writing and talk through the solution. The thought process to approach the problem was given importance over the implementation.

This round was more of a pair-programming session with me in the driver's seat. Out of the four questions, I was able to solve the first three in 30 mins. The last one was based on the concept of Content child/view child. I struggled a bit with this question but a small hint from Alex helped me solve it.

I started the test at 10:30pm and finished it around 11:20pm.

I was allowed to use online resources during the interview. But the condition was that I had to explain what I was looking for and why.

At the end of the test, I was able to solve all four questions successfully. The feedback from Alex mentioned that I was struggling with a few of the concepts of RxJS and I need to work on that. But he was happy with my overall performance and I was promoted to the third round of the interview.

Angular Concepts Covered in this Round

The second round of the interview was primarily based around the following Angular concepts:

• ViewChild and ViewChildren
• ContentChild and ContentChildren
• Content projection
• Usage of Async pipe
• Multicast observables
• Parent-child relation of the components
• Services

The Third Round of the Interview

I got a call from my manager, Vaibhav, and he informed me that they were happy with my performance in first two rounds and wanted to schedule another round of technical discussion.

He asked me for my availability and I replied to him to schedule the call for the next day at 10 am IST. This round of interviews is conducted by the team in India so it has to be during IST working hours.

Two interviewers joined the call, and after the introduction, I was informed that this round would be divided into two sections, one for Angular and another one for JavaScript.

They started with the questions about Angular. This round had a mix of theoretical as well as scenario-based questions. The Angular interview continued for around 45 mins and I aced it. I answered all but one question.

After 45 mins they switched to the JS side. They started with the core concepts of JS and I answered those questions easily. Then they moved deeper into JS and I was asked few output-based questions. I struggled a bit here.

Then came more output-based questions and I was unable to answer a few of them. The JS interview also continued for 45 mins. I was not happy with my performance in the JS part of the interview. It was pretty average.

The interview was originally scheduled for 1 hr, but it got stretched to 1.5 hrs.

Angular Concepts Covered in this Round

The third round of the interview was based around the following Angular concepts:

• RxJS concepts such as mergeMap & switchMap
• Directives
• How does the ngIf directive work internally? How does it add DOM elements dynamically on the page?
• How can we create a custom directive (with practical example)
• What is Input and Output in a component?
• Few theoretical questions around services, lazy loading of modules, and component communication

JavaScript Concepts Covered in this Round

The third round of the interview was based around the following JS concepts:

• What are the different ways to create and call methods in JS?
• Closures
• Currying
• Event bubbling
• Output-based questions on closure and various setTimeout scenarios

The Fourth Round of the Interview

Two days after the third round of interviews, I got a call from Vaibhav. He informed me that the interviewers were impressed with my Angular skills but they were not happy with my JS skills. But the overall performance was good, so I was able to move on to the fourth and the final round of interviews. He also suggested that I work on improving my JS skills.

The final round of interviews was scheduled on the Tuesday of the following week from 12:30pm to 1:30pm.

This was a managerial round and Vaibhav was the interviewer along with another senior developer from my team. This round was more focused on my non-technical skills.

He asked me about the project I was working on with my current company. I was also asked questions about Agile methodology since I had mentioned that in my résumé. I told him about my open-source work and he asked few questions about that.

At the end of the interview, Vaibhav shared that he was happy with my performance and wanted to go ahead with the offer. The next step was to update HR so that they could continue with the salary and the offer formalities.

Question Asked in the Managerial Round of the Interview

The fourth round of the interview was entirely non-technical. I have mentioned a few of the questions asked in this round, and here are some more:

• Tell me about the current project and tech stack you're using.
• What is your current role and responsibilities?
• What are the Agile practices you are following currently?
• How does your sprint planning look like?
• How does a story refinement happen in your current project?
• How can you resolve a conflict of ideas within your team?
• Why are you looking for a change?
• Why Cisco?

Salary Negotiations and Getting the Job Offer

I was waiting patiently for the call from HR after the fourth round of interviews. I got the call after one week.

The HR rep congratulated me on clearing all the rounds of the interview and asked me about my current salary and notice period. She also asked me to share my payslip and compensation details from my current employer.

After two days, I got another call from HR and she informed me about the salary I was being offered. I asked if there was any possibility of negotiating a better offer. She told me that this was the best possible salary as per my employment grade and it was not possible to increase it any further. I asked her for some time to make the final decision.

I did not want to lose the job offer but at the same time, I also wanted to have a better salary structure than the one offered.

I discussed the situation with my family as well as a few of my friends. I also had a call with Vaibhav, and a few calls with HR as well.

I was very much confused at this point, so I decided to write down the pros and cons of this role. Here is what I came up with:

Pros:

• The project is customer-facing, so I'd get more exposure and increased responsibilities
• Working at the scale of Cisco would be a plus
• It would be a great learning and growth opportunity
• The brand value of Cisco is high

Cons:

• The salary offered was not up to my expectations

Finally, the pros outweighed the cons and I decided to accept the offer. So, I informed HR of my decision. But there was a surprise waiting for me.

HR informed me that since I had taken a long time (around 10 days) to decide on the offer, they have put my offer on hold. I needed to wait further for the final confirmation from Cisco’s end.

I panicked and thought that I had lost the opportunity. But I had no option other than to wait. TBH, I had lost any hope of getting the offer at this point.

After two weeks, I got a call from Vaibhav and he asked me if I was still interested to proceed with the job offer. After my confirmation, he informed me that HR was happy to release the offer letter. The next day, HR called me to confirm the same. By the end of the day, I had the offer letter in my inbox.

I gladly accepted the offer letter. I was relieved and ecstatic. All's well that ends well.

Job offer accepted

How to Ask Good Questions in Your Job Interview

Whenever you are being interviewed for a job, the interviewer always asks this question at the end – Do you have any questions?

A lot of people are confused about what to ask and what not to ask. Some people do not ask any questions at all.

Well, this is a good opportunity to learn more about the project, the team, and the company. So, you should ask your interviewer as many questions as you can.

Here are a few suggestions from my end.

What to Ask the Interviewer in a Technical Interview

• Ask about the details of the project you are being interviewed for
• Are you using any third-party tools/libraries in your application? If the answer is yes, ask about them.
• How does the code review cycle work?
• What are some of the current challenges in the codebase?
• What is the ratio of new features vs the bug fixes assigned to a dev?
• What testing framework do they use in the application for unit testing as well as E2E testing?
• What is the test coverage for the application?

What to Ask the Interviewer in a Managerial Interview

• Ask about the details of the project you are being interviewed for
• What kind of application it is? Customer-facing or internal?
• What will be my roles and responsibilities?
• How is the work-life balance in the project?
• What are my learning and growth opportunities in the next 1/2/3 years?
• What are the current challenges with the project?
• Are there any plans to add new features to the application?
• Ask about the current team structure and where you will fit in it
• How does the team culture look like in the current pandemic situation when we are 100% remote?
• What is the working shift for this project? Is it flexible or fixed? Are there any shift allowances provided? This is a very important question and is often neglected by the interviewees.
• An extension to the previous question – Does my job require any type of weekend support? If the answer is yes, ask about the timing, frequency per month, and the reimbursement policy around that.

What to Ask HR Before Accepting the Offer or Joining the Company

• Leave policies
• Health insurance policies
• WFH policies
• What is the timeline of the annual appraisal cycle?
• Will I be eligible for the appraisal in the next appraisal cycle?
• Do I need to sign any kind of employment bond?
• Does this job require me to move to another city/state?
• Do I have to serve a probation period upon joining the company? If the answer is yes, ask about the duration and its effect on your employment. Every company has different rules related to probation so ask as many questions as you can around this topic
• What are the covid-related benefits company is providing, for example vaccination, medical support, and so on?

Do you Want to Join the World’s Best Workplace?

Cisco Systems has been ranked number one in Fortune’s list of 100 Best Companies to Work For the year 2021 and 100 Best Large Workplaces for Millennials. Do I need to say anything more about the company’s culture?

Cisco provides you with ample learning and growth opportunities. You will get a chance to work on applications used on a worldwide scale. You will be always motivated to grow and explore yourself on a personal and professional level.

So, what are you waiting for? Go to the Cisco Careers portal and apply for the role you want.

I hope my interview experience will be helpful for you. Best of luck with your job interview.

If you like the article, share it with your friends. You can also connect with me on Twitter and LinkedIn. My DMs are always open.

As a React developer, I have gone through my fair share of front-end coding interviews. Recently, I had the opportunity to experience the process from the other side – as an interviewer. Here is what I've learned.

Coding interview usually involve a multi-step process where interviewers assess everything from basic technical knowledge to culture fit. Every step of that process is important and should not be underestimated. Prepare for all of it and prepare well.

But there is one thing that is at the core of (almost) every React interview.

Inevitably, at some point, you have to build a React app.

The App Assignment

Here is a short list of real app assignments I had to complete for my own React interviews over the years:

• Support Desk app – an app to display a list of support desk employees and their contact information.
• Video app – an app where, given a YouTube video URL, it displays it on the page. Users can comment on it.
• Projects app – an app to display a list of on-going projects that users can subscribe to and follow.
• Articles app – an app to display a list of articles where users can leave nested comments for each one.

These assignments are, in many ways, very similar to each other. The reason is that they are assessing the same set of basic React skills. Which skills are those? Let's break them down.

Interview Skill #1 – How to Build UIs with React

A primary job of a React developer is to build and structure React components in a meaningful way.

The assignments above are meant to test your ability to write code in a modular and reusable way while creating abstractions at the right level.

The main goal is for your app to work well. But, as a front-end developer, you are also expected to build UIs that look good, too.

Most of the time, the assignment will come with a concrete design you'll need to follow. If that is the case, it's important to stick closely to it.

But if you believe that there is a good reason to deviate, don't hesitate to do so. Just be prepared to explain why your solution is better.

If there is no design available, the interviewer is probably interested in understanding if you can create sensible UIs on your own. Although this could be more challenging, it also gives you the opportunity to show you are able to make conscious choices when it comes to the front-end.

Tip: It is easy to assume that the expectation is that you have to build all components from scratch. Using a third party component library might feel like cheating in an interview context. But it is not!

Make sure to ask in advance what is expected. Taking advantage of component libraries like MaterialUI or ChakraUI is a huge time saver during interview assignments and will allow you to focus on more interesting parts of the app.

Interview Skill #2 – State Management in React

Another important challenge when it comes to building React apps is state management. There is a myriad of ways to go about this depending on your concrete use case and goals. Check out my article on the topic if you are curious to learn more.

Whatever approach you choose, what is important during as interview assignment is to show the interviewer that you understand and are able to reason about state management.

Your solution needs to make sense without being overly complex or convoluted. Be prepared to explain and defend your choices.

Tip: It is a good idea to match your state management solution to the one used by the company your are interviewing for.

Do they use Redux? Then don't hesitate to include Redux in your project. Are they into state machines? Then xState is your friend, and so on. Make sure to ask the interviewer in advance what they would like to see implemented in your project.

Interview Skill #3 – Data-fetching in React

As a front-end developer, normally you won't be expected to build your own back-end. But the assignment you are given will probably involve some form of data-fetching – likely either through a mock API of some kind or just a JSON file with the necessary data.

This part of the assignment is meant to test if you, as a front-end developer, know how to talk to the back-end. Can you get, display and update the data you receive from the back-end correctly? Do you understand how API requests work?

In a more advanced setting, there might be a conversation about data-fetching architecture, data state management, and front-end caching.

Tip: Make an effort to implement a semi-realistic data-fetching mechanism in your app. In you are given a JSON file, don't just directly import the data in your components. Instead, use fetch or another more advanced (preferably async) approach to get it so that you are able to demonstrate your deeper understanding.

Interview Skill #4 – Routing in React

A lot of the time, creating a React project is synonymous with a single page application. So it is possible that the assignment involves implementing a routing solution.

Here the goal is to demonstrate that you understand the basics of client-side routing and are able to structure your app around it.

Tip: Avoid creating your own client-side routing implementation, unless explicitly required. Opting for React Router or Reach Router is a perfectly acceptable choice.

How to Stand Out in a React Interview

Getting a solid grasp on the basics discussed above is a must and it's a good start to earn points during an interview assignment. But to truly stand out, you have to go a step further.

Here is how.

Understand Your Setup

Most of the time you can get away with using toolchains like Create React App (or similar) when building a React project for an interview. This will help you get started and save time.

In fact, it is important to use those tools in order to spend your time on meaningful development rather than setup.

But it's also important to understand and be able to explain the basic tooling you are using. During a React interview, expect to be asked questions about Webpack and Babel, for example.

But what can really give you an edge is if you not only understand but are able to enhance your existing setup. One idea would be to add a linter (eslint) and a formatter (prettier) to your app. This shows that you really care about code quality and consistency.

Another would be to go even further and setup pre-commit hooks (husky) that lint and format your code with each commit. Crazy, I know!

These tools take minutes to setup but can seem like an impressive extra step in the eyes on an interviewer.

Test Your Code

Very few assignments will explicitly state that tests are required. For this reason, many developers assume tests are not part of the task and completely ignore them. This is wrong!

Most of the time, an interviewer will be impressed to see that you understand the importance of testing your code. It is a very easy but powerful way to set yourself apart.

It is not necessary to have a test for every single line of code in your project. Several strategically selected tests covering the more complicated logic should do the trick just fine.

Don't Ignore Responsiveness

Here is another aspect of your React assignment that is not explicitly mentioned most of the time – responsiveness.

Even if you are given a design at the beginning of the task, almost always it will not be a responsive one. It is up to you care enough about responsiveness to figure it out on your own.

Same as testing, most developers will just ignore responsiveness. Which is good news for you – it gives you the opportunity to shine!

There is no need for the implementation to be perfect and work flawlessly on every screen and device. The mere fact that this is something you though about in your development process should be enough to score you some major points.

Improve Accessibility

Accessibility is a huge concern for most modern web products. Taking even minor steps to improve the accessibility of your project, like adding alt text to your images, for example, can leave a really good impression.

Accessibility is also another reason why you might want to choose a third-party component library when building your assignment. Most components in these libraries are accessible out of the box.

Making your project as accessible as possible can truly make you stand out in an interview. But what is more, accessibility should be (and is becoming) the norm in web development. Make sure your future employer knows you understand that.

Details Matter

Everything in your code should tell the interviewer you are a competent developer – from basics like the way you name and structure your code to minor details like commit messages.

Given that these assignments are usually done under time constraints, it is tempting to just ignore these seemingly unimportant aspects. But getting them right can meaningfully set you apart.

Hopefully this article is useful for your next React interview. Let me know how it goes!

Follow me on Twitter for more tech content.

I'm Lynn, a software engineer and a recent graduate from the University of Chicago. This is the second course in my Coding Interview Crash Course Series. Feel free to check out my YouTube channel, Lynn's DevLab, to stay updated on this series.

This crash course is about Tree Traversal. If you just want to dive right in, you can find the course here (and linked at the bottom of this article). If you want a little more info, read on. 😎

Who is the Course for and What are Tree Traversal Algorithms? 🌳

You will get the most of this course if you already know a bit about the Tree data structure. Check out these tutorials if you need a refresher.

We will cover the traversal algorithms for both Binary Trees and N-ary Trees (in which each parent node has an arbitrary number of children).

If you have heard about Binary Search Trees (BST) before, that's a special type of Binary Tree so the techniques we are going to learn here also apply.

Trees are a favorite interview subject among top tech companies like Google, Microsoft, and Facebook, so let's crunch this topic!

We will learn about four traversal techniques and solve their corresponding LeetCode problems hands-on.

The four techniques are:

• Pre-order (Depth-First Search, DFS)

• Post-order

• In-order

• Level-order (Breadth-First Search, BFS).

Course Outline

This course video runs for a total of 30 minutes and features:

• A high-level description of the four traversal techniques: pre-order, post-order, in-order, and level-order

• Recursive implementations of pre-order, post-order, and in-order (Note: this doesn't apply to level-order)

• Iterative implementations of pre-order, post-order, in-order, and level-order

• An extension of the templates from Binary Trees to N-ary Trees

Let's dive into each of the four techniques below.

Tree Traversal Demonstration Using an Example Tree

We will use the following tree to demonstrate the output from the four traversal techniques.

Note that this tree is a simple Binary Tree, not a Binary Search Tree (BST). A BST is a special type of Binary Tree, so our techniques also apply. Also, in-order traversal becomes especially interesting when we work with a BST, as we will see below.

An example Binary Tree. Note that it's not a Binary Search Tree (BST).

Given this tree, the traversal result from the four techniques are as follows:

• Pre-order: 1, 2, 4, 5, 3

• Post-order: 4, 5, 2, 3, 1

• In-order: 4, 2, 5, 1, 3

• Level-order: 1, 2, 3, 4, 5

Pre-order Traversal

Pre-order traversal is also known as Depth-First Search (DFS) if we analyze the tree as a graph and take the tree root node as our starting node in the search.

As in the example above, we go all the way down to the leftmost node before visiting any other node that is a left child of some parent node.

Pre-order traversal allows us to explore roots before leaves, and is hence ideal for tasks like copying a tree.

Post-order Traversal

Post-order traversal does the opposite of pre-order traversal, allowing us to explore leaves before roots.

In-order Traversal

In-order traversal is especially useful for flattening a tree into an array representation.

For a Binary Search Tree like below, in-order traversal outputs an array in a sorted, non-decreasing order: -4, 3, 2, 5, 18.

Binary Search Tree example

Level-order Traversal

Level-order traversal is also known as Breadth-First Search (BFS) if we consider the tree as a graph and start our search from the tree root node.

We visit every node on the current level (depth) before moving onto those on the next level. Effectively, we visit the immediate neighbor of (one step away from) our current node before visiting neighbors that are farther away.

How to Implement these Four Techniques

We will use the following definition for a node of a Binary Tree:

# Definition for a binary tree node.
# class TreeNode:
#     def __init__(self, val=0, left=None, right=None):
#         self.val = val
#         self.left = left
#         self.right = right

Recursive implementation

Recursive implementations are the most straightforward. The most important thing to remember is the order in which we concatenate the results from the two recursive calls (one on the left subtree and one on the right subtree) with the value of the current node.

def preorder(root):
    if not root:
        return []
    return [root.val] + preorder(root.left) + preorder(root.right)

def postorder(root):
    if not root:
        return []
    return postorder(root.left) + postorder(root.right) + [root.val]

def inorder(root):
    if not root:
        return []
    return inorder(root.left) + [root.val] + inorder(root.right)

Iterative implementation

Compared to recursive implementations, iterative implementations are non-trivial. Most require that we use either a stack or a queue to keep track of the nodes that we need to visit.

def preorder(self, root):
    if not root:
        return []
    ret = []
    stack = [root]
    while stack:
        node = stack.pop()
        ret.append(node.val)
        # note that we append the right child before the left child
        if node.right:
            stack.append(node.right)
        if node.left:
            stack.append(node.left)
    return ret

def postorder(self, root):
    if not root:
        return []
    from collections import deque
    ret = deque()
    stack = [root]
    while stack:
        node = stack.pop()
        ret.appendleft(node.val)
        if node.left:
            stack.append(node.left)
        if node.right:
            stack.append(node.right)
    return ret

The implementation for in-order traversal looks quite different from pre-order and post-order:

def inorder(self, root):
    if not root:
        return []
    ret = []
    stack = []
    while root is not None or stack:
        while root is not None:
            stack.append(root)
            root = root.left
        root = stack.pop()
        ret.append(root.val)
        root = root.right
    return ret

Lastly, we have level-order traversal, where we will output the result as [[nodes on the first level], [nodes on the second level], [nodes on the third level], ...].

def levelorder(self, root):
    if not root:
        return []
    ret = []
    from collections import deque
    queue = deque([root])
    while queue:
        ret_row = []
        # fixed size for current level
        for _ in range(len(queue)):
            node = queue.popleft()
            ret_row.append(node.val)
            if node.left:
                queue.append(node.left)
            if node.right:
                queue.append(node.right)
        ret.append(ret_row)
    return ret

N-ary Trees

We now extend our templates from handling Binary Trees to handling N-ary Trees. We use the following definition for the node of an N-ary Tree:

class Node:
    def __init__(self, val=None, children=[]):
        self.val = val
        self.children = children

To extend our iterative implementations to handle N-ary Trees, all we need to do is to make sure that we are appending the child nodes that we will visit in a correct order.

Recall that in pre-order traversal, we appended the right child before the left child. So when appending the children of a node of an N-ary Tree, we need to reverse the list of children.

def preorder(self, root):
    if not root:
        return []
    ret = []
    stack = [root]
    while stack:
        node = stack.pop()
        ret.append(node.val)
        # reverse the list of children
        for child in node.children[::-1]:
            stack.append(child)
    return ret

For the other traversal techniques, since we are appending the children from the left to the right, we can iterative over the list of children normally:

def postorder(self, root):
    if not root:
        return []
    from collections import deque
    ret = deque()
    stack = [root]
    while stack:
        node = stack.pop()
        ret.appendleft(node.val)
        for child in node.children:
            stack.append(child)
    return ret

def levelorder(self, root):
    if not root:
        return []
    ret = []
    from collections import deque
    queue = deque([root])
    while queue:
        ret_row = []
        # fixed size for current level
        for _ in range(len(queue)):
            node = queue.popleft()
            ret_row.append(node.val)
            for child in node.children:
                queue.append(child)
        ret.append(ret_row)
    return ret

And now we can apply our tree traversal templates to trees that have an arbitrary number of children at each node.

Conclusion

In this crash course on tree traversal, we learned four techniques: pre-order, post-order, in-order, and level-order. We discussed how they differ and what tasks they are best for.

We also implemented them both in a recursive fashion and in an iterative one. Last but not least, we extended the techniques to deal with not only Binary Trees, but N-ary Trees.

I hope now you feel more confident about tree traversal interview questions. This is also a nice segue into the topic of my next crash course on graph traversal.

With the knowledge of pre-order traversal and level-order traversal, DFS and BFS won't be completely out of the blue for you 🤓 I will even talk about how I applied graph traversal when developing an algorithm for my match-three game, Clicky Galaxy, so stay tuned!

Resources

Watch the course here:

Access the code template on my GitHub:

Check out the whole crash course series:

And lastly, feel free to subscribe to my YouTube channel for more content like this :)

I've carefully gone through over 50 resources, I've been through 10 JavaScript interviews, and I've landed a job at a unicorn startup.

And throughout this entire process, I started to see a pattern in the most frequently asked JS interview questions.

In this article, I have tried to list the concepts which will cover 80% of any good JS interview.

So, if you are prepping for your next JS interview this is the perfect cheatsheet for you to review and solidify your skills. Go through this and you'll be ready to rock. 💃

📝Prerequisites

• Basic knowledge of the web and programming
• Familiarity with HTML/CSS and JavaScript (especially ES6+ syntax)

Table Of Contents 📜

• JavaScript Basics – JS Variables and Array Methods
• Functional Programming in JavaScript – Scope, Closures, and Hoisting
• Objects in JavaScript – Prototypes and "this"
• Asynchronous JavaScript – Event Loops, Timers, and Promises
• Advanced JavaScript Concepts to Know - Async/defer, Polyfills, Debouncing, and Throttling
• Storage in JavaScript

Caveat: The focus here will largely be to cover concepts relevant to the interview and not to create a comprehensive booklet for learning the language. Treat this more like a cheatsheet.

If you want to dive in deeply and learn more JS concepts, check out freeCodeCamp's curriculum.

With that out of the way - let's go!

JavaScript Basics 👶

Let's start off with some basic concepts every JS developer needs to know.

Variables in JavaScript 📥

Variables are the building blocks of every programming language. You use them to store values. A variable can be a number, string, and many other types.

Now, JS is a loosely-typed language. You don't have to state the type of variable. You can just declare it, and JS will figure it out on its own.

Now, in JavaScript we have 3 ways to declare variables: var, let, and const.

Here are the key differences:

Let's try to understand them through examples.

We will cover scope later on. For now, let's focus on the other differences.

var a = 3
var a = 4

console.log(a) // 4 as var variables can be redeclared + updated

let b = 3
let b = 4

console.log(b) // Syntax Error as let variables cannot be redeclared

// If we just do, it will work because it can be updated
b = 4 

const c = 3
const c = 4

console.log(c) // Syntax Error as const variables cannot be redeclared or updated

const d

// Will this throw an error? Go through the table and try to find the answer.

Note: In JavaScript, putting a semi-colon after the end of statement is optional. I will be skipping it here for the sake of readability.

== vs === in JavaScript

Let's compare some variables. There are two ways you can do that.

== only checks for the value

=== checks for value + type

let a = 5 // number
let b = '5' // string

console.log(a == b) // true

console.log(a === b) // false

Arrays in JavaScript

Now that we know a bit about variables, let's move on to arrays and array-methods.

If we have declared a lot of variables, it makes sense to store them somewhere. Otherwise it will be difficult to keep track of all of them. Arrays are one way of storing a variable.

let a = 4
const b = 5
var c = 'hello'

const array = [a, b, c]

// or you can just directly do

const arr = [4,5,'hello']

But only storing variables in an array is kind of boring. We can do more stuff with this array (like accessing these variables or changing the order in which they are stored or how they are stored).

For that, JS has a lot of methods. Let's look at some of them now.

JavaScript Array Methods 🧰

The most frequently used array methods in JS are: map, filter, find, reduce, and forEach.

Let's cover map, filter, and forEach. You can explore more in this helpful article.

The map array method

map creates a new copy of the original array. We use it when we want to do something with the elements of the original array but don't want to change it.

map iterates over the original array and takes a callback function (which we'll cover later) as an argument. In the callback function, we tell it what to do with the elements.

const a = [1,2,3,4,5]

// Create a new array which multiplies every element by 2

const d = a.map(function(item){ return item*2 })

console.log(d) // [2,4,6,8,10]

The filter array method

filter creates a new array with elements that meet the given condition(s).

Let's look at an example. I have used arrow functions here. If you are a little uncomfortable with functions, you can cover the next section first and come back.

// Return the words with more than 6 letters
const words = ['react', 'script', 'interview', 'style', 'javascript']

const ans = words.filter((word) => word.length > 6)

console.log(ans) // ['interview', 'javascript']

Try to do the exercises yourself first to test your knowledge. If you come up with different or better solutions, let me know!

Generally, a follow up to this: can you do it without the array method?

let newArr = []

for (let i = 0; i < words.length; i++) {
  if (words[i].length > 6) {
    newArr.push(words[i])
  }
}
console.log(newArr)

The forEach array method

forEach is very similar to map but has two key differences:

First of all, map returns a new Array, but forEach doesn't.

// Return a new array where even numbers are multiplied by 2 
let arr = [1, 2, 3, 4, 5, 6, 7]

function consoleEven(arr) {
  let data = arr.map((num) => (num % 2 === 0 ? num * 2 : num * 1))

  console.log(data)  // [1,  4, 3, 8, 5, 12, 7]
}


// ? is the ternary operator. If the condition is true - first statement is returned otherwise the second one.


consoleEven(arr)

function consoleEven(arr) {
  let data = arr.forEach((num) => (num % 2 === 0 ? num * 2 : num * 1))
  console.log(data) // undefined
}

consoleEven(arr)

And second, you can do method chaining in map but not in forEach.

// Convert  the new array back to original

function consoleEven(arr) {
  let data = arr
    .map((num) => (num % 2 === 0 ? num * 2 : num * 1))
    .map((item) => (item % 2 === 0 ? item / 2 : item / 1))

  console.log(data)
}

consoleEven(arr)

Note: map and forEach don't mutate (change) the original array.

Functional Programming in JavaScript 🛠

We have already used functions above. Let's cover them in more detail now.

Just like how we used variables to store values, we can use functions to store a piece of code which we can reuse.

You can make function in two ways:

function a(){
 console.log('I am a normal function');
 }

const b = () => {
console.log('I am an arrow function')
}

// They are essentially the same but with a few differences which we will cover as we go along this tutorial. 

// We can pass variables as arguments

const c = (name) => {
console.log(`My name is ${name}`)
}

// `` template literal are a new addition to the language. Very useful for string formatting. Values are accessed using ${} inside them.


// We can even pass functions as arguments to a function. Will see more on this when we try to understand closures.

const greet = () =>  {
    const prefix = 'Mr'
    return (name) => {
        console.log(`${prefix} ${name}, welcome!`)
    }
}

console.log(greet()('Jack'))

Now, let's cover some important concepts related to functions.

Function Scope in JavaScript 🕵️

Scope determines from where the variables are accessible.

There are three types of scope:

• Global (declaration outside of any function)
• Function (declaration inside a function)
• Block (declaration inside a block)

Remember from before that var is globally scoped whereas let and const are block scoped. Let's understand that now.

var a = 5 // we can access this a anywhere

function adder(){
    let b = 7
    console.log(a + b)
 }

console.log(adder())

console.log(b) // Error as b is not accessible outside the function

{
const c = 10
console.log(c) // 10
}

console.log(c) // Error as c is not accessible outside the block

Closures in JavaScript (❗important) 🔒

We have already used a closure without even realizing it. In the example below, prefix is a closed-over-variable.

const greet = () =>  {
    const prefix = 'Mr'
    return (name) => {
        console.log(`${prefix} ${name}, welcome!`)
    }
}

console.log(greet()('Jack'))

This section will have a lot of fancy words, so bear with me. We will cover them one by one.

MDN says:

A function bundled together with its lexical environment forms a closure.

Okay, what is a lexical environment?

It is essentially the surrounding state – the local memory along with the lexical environment of its parent.

Whaaat? 🤯 I know it's a bit of a doozy. Let's understand it with a simple example.

function x() {
  var a = 7
  function y() {
    console.log(a)
  }
  return y
}

var z = x()
console.log(z) // [Function: y]
z()

When x is invoked, y is returned. Now, y is waiting to be executed. Kind of like a loaded gun waiting to be shot! 🔫

So, when we finally invoke z, y is invoked. Now, y has to log a so it first tries to find 🔍 it in the local memory but it's not there. It goes to its parent function. It finds a there.

Voila! There you have it - this is closure.

Even when functions are returned (in the above case y) they still remember their lexical scope (where it came from)

Totally unrelated quote for kicks 👻:

They may forget what you said - but they will never forget how you made them feel - Carl W. Buehner

I swear the rest of the article is legit 🤞 Keep reading.

Advantages of Closures in JavaScript 😎

• Currying

let add = function (x) {
  return function (y) {
    console.log(x + y)
  }
}

let addByTwo = add(2)
addByTwo(3)

• Data Hiding/Encapsulation

Suppose you want to create a counter application. Every time you call it, the count increases by 1. But you don't want to expose the variable outside the function. How to do it?

You guessed it – closures!

function Counter() {
  var count = 0
  this.incrementCount = function () {
    count++
    console.log(count)
  }
}

console.log(count) // Error: count is not defined
var adder = new Counter()
adder.incrementCount() // 1

Don't worry about this and new. We have a whole section devoted to them down below.

Disadvantages of Closures in JavaScript 😅

• Overconsumption of memory or memory leaks can happen.

For example, the closed-over-variable will not be garbage collected. This is because, even if the outer function has run, the returned inner function still has a reference to the closed-over-variable.

Note: Garbage collection basically removes unused variables from the memory automatically.

Hoisting in JavaScript 🚩

This is JavaScript's default behavior of moving declarations to the top of the program.

• var declaration is hoisted up and initialized with undefined.
• let and const declarations are hoisted up but not initialized.
• function definitions are also hoisted up and stored as they are.

Let's look at an example:

function consoleNum() {
  console.log(num)
  var num = 10
}

consoleNum() // undefined

// Why no error?

// This is how runtime sees this
{
  var num
  console.log(num)
  num = 9
}

// If instead of var -> let, it will give an error as let values are not initialized

Phew! I am done with functions here, but if you want more check out this amazing talk by Anjana Vakil on functional programming.

Objects in JavaScript 🔮

Just like arrays, objects are a way of storing data. We do so with the help of key-value pairs.

    const developer = {
        name: "Raj",
        age: 22
        }

name is the key and Raj is the value. Keys are generally the name of the properties of the object.

We can store all sorts of data like functions inside an object. You can explore more here on the MDN.

What is this in JavaScript?

Now, working with objects is different in JS than in other popular programming languages like C++. And to understand that properly, we need a good grasp of the this keyword.

Let's try to understand it step-by-step.

In a program, at times, we need a way to point at stuff. Like saying this function right here belongs to this object. this helps us get this context.

You will understand what I am saying better when we look at some examples.

For now, think of this as something which provides context. And remember this important thing: its value depends on how and where it is called.

I know, I know. A lot of this 😬. Let's go over all this slowly.

Start a new program and just log this.

console.log(this)

It will point to the window object.

Now, let's take an example with an object:

function myFunc() {
    console.log(this)     
  }

const obj = {
  bool: true,
  myFunc: myFunc,
}

obj.myFunc()

Now, this will point to the object. So what's happening here?

In the first example, we had nothing left of the . so it defaulted to the window object. But in this example, we have the object obj.

If you do:

myFunc() // window

We again get the window object. So, we can see that the value of this depends on how and where are we doing the calling.

What we just did above is called Implicit Binding. The value of this got bound to the object.

There is another way to use this. Explicit binding is when you force a function to use a certain object as its this.

Let's understand why we need explicit binding through an example.

const student_1 =  {
    name: 'Randall',
    displayName_1: function displayName() {
        console.log(this.name)
    }
}
const student_2 =  {
    name: 'Raj',
    displayName_2: function displayName() {
        console.log(this.name)
    }
}

student_1.displayName_1()
student_2.displayName_2()

We are using this properly, but can you see the problem with the above code?

We are repeating code. And one of the principles of good programming is keep your code DRY! (Don't Repeat Yourself)

So, let's get rid of displayName_2 and simply do:

student_1.displayName_1.call(student_2) // Raj

call forced displayName_1 to use the second object as its this.

There are a lot of other ways we can do this.

Try to solve the given problem yourself.

const myData = {
  name: 'Rajat',
  city: 'Delhi',
  displayStay: function () {
    console.log(this.name, 'stays in', this.city)
  },
}
myData.displayStay()

// create an object yourData and try to use displayStay
const yourData = {
 name: 'name',
 city: 'city'
}


// answer
myData.displayStay.call(yourData)

Finally, remember that I said that there are differences between arrow and regular functions.

The case of this is one of them.

For an arrow function, the value depends on the lexical scope – that is to say, the outer function where the arrow function is declared.

So, if we make the displayName() from above an arrow function, nothing will work.

Arrow functions basically inherit the parent's context which in the above case is the window.

Prototypes and Prototypal Inheritance in JavaScript 👪

Whenever we create anything (like an object or function) in JavaScript, the JS Engine automatically attaches that thing with some properties and methods.

All this comes via prototypes.

__proto__ is the object where JS is putting it all.

Let's see some examples. Fire up your consoles!

let arr = ['Rajat', 'Raj']
console.log(arr.__proto__.forEach)
console.log(arr.__proto__) // same as Array.prototype
console.log(arr.__proto__.__proto__) // same as Object.prototype
console.log(arr.__proto__.__proto__.__proto__) // null

All this is called a prototype chain.

We can do the same with objects and functions as well.

We will always find Object.prototype behind the scenes. That's why you may have heard that everything in JS is an object. 🤯

What is Prototypal Inheritance in JavaScript?

let object = {
  name: 'Rajat',
  city: 'Delhi',
  getIntro: function () {
    console.log(`${this.name}, ${this.city}`)
  },
}

let object2 = {
  name: 'Aditya',
}

Note: Don't modify prototypes this way. It's just for understanding. Here's the right way to do it.

object2.__proto__ = object

By doing this, object2 gets access to the object's properties. So, now we can do:

console.log(object2.city)

This is prototypal inheritance.

Asynchronous JavaScript ⚡

So, JS is a single-threaded language. Things happen one at a time. Only after one thing is done can we move to the next thing.

But this creates problems in the real world, especially, when we are working with browsers.

For example, when we need to fetch data from the web - often times we don't know how long will it take to get it. And whether we will be able to get the data successfully.

To help with this, asynchronous JS comes into play.

And the most important concept to understand is the event loop.

Event Loops in JavaScript ➰

Instead of providing a half-baked explanation here, I highly recommend watching this video by Philip Roberts if you haven't already:

Learn all about event loops in JS here.

Timers in JavaScript – setTimeout, setInterval, clearInterval ⏱️

I hope you watched the video. It mentioned timers. Let's talk about them more now. These are very frequently asked about in interviews.

The setTimeout() method calls a function or evaluates an expression after a specified number of milliseconds.

setInterval() does the same for specified intervals.

setTimeout(() => {
    console.log('Here - I am after 2 seconds')
}, 2000);

const timer = setInterval(() => {
    console.log('I will keep on coming back until you clear me')
}, 2000);

You use clearInterval() to stop the timer.

clearInterval(timer)

Let's go over some questions that use these concepts.

  console.log('Hello')
  setTimeout(() => {
    console.log('lovely')
  }, 0)
  console.log('reader')

  // output
  Hello
  reader
  lovely

Here's a slightly trickier one:

  for (var i = 1; i <= 5; i++) {
    setTimeout(function () {
      console.log(i)
    }, i * 1000)
  }

// output
6
6
6
6
6

And here's a short explanation of what's going on there: when setTimeout comes again into the picture, the entire loop has run and the value of i has become 6,

Now, let's say we want the outcome to be 1 2 3 4 5 – what do we do?

Instead of var ➡️ use let.

Why this will work?

var is globally scoped but let is locally scoped. So for let a new i is created for every iteration.

Promises in JavaScript (❗important) 🤝

Promises are at the heart of Asynchronous JS.

The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.

A promise can be in one of these three states:

• Pending: initial state, neither fulfilled nor rejected
• Fulfilled: operation was completed successfully
• Rejected: operation failed

const promise = new Promise((resolve, reject) => {
  let value = true
  if (value) {
    resolve('hey value is true')
  } else {
    reject('there was an error, value is false')
  }
})

promise
  .then((x) => {
    console.log(x)
  })
  .catch((err) => console.log(err))

Note: resolve and reject are just conventional names. Call it pizza🍕 if you like.

Instead of then/catch, we can also use async/await:

async function asyncCall() {
  const result = await promise
  console.log(result)
}

asyncCall()

One of the advantages of promises is that they are a much cleaner syntax. Before we had promises, we could easily get stuck in callback hell 🌋

Advanced JavaScript Concepts to Know

📚 Polyfills in JavaScript

A polyfill is a piece of code (usually JavaScript on the Web) used to provide modern functionality on older browsers that do not natively support it. MDN

• Let's implement it for map:

// this - array
// this[i] - current value
Array.prototype.myMap = function (cb) {
  var arr = []
  for (var i = 0; i < this.length; i++) {
    arr.push(cb(this[i], i, this))
  }
  return arr
}

const arr = [1, 2, 3]
console.log(arr.myMap((a) => a * 2)) // [2, 4, 6]

Notice how we use this. Here, we have basically created a new array and are adding values to it.

Async and defer in JavaScript ✔️

These concepts are frequently asked about in interviews by big corporations like Amazon, Walmart, and Flipkart. 🏢

To understand async and defer, we need to have an idea of how browsers render a webpage. First, they parse the HTML and CSS. Then DOM trees are created. From these, a render tree is created. Finally, from the render tree - a layout is created and the painting happens.

For a more detailed look, check out this video.

Async and defer are boolean attributes which can be loaded along with the script tags. They are useful for loading external scripts into your web page.

Let's understand with the help of pictures.

If there are multiple scripts which are dependant on each other, use defer. Defer script are executed in the order which they are defined.

If you want to load external script which is not dependant on the execution of any other scripts, use async.

Note: The async attribute does not guarantee the order of execution of scripts.

Debouncing in JavaScript ⛹️‍♂️

Debouncing is another favorite topic of interviewers.

Let's understand it by creating a search bar.

Demo: https://codesandbox.io/s/debounce-input-field-o5gml

Create a simple input field in index.html like this:

<input type='text' id='text' />

Now, in index.js. Don't forget to add it to index.html first:

const getData = (e) => {
  console.log(e.target.value)
}
const inputField = document.getElementById('text')

const debounce = function (fn, delay) {
  let timer
  return function () {
    let context = this
    clearTimeout(timer)
    timer = setTimeout(() => {
      fn.apply(context, arguments)
    }, delay)
  }
}

inputField.addEventListener('keyup', debounce(getData, 300))

First, we have selected the input and added an event listener to it. Then we created a debounce function which takes a callback function and delay.

Now, inside the debounce function we create a timer using setTimeout. Now, this timer's job is to make sure that the next call for getData only happens after 300 ms. This is what debouncing is.

Also, we use clearTimeout to remove it. Don't want too many of them hanging out there taking up memory space!

Phew! Lots of theory. Let's do a fun challenge. You must have seen the countdown before a game starts (it goes like 10, 9, 8, .... with some delay in between). Try to write a program for it.

Here's how you'd do it:

let count = 10

for (let i = 0; i < 10; i++) {
  function timer(i) {
    setTimeout(() => {
      console.log(count)
      count--
    }, i * 500)
  }
  timer(i)
}

Were you able to solve it? Did you do it differently? Let me know your solution.

Throttling in JavaScript 🛑

Let's look at an example again. Suppose that on every window resize event we call an expensive function. Now, we want it such that the expensive function will only be executed once in the given time interval. This is what throttling is.

Create an index.html and an index.js with the following code:

const expensive = () => {
  console.log('expensive')
}

const throttle = (fn, limit) => {
  let context = this
  let flag = true
  return function () {
    if (flag) {
      fn.apply(context, arguments)
      flag = false
    }
    setTimeout(() => {
      flag = true
    }, limit)
  }
}
const func = throttle(expensive, 2000)
window.addEventListener('resize', func)

Almost the same as debouncing. The key difference is the flag variable. Only, when it's true we are invoking the callback function. And it is set to true inside the setTimeout. So the value is true only after the desired time limit.

So, what's the difference between debounce and throttling❓

Let's take the search bar 🔍 example from above. When we are debouncing the input field, we are saying to only fetch the data when the difference between two keyup events is at least 300 ms.

In the case of throttling, we make a function call only after a certain period of time.

Suppose that you are searching for an encyclopedia in the search bar. The first call is made on e and it took us 300 ms to reach p. The next call will be made then only. All the events in between will be ignored.

So, to summarize, debouncing is when the difference between two keyup events is 300 ms. And throttling is when the difference between two function calls is 300 ms. Basically, the function is called after a certain interval of time.

Storage in JavaScript 💾

Finally, a small but important topic to wrap things up.

localStorage: Data persists even after closing your session

sessionStorage: You lose your data when your session is over, like when you close the browser on the tab.

// save
localStorage.setItem('key', 'value')
// get saved data
let data = localStorage.getItem('key')
// remove saved data
localStorage.removeItem('key')
// Same for sessionStorage

And we are done! 🏁 I hope you feel more confident about your next JS interview now. I wish you all the best.

If you have any queries / suggestions / feedback, you can reach me on Twitter: https://twitter.com/rajatetc.

🗃️ Main References

• MDN Docs
• Akshay Saini
• Coding Addict
• Javascript_Interviews

In it, we will learn about an all-purpose coding template for solving backtracking problems and apply it to two LeetCode hard problems. Ready to crunch your next coding interview? Let's go!

If you just want to dive right in, you can find the course here (and linked at the bottom of this article). If you want a little more info, read on. :)

Who is the Course for and What is the Backtracking Algorithm?

This course is suitable for anyone who is preparing for coding interviews, especially those who are looking to hone their skills in solving backtracking problems.

Backtracking is a common category for questions in coding interviews. The algorithm for solving those problems usually involves recursion and building incrementally on previous states to arrive at the ultimate valid solution.

Backtracking is a favorite topic among top tech companies like Google, Microsoft, and Facebook, precisely because it requires robust reasoning and coding competence to nail those questions.

However, because of its recursive nature and complex problem definition, backtracking problems are usually a major source of confusion among devs who are preparing for coding interviews.

To address this confusion, this crash course aims to arm with you a concise, 20-line template that you can apply to the majority of backtracking problems.

Course Outline

This course runs for a total of 40 minutes and the structure is as follows:

• An 8-minute introduction to the template

• A 15-minute hands-on code-along session for LeetCode Question 51. N-Queens

• A 15-minute hands-on code-along session for LeetCode Question 37. Sudoku Solver

The All-Purpose Template

For your convenience, I've copied the template over. This is exactly the same template that I use for my coding interviews, or when I'm developing algorithms for my indie games. I even used it once in my research on a non-convex optimization problem.

def is_valid_state(state):
    # check if it is a valid solution
    return True

def get_candidates(state):
    return []

def search(state, solutions):
    if is_valid_state(state):
        solutions.append(state.copy())
        # return

    for candidate in get_candidates(state):
        state.add(candidate)
        search(state, solutions)
        state.remove(candidate)

def solve():
    solutions = []
    state = set()
    search(state, solutions)
    return solutions

The first three are all helper functions, and the last and most important one, solve, is essentially the one that a LeetCode problem is asking you to write.

Solving LeetCode Problems Hands-On

We will next apply this template to solving two LeetCode hard problems: LeetCode Question 51. N-Queens and LeetCode Question 37. Sudoku Solver.

To illustrate the flexibility of the template, see below for how we solve the N-Queens problem by doing nothing fancy other than adapting the four functions (renaming solve to solveNQueens). The complete code for either problem is available in my GitHub gist.

Watch the video course to follow along my analysis and adaptation of the template.

class Solution:
    # solveNQueens is essentially the solve function
    def solveNQueens(self, n: int) -> List[List[str]]:
        solutions = []
        state = []
        self.search(state, solutions, n)
        return solutions

    def is_valid_state(self, state, n):
        # check if it is a valid solution
        return len(state) == n

    def get_candidates(self, state, n):
        if not state:
            return range(n)

        # find the next position in the state to populate
        position = len(state)
        candidates = set(range(n))
        # prune down candidates that place the queen into attacks
        for row, col in enumerate(state):
            # discard the column index if it's occupied by a queen
            candidates.discard(col)
            dist = position - row
            # discard diagonals
            candidates.discard(col + dist)
            candidates.discard(col - dist)
        return candidates

    def search(self, state, solutions, n):
        if self.is_valid_state(state, n):
            state_string = self.state_to_string(state, n)
            solutions.append(state_string)
            return

        for candidate in self.get_candidates(state, n):
            # recurse
            state.append(candidate)
            self.search(state, solutions, n)
            state.pop()

Check out the video course here:

You can access the template as well as the solutions to the two LeetCode problems (N-Queens and Sudoku Solver) in my GitHub gist:

Final Thoughts

Remember that practice makes perfect, so do try applying this template to more backtracking problems on LeetCode. Best of luck crunching your next coding interview!

For more content like this, check out my YouTube channel:

System Design is an important topic to understand if you want to advance further in your career as a software engineer. Even if you are just beginning your coding journey, it's a good idea to get a head start on learning about system design.

Early in your career you will mostly just be tested on your coding ability. In higher level interviews, however, there will often be a greater focus on testing your ability and experience at designing applications.

The biggest struggle engineers have with system design interviews is that they are more open-ended and there isn't any single correct answer. This lack of structure can be intimidating, so my goal with this article is to give you a roadmap for navigating these types of interviews with confidence.

What this article will cover:

• What is a system design interview and why they are used
• The main stages of a system design interview
• Example interview problem – Design YouTube

Video Tutorial

You can also watch this tutorial on YouTube if you like:

And I've created a playlist of videos on specific topics related to system design and web architecture:

System Design Interview Overview

At first glance it seems silly to ask somebody to design a huge app like Twitter or YouTube in 45-60 minutes. These apps were designed over a period of years by hundreds of engineers working together, so it's clearly an impossible task to do in a short interview.

There are two main reasons why companies use these types of interviews. The first is, of course, to test your knowledge about the technologies being discussed. They want you to go deep enough to make sure you aren't just throwing buzzwords around without understanding how things actually work.

The second reason might be more important, though. The system design interview is a way to simulate a realistic scenario where you are working together with the interviewer to determine the best design decision.

Getting the perfect answer isn't necessarily the most important thing here – it's some of the other things you can show, like:

• How do you handle being challenged? Do you get defensive or take feedback with a positive attitude? Are you stubborn or narrow-minded?
• Do you show knowledge of the various tradeoffs certain design decisions involve? There's a big difference between blindly making a decision and not realizing the consequences, and knowing the pros/cons and accepting the tradeoffs.
• Are you able to effectively communicate and if necessary explain complex technical concepts in an easy to understand way?
• Are you candidate somebody the interviewer would want to work with long term? Even if somebody is a genius, if they are miserable to work with they might not be a good hire.

Stages of a System Design Interview

In this section you'll learn a general framework for structuring how to handle a problem during a system design interview.

Clarify the problem and establish design scope

The first thing you'll want to do after your interviewer gives you the problem is to take a few minutes to ask some clarifying questions and figure out what exactly they are looking for.

The worst thing you could do here is just start off in the completely wrong direction because you didn't take the time to ask a few questions. You have a limited amount of time during the interview, so you want to make sure you focus on what's important.

Here are some examples of questions you might ask:

What are the use cases / features of the app?

In this article we will be using YouTube as an example. There are hundreds of different features you could design like ad delivery, authentication, recommendation algorithms, comments, video upload, video processing, and many others.

During an interview you only have time to cover a few of those, so make sure to ask the interviewer questions to figure out what they want you to focus on designing.

How many users are expected / what is the likely traffic volume?

The complexity of the system will depend on the amount of traffic it needs to handle, so make sure to gather this information.

You don't want to over-engineer things if the traffic is relatively low and you also don't want to get stuck with an app that can't scale because you didn't design it properly.

Ask questions like how many users the app will have, the average amount of data per request, how long data needs to be stored, and how reliable and available does the system need to be?

This step is going to help you beyond just getting more information to work with. You're also showing the interviewer that you understand how to gather information about a vague problem.

Determine Rough Capacity Estimates

Using the information you gathered during the first step, you can begin to make some rough estimates and generalizations for things like storage and bandwidth requirements.

This process will involve some basic math like multiplying the number of users by the average request size and the amount of requests each user is expected to make daily.

Create a High Level Design

Here you want to create a rough architecture for the system. Draw out things like load balancers, web servers, app servers, task queues, database, caching, file storage, and so on. You should include all the core components you need to create the system.

Make sure to communicate with the interviewer during this stage and check to ensure that you aren't missing anything. While they probably won't tell you directly, they will give you a nudge in the right direction if you forgot about some crucial feature.

API Design

This part is almost cheating because you are using the structure of the interview to your advantage to confirm that you are on the right path.

The interviewer is never going to deliberately lead you down the wrong path, so once you've created your high level design you can start sketching out some rough API endpoints for each component.

For the YouTube example they might look something like this, depending on which features you are building:

• uploadVideo (userID, video, description, title)
• comment (userID, videoID, comment)
• viewVideo (videoID)
• videoSearch (query)

In some cases you might not need to drill down to this level. If the interview question is very high level like "design Youtube", you can probably skip this part. On the other hand if you get a more focused question like "design YouTube's comment system", it would make sense to go more in depth.

Create a Data Schema

At this point you should have a good idea of all the requirements and data needed for the application to work, so now you can plan out how your data is structured.

Depending on what you are building and the requirements, you'll need to weigh the costs and benefits of things like using a relational vs non-relational database. When modeling your data you'll also want to account for things like potential data partitioning and replication.

Take a Detailed Look at the Components

What happens during this section will mainly depend on the feedback of the interviewer. They will probably pick out a few specific components to focus on and ask why you made certain decisions.

The most important part here isn't necessarily being 100% right. Instead, it's to show that you didn't just blindly make decisions and understand exactly what tradeoffs you were making.

You should be able to propose alternate design decisions that could have been used and explain why you didn't use them.

How to Design YouTube

Now that you have a general idea of how a system design interview works and a framework for handling a system design problem, I'm going to show you how to put it all into practice using YouTube as an example.

Step 1 – Define Problem Scope and Requirements

This will be a high level problem where we implement a few of YouTube's major features without diving too in-depth on any of them. The features to focus on will be:

• Users can upload videos
• Users can view videos
• Users can comment on videos

Step 2 – Determine Capacity estimates

The two biggest capacity factors in an app handling large amounts of video like YouTube will be storing all that content and bandwidth requirements to deliver the content to users. In this section you'll learn how to make rough estimates for capacity requirements.

The main focus here is not on being highly accurate, but showing a logical thought process for calculating these numbers based on the information available to you.

In an interview you would be given the data, but in this case I'm using two key pieces of data that YouTube has made public:

• YouTube creators upload 500 hours of video every minute
• YouTube users watch 1 billion hours of video per day

You can use these numbers to calculate storage and bandwidth requirements with a few assumptions.

Bandwidth Calculation

Daily bandwidth calculation

To calculate an estimate for bandwidth, we start with the amount of video watched daily. The key assumption here is how much bandwidth is used per hour watched, as this would depend on the quality of video most users choose to watch.

The 3 Gigabyte estimate is based on a rough percentage of users watching in standard definition and others choosing HD or 4K, which consume much more bandwidth per hour watched.

The math here is fairly simple: multiply 1 billion hours by the average bandwidth of an hour of video, then divide that by 1000 to convert to terabytes, then divide by 1000 again to get to Petabytes. The final bandwidth estimate is 3,000 PB used daily.

Storage Calculation

Step by step calculations for storage

Based on a few assumptions we can calculate that YouTube will need to store around 2.16 Petabytes of new video every day. Here's how we get that number:

• Convert 500 hours to 30,000 minutes of video uploaded per minute
• Each minute of HD video is roughly 50 Megabytes due to having copies of each video in multiple formats. We multiply that by 30,000 minutes and then divide by 1000 to convert to Gigabytes.
• We then take the 1,500GB uploaded per minute and multiply by 60 then 24 to calculate the daily amount of video uploaded. We divide by 1000 again to convert Gigabytes to Terabytes
• Our final total is 2,160 Terabytes uploaded daily or 2.16 Petabytes

Step 3 – Database Design

For our database we will use a standard relational database like MySQL. The schema will look something like this:

This design is very simple but has the essentials that you'd need for a basic implementation. It would be a good idea to do some research into the differences between relational and non-relational databases so you understand what kind of situations each excel at and when to use them.

For certain apps with different requirements a NoSQL database might make sense. Often large systems will have many different services that use different types of databases depending on their needs.

Step 4 – High Level Design

That's a pretty complex diagram, so let me break down what's happening:

• Client – This could be a user on a mobile app or their computer trying to upload a video, make a comment, or watch a video
• CDN – A content distribution network is used to reduce latency and improve reliability when it comes to delivering static content like videos or images. A CDN works by storing content in data centers all around the world so that the content is closer to users. This results in reduced latency because requests travel a shorter distance. There's also an added benefit of content being stored in multiple locations so even if one location can't serve traffic for some reason, another location can.
• Load Balancers – A load balancer accepts requests and routes them to servers depending on a number of factors. At YouTube's scale, a single server can't handle all the traffic and you want replication to prevent a single point of failure. The load balancer can check the status of servers and verify they can handle traffic or choose another server that can handle the request.
• Services – You can think of this as the app layer of the system. Instead of using a single monolith to handle traffic, we'll use several microservices to handle specific tasks. The second box for each of these services in the diagram represents multiple servers running for each of them to increase reliability. If one replica of the service goes down, there's always another to step in and handle traffic.
• Data Stores – When using microservices it is generally best practice for each microservice to own its own data. If one service needs data from another they can access it through an API.
• Video Upload Process – Handling the video uploads will involve multiple steps, as trying to handle it synchronously with the app server would be fragile and reduce performance. I'll cover this more in depth in the next section

I don't want to go too in-depth on these individual components because I could write entire articles on any of them if I wanted to explain them fully.

If you are interested in a more detailed explanation you can check out the system design playlist I linked to above which has videos covering most of these concepts.

Step 5 – Go Over Specific Components and Details

At this stage you have a working design. Now let's look at some of the specific components in detail.

Video Upload

Video content is the lifeblood of YouTube, and it doesn't exist without it. This means that making it quick and easy for users to upload videos is probably the most important feature.

Imagine uploading a multi-gigabyte video to YouTube and then seeing the upload fail after 30 minutes when it's 95% done. To prevent this you'll want to support the ability for resuming uploads if the client's connection is lost temporarily. The uploaded video can then be stored with a distributed file system like HDFS.

Once the upload is complete there's still a lot more to do before the video is ready for users to access. The video needs to be encoded into multiple different quality formats, you need to generate thumbnails, and push copies of the video to the global CDN.

Again, at any stage one of these processes could fail. To prevent this you'll have a task queue to manage this process and retry the processing attempt if it fails at any stage.

Database Scaling

The database is often the bottleneck of an application. You will probably be tested on whether you understand some of the fundamental concepts around database scaling. This could include caching to handle read requests, sharding, and replication.

Conclusion

Hopefully this article has given you a better understanding of what to expect during a system design interview.

This article mainly focused on the structure of the interview itself rather than the concepts you need to understand to answer the questions given during the interview.

Two great resources for beginning to learn about that are:

A great article posted here on Free Code Camp News: https://www.freecodecamp.org/news/systems-design-for-interviews/

The system design primer repo on GitHub: https://github.com/donnemartin/system-design-primer

Both cover just about every major concept you need to know for your system design interview and should put you in a great position for success.

Technical interviews are one of the most stressful parts of landing a job in tech.

You don't know what questions the interviewer is going to ask. What if you have no idea how to solve the problem in front of you? What if you freeze up and look like you don't know what you're doing?

Many aspiring programmers work themselves up into a frenzy as they try to memorize every coding interview question. You and I both know this approach is unsustainable. I'm here to tell you there's an easier way.

I recently sat down with my friend Michelle, who's a senior software engineer at Stitch Fix (a recently IPO'd company). She shared the kinds of qualities she looks for in developers that she interviews.

Honestly, the qualities might surprise you. I promise they don't include memorizing coding interview questions and solutions.

The rest of this article will unpack the qualities Michelle looks for in developer candidates. I'll translate each of these qualities into key interview behaviors. Then I'll tell you how you can implement them in your own interviews. Let's get started.

Qualities you should have going into the coding interview

When I sat down with Michelle, a part of me imagined I was getting a secret code to cracking the coding interview. I thought I'd hear the ultimate algorithm to solving every problem out there.

While we know a universal algorithm doesn't exist, she did share something even better: how to create a mental a framework for interviewing.

Success is not about memorizing every problem and solution. Rather, it's about learning how to solve problems.

As a developer, there won't be a cookie-cutter LeetCode type of answer. This is where mental frameworks are incredibly helpful. They create just enough problem solving certainty to overcome a seemingly ambiguous problem.

Here are Michelle's key components to building a killer mindset framework for your coding interview.

Be curious

One of Michelle's biggest tips for developer candidates is to be curious. Clarify the problem and ask questions. Share any thoughts you have on the problem you're facing. Interviewers aren't just looking for the right solution. They want to see how you think.

The best way you can show how you think is by asking questions. Let's say an interviewer asks you to check if a string contains any digits. You should clarify the question in your own words, something like:

"So I need to find a way to verify if a set of characters contains any numbers?"

When you say this you're giving interviewers insight into your logic. You're also showing them you're interested in the problem.

And don't be afraid to ask follow-up questions. Using the same example above, here are a few questions you can ask:

"Do the numbers I'm looking for contain decimals?"

"Do I need to sort the characters in any way before checking them?"

Be open to suggestions

One thing that is easy to forget is that interviewers want you to succeed. Most interviewers want to provide real-time feedback and suggestions to candidates. But candidates often take a non-verbal, siloed approach to the coding interview.

One way you can be more open to suggestions is by engaging your interviewer. Verbalize your logic and take them along your problem solving journey.

We'll use the same problem as above. Here are a few ways you can verbalize your logic from the get-go:

"So I'll need to establish a way to separate characters from numbers, right?"

"I'm thinking about iterating through the set of characters from end to end."

"I want a programmatic way to iterate through characters, but stop at numbers."

The more insight you can provide, the more your interviewer will feel inclined to help.

Work collaboratively

This goes hand in hand with the above. The idea that a developer works siloed and alone is a myth. You have version control and project management tools that require collaboration.

You should verbalize your approach, ask great questions, and loop your interviewer in. You'll arrive at the solution much more quickly. But you'll also show your interviewer you can effectively collaborate with other developers.

Here are a few ways you can loop your interviewer in:

"Would a for loop be too simple/complex for this solution?"

"How important is it to establish if there are floats or not?"

"Is there any type of solution you have in mind?"

Be willing to just go for it

Finally, Michelle suggested that developer candidates should just go for it. Meaning, go for the success you want to see.

One of the most common occurrences for candidates is that they freeze up. While this is understandable, no one wins in this situation. You can't show how incredible you are and the interviewer can't help you. Here's what Michelle said to "just go for it":

Even if you have to pseudocode your implementation, that’s better than being too nervous to try. Putting something on the board/coderpad will invite discussion, a chance to share your thoughts, and an opportunity to learn.

Don’t be afraid to fail! It just means you’re one step closer to succeeding. :)

"Just go for it" can mean a lot of things. That said, here are a few examples of what that can look like:

• Write pseudocode on the whiteboard, paper, or coderpad
• Note exactly where you are stuck in your logic
• Verbalize the solution you wish you could come up with

Use the Mindset Framework to Ace Your Coding Interview!

Coding interviews can be scary and there's always the fear that you'll freeze up. Part of this fear stems from not knowing which questions will show up.

The great thing is that you no longer have to memorize coding questions and solutions. Instead, build a mindset framework with the key interview behaviors you read about today.

You want to be curious and open to suggestions. You should work in collaboration with your interviewer. Be willing to go for the success you want to see. Happy interviewing!

If you want to see more of this type of content, subscribe to my newsletter at Course to Hire. I'll help you learn how to code and break into tech. Feel free to add me on LinkedIn as well.

P.S. – if you're interested in connecting with Michelle, ping me on Course to Hire or LinkedIn and I can make the intro.

I had fifteen minutes left, and I knew I was going to fail.

I had spent two months studying for my first technical interview.

I thought I was prepared, but as the interview came to a close, it hit me: I had no idea how to solve coding problems.

Of all the tutorials I had taken when I was learning to code, not one of them had included an approach to solving coding problems.

I had to find a method for problem-solving—my career as a developer depended on it.

I immediately began researching methods. And I found one. In fact, what I uncovered was an invaluable strategy. It was a time-tested four-step method that was somehow under the radar in the developer ecosystem.

In this article, I’ll go over this four-step problem-solving method that you can use to start confidently solving coding problems.

Solving coding problems is not only part of the developer job interview process—it’s what a developer does all day. After all, writing code is problem-solving.

A method for solving problems

This method is from the book How to Solve It by George Pólya. It originally came out in 1945 and has sold over one million copies.

His problem-solving method has been used and taught by many programmers, from computer science professors (see Udacity’s Intro to CS course taught by professor David Evans) to modern web development teachers like Colt Steele.

Let’s walk through solving a simple coding problem using the four-step problem-solving method. This allows us to see the method in action as we learn it. We'll use JavaScript as our language of choice. Here’s the problem:

Create a function that adds together two numbers and returns that value.

There are four steps to the problem-solving method:

1. Understand the problem.
2. Devise a plan.
3. Carry out the plan.
4. Look back.

Let’s get started with step one.

Step 1: Understand the problem.

When given a coding problem in an interview, it’s tempting to rush into coding. This is hard to avoid, especially if you have a time limit.

However, try to resist this urge. Make sure you actually understand the problem before you get started with solving it.

Read through the problem. If you’re in an interview, you could read through the problem out loud if that helps you slow down.

As you read through the problem, clarify any part of it you do not understand. If you’re in an interview, you can do this by asking your interviewer questions about the problem description. If you’re on your own, think through and/or Google parts of the question you might not understand.

This first step is vital as we often don’t take the time to fully understand the problem. When you don’t fully understand the problem, you’ll have a much harder time solving it.

To help you better understand the problem, ask yourself:

What are the inputs?

What kinds of inputs will go into this problem? In this example, the inputs are the arguments that our function will take.

Just from reading the problem description so far, we know that the inputs will be numbers. But to be more specific about what the inputs will be, we can ask:

Will the inputs always be just two numbers? What should happen if our function receives as input three numbers?

Here we could ask the interviewer for clarification, or look at the problem description further.

The coding problem might have a note saying, “You should only ever expect two inputs into the function.” If so, you know how to proceed. You can get more specific, as you’ll likely realize that you need to ask more questions on what kinds of inputs you might be receiving.

Will the inputs always be numbers? What should our function do if we receive the inputs “a” and “b”? Clarify whether or not our function will always take in numbers.

Optionally, you could write down possible inputs in a code comment to get a sense of what they’ll look like:

//inputs: 2, 4

Next, ask:

What are the outputs?

What will this function return? In this case, the output will be one number that is the result of the two number inputs. Make sure you understand what your outputs will be.

Create some examples.

Once you have a grasp of the problem and know the possible inputs and outputs, you can start working on some concrete examples.

Examples can also be used as sanity checks to test your eventual problem. Most code challenge editors that you’ll work in (whether it’s in an interview or just using a site like Codewars or HackerRank) have examples or test cases already written for you. Even so, writing out your own examples can help you cement your understanding of the problem.

Start with a simple example or two of possible inputs and outputs. Let's return to our addition function.

Let’s call our function “add.”

What’s an example input? Example input might be:

// add(2, 3)

What is the output to this? To write the example output, we can write:

// add(2, 3) ---> 5

This indicates that our function will take in an input of 2 and 3 and return 5 as its output.

Create complex examples.

By walking through more complex examples, you can take the time to look for edge cases you might need to account for.

For example, what should we do if our inputs are strings instead of numbers? What if we have as input two strings, for example, add('a', 'b')?

Your interviewer might possibly tell you to return an error message if there are any inputs that are not numbers. If so, you can add a code comment to handle this case if it helps you remember you need to do this.

// return error if inputs are not numbers.

Your interviewer might also tell you to assume that your inputs will always be numbers, in which case you don’t need to write any extra code to handle this particular input edge case.

If you don’t have an interviewer and you’re just solving this problem, the problem might say what happens when you enter invalid inputs.

For example, some problems will say, “If there are zero inputs, return undefined.” For cases like this, you can optionally write a comment.

// check if there are no inputs.

// If no inputs, return undefined.

For our purposes, we’ll assume that our inputs will always be numbers. But generally, it’s good to think about edge cases.

Computer science professor Evans says to write what developers call defensive code. Think about what could go wrong and how your code could defend against possible errors.

Before we move on to step 2, let’s summarize step 1, understand the problem:

-Read through the problem.

-What are the inputs?

-What are the outputs?

Create simple examples, then create more complex ones.

2. Devise a plan for solving the problem.

Next, devise a plan for how you’ll solve the problem. As you devise a plan, write it out in pseudocode.

Pseudocode is a plain language description of the steps in an algorithm. In other words, your pseudocode is your step-by-step plan for how to solve the problem.

Write out the steps you need to take to solve the problem. For a more complicated problem, you’d have more steps. For this problem, you could write:

// Create a sum variable.

Add the first input to the second input using the addition operator.

// Store value of both inputs into sum variable.

// Return as output the sum variable.

Now you have your step-by-step plan to solve the problem.

For more complex problems, professor Evans notes, “Consider systematically how a human solves the problem.” That is, forget about how your code might solve the problem for a moment, and think about how you would solve it as a human. This can help you see the steps more clearly.

3. Carry out the plan (Solve the problem!)

The next step in the problem-solving strategy is to solve the problem. Using your pseudocode as your guide, write out your actual code.

Professor Evans suggests focusing on a simple, mechanical solution. The easier and simpler your solution is, the more likely you can program it correctly.

Taking our pseudocode, we could now write this:

function add(a, b) {
 const sum = a + b;
 return sum;
}

Professor Evans adds, remember not to prematurely optimize. That is, you might be tempted to start saying, “Wait, I’m doing this and it’s going to be inefficient code!”

First, just get out your simple, mechanical solution.

What if you can’t solve the entire problem? What if there's a part of it you still don't know how to solve?

Colt Steele gives great advice here: If you can’t solve part of the problem, ignore that hard part that’s tripping you up. Instead, focus on everything else that you can start writing.

Temporarily ignore that difficult part of the problem you don’t quite understand and write out the other parts. Once this is done, come back to the harder part.

This allows you to get at least some of the problem finished. And often, you’ll realize how to tackle that harder part of the problem once you come back to it.

Step 4: Look back over what you've done.

Once your solution is working, take the time to reflect on it and figure out how to make improvements. This might be the time you refactor your solution into a more efficient one.

As you look at your work, here are some questions Colt Steele suggests you ask yourself to figure out how you can improve your solution:

• Can you derive the result differently? What other approaches are there that are viable?
• Can you understand it at a glance? Does it make sense?
• Can you use the result or method for some other problem?
• Can you improve the performance of your solution?
• Can you think of other ways to refactor?
• How have other people solved this problem?

One way we might refactor our problem to make our code more concise: removing our variable and using an implicit return:

function add(a, b) {
 return a + b;
}

With step 4, your problem might never feel finished. Even great developers still write code that they later look at and want to change. These are guiding questions that can help you.

If you still have time in an interview, you can go through this step and make your solution better. If you are coding on your own, take the time to go over these steps.

When I’m practicing coding on my own, I almost always look at the solutions out there that are more elegant or effective than what I’ve come up with.

Wrapping Up

In this post, we’ve gone over the four-step problem-solving strategy for solving coding problems.

Let's review them here:

• Step 1: understand the problem.
• Step 2: create a step-by-step plan for how you’ll solve it.
• Step 3: carry out the plan and write the actual code.
• Step 4: look back and possibly refactor your solution if it could be better.

Practicing this problem-solving method has immensely helped me in my technical interviews and in my job as a developer.

If you don't feel confident when it comes to solving coding problems, just remember that problem-solving is a skill that anyone can get better at with time and practice.

Good luck!

If you enjoyed this post, join my coding club, where we tackle coding challenges together every Sunday and support each other as we learn new technologies.

If you have feedback or questions on this post, feel free to Tweet me @madisonkanna.

There are two big things I that I usually find missing in interviewing guides:

1. Your chief aim as a candidate should be to make a connection and have a real conversation.
2. You may not be given a good opportunity to make a connection.

There is no one formula for success in interviews because interviews are run like the Wild West. But you can maximize your chances.

How to Connect with Your Interviewer through Stories

Tech interview guides focus a lot on challenges, puzzles and tests. We should put more emphasis on the discussions to establish if you’re a fit for the role.

As a candidate it’s extremely valuable to be well prepared for the fit interview. It’s a chance to make a great impression at a personal level and not just as a test score.

A big part of this preparation is having stories that present the skills you want to present. Let’s consider examples of what this can look like.

Example Interview Question and Answer

Interviewer: Could you give me an example of something you worked on at company X?

Candidate: One of my favourite projects was a performance improvement project. I introduced a new library for mapping code entities to the database. I also introduced a benchmarking tool to measure the improvement. It showed a speed-up of 40% for some queries.

Interviewer: That's interesting, what did you enjoy particularly?

Candidate: I enjoyed seeing the difference it made to the user experience. I also liked that it was a well-defined task and it was rewarding to get it done. I can talk more about the challenges if you like?

Interviewer: Sure, what would you say was the biggest challenge on that piece of work?

Candidate: Well I knew which library I wanted to migrate to. But it wasn’t compatible with another library we were using. I saw that it would become compatible if we upgraded that other library. So I had to explain that and get agreement to do the upgrade. There were some code changes involved and one of the others was initially reluctant. I convinced them by doing a small PoC to show that the changes weren’t that big.

Preparing stories that answer the first question in this exchange is good preparation. But the big value is in the follow-on conversation. That’s where the interviewer really gets to see your problem-solving skills. And in this case, also your teamwork skills.

You don’t want to just aim to be telling stories. You want to be bringing the interviewer with you through your accomplishments. Those accomplishments don’t make sense unless you reveal what was difficult about them.

Sharing your experience effectively is even more important for more senior roles.

Interviewer: What was the best thing you did at company X?

Candidate: I led the implementation of a new feature to generate business insight reports. It was very well received and helped lead to doubling of sales.

Interviewer: How did you ensure the reports offered the insights the business was looking for?

Candidate: It took a couple of iterations to get them right. We agreed on initial specs but they were a bit rough and the business wasn't very clear from the beginning. In the second iteration they got more excited and could guide us more clearly.

Interviewer: Why do you think the business wasn't excited until the second iteration?

Candidate: I think the mockups we'd done for the first didn't feel real to them. We'd mocked the data and they needed to see it with some of the real records to see the value they could get from it.

Here the initial story doesn’t demonstrate much. It asserts an achievement but it doesn’t demonstrate. The answers to the follow-ups show an appreciation of stakeholder management and requirements solicitation. Getting a flow of conversation going like this also helps the interviewer to relate.

Both of these example exchanges do well at making a connection. The answers get to the point and are explained so that the interviewer can understand them. They tell stories of overcoming challenges. They show appreciation of tricky problems as well as good collaboration skills.

Have stories prepared that show off your experience. Be prepared to answer questions like “tell me about a time when…” If you’re well prepared you’ll look forward to these questions. They can lead to good discussions.

Get to Know the Company

Your conversations will be more productive if you tailor them to the company and the role. Look at what the company does and what tech they use.

When you know a little about the company, think about which stories you’d like to emphasise. Which of your experiences would be most relevant to this role?

The job ad likely says which skills are must-haves and how much experience they’re looking for. It’s ok to not match it perfectly. Think about where you are a strong fit and emphasise that. Acknowledge your limitations and stress that you’d be keen to learn to fill the gaps.

You’re more likely to get favourable questions if you tailor your CV to the job ad. This need not be a lot of work. It could just be re-ordering so that the most relevant skills and experiences feature more prominently.

How to Connect with Your Interviewer through Thinking

Of course it’s not all about stories. The tech skills are crucial. But the technical evaluations are not just a chance to demonstrate tech skills. They’re also a chance to relate personally.

Don’t treat the tech parts as simply a test of knowledge. They should be tests of reasoning.

Take every opportunity to reveal your thinking. Say why you chose one approach rather than another. Say what you like about a technology and what you’ve found awkward.

It is usually ok to not know an answer. Share your thoughts and be interested in how to get to the right answer, if there is one.

Expect to be challenged on exactly how far your knowledge and experience goes. Maybe you don’t have experience using technology X for millions of transactions. Acknowledge that. Talk about what scale you have dealt with and how you would scale higher.

Sometimes you’ll get ‘gotcha’ questions. Questions where the interviewer really wants some obscure piece of knowledge you don’t have. Try to turn them into conversations.

You want to show that you are flexible and that you’re someone the interviewer could work with. That involves being humble about what you don’t know. Try to show that you could go on learning journeys together.

You should be prepared to be challenged with coding exercises. Look up what you can about how the company hires. It’s ok to ask them what to expect in the process.

How to Achieve your Goals

“We do not learn from experience… we learn from reflecting on experience.” - John Dewey, Philosopher

Interview prep takes time. Getting your stories prepared has to compete for time with technical preparation. You’ll want to tailor this to the company.

The key point is not about what prep to do. It’s about how to approach the interview.

Making a connection maximises our chances. Even if we make mistakes in the process, the interviewer is more likely to be generous to us if they relate to our experience and thinking.

The process of thinking about what we want to emphasise is also a good growth exercise. It forces us to consider which of our skills are most marketable. And also what we most enjoy.

We’ve a better chance of landing a role if we can explain how it would fit into our personal growth story. We want to be clear what attracts us to the role and how we’d grow with it.

The interviewer will likely ask us why we’re interested in the role. We should have a compelling answer, both for the interviewer and for ourselves.

Interviews are the Wild West

Candidates tend to assume interviewers have everything together. We assume that it’s a great company with a great interview process. So obviously if the interview goes badly it must be our fault?

Even in great companies you get messy hiring situations.

There may be multiple people in the hiring process and they may disagree on what they want. You may get one interviewer open to more junior candidates with an aptitude to learn. And another interviewer who wants all the relevant skills right away.

The interviewer should be trying to have a conversation with you. They should be trying to see how you approach problems and whether you’re somebody they could work with.

Unfortunately the interviewer might not be looking for conversation. They may be rushed or having a bad day. They may have limited thinking space.

Rarely is anyone trained in interviewing. Some people seem strangely ok with making interviews an exercise in ticking boxes. Or a kind of chess game to find faults.

The most common weakness in interviewers is being under-prepared and rushed. This leads to a passive approach to interviewing where the interviewer basically sits back and waits for you to impress them.

Tell stories about good work that you’re proud of. Stories about overcoming obstacles and making trade-offs. Try to relate the stories to what you know about the role. Where you’re not sure how your experience relates to the role, drop in the odd question to show how interested you are.

How to Succeed in the Wild West of Software Interviews

Think about what the interviewer is looking for. Which skills are must-haves and how much experience they want. Even ask them.

Have stories prepared and think about how to relate them to the role. Use your CV so that it prompts the questions you want. Stories aren’t the whole interview process but they are typically the centrepiece.

Have questions prepared to show how interested you are. Really try to imagine what you’d be doing day to day.

Think about how relatable each of your stories are. Make sure you tell them in a way that doesn’t require too much insider language or context.

The way to succeed in the Wild West of interviews is not to be an awesome gunslinger. It’s by being awesome at making new friends.

In my last article, I shared my thoughts on how to prepare for a software developer interview.

In this article, I am going to switch gears a bit and talk about common patterns you can use to solve problems in technical interviews. We'll discuss the frequency counter pattern in depth to help you tackle it effectively.

What is the “Frequency Counter” pattern?

The Frequency Counter pattern uses an object or set to collect values and the frequency of those values.

This pattern is often used with an array or a string, and allows you to avoid nested loops (quadratic time complexity O(n²)).

When should I use the Frequency Counter pattern?

The Frequency Counter pattern is most helpful when you have multiple pieces of data that you want to compare with one another. Let me walk you through an example to see the Frequency Counter in action.

The "sameSquared" exercise

• Write a function called sameSquared which accepts two arrays
• The function should return true if every value in the first array has its corresponding value squared in the second array
• The frequency of the values must be the same

What is the optimal outcome?

After our function is written, we should expect our sameSquared function to return these values.

sameSquared([1, 2, 3], [4, 1, 9]); _// true_

sameSquared([1, 2, 3], [1, 9]); _// false_

sameSquared([1, 2, 1], [4, 4, 1]); _// false_

sameSquared([2, 3, 6, 8, 8], [64, 36, 4, 9, 64]); _// true_

Getting started

First, using the function keyword, we create a function with the identifier sameSquared:

function sameSquared() {

Our function sameSquared needs two parameters, a first array and a second array. In this example, we are passing these values [1, 2, 3] and [4, 1, 9].

function sameSquared(firstArr, secondArr) {

Check edge cases

Inside of our function block, we want to address a few edge cases. First, we need to check that both parameters have truthy values, that is not null, undefined, and so on.

We can check for a falsy value by using the ! operator. If firstArr or secondArr is falsy, we return false.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;

The next edge case we want to account for is to ensure that the length of both arrays are the same. If they are different, we know that they can not contain an equal amount of shared values.

By checking the length property on both parameters, we can determine if they are the same. If they are not, we return false.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

Build a "dictionary" to avoid nested loops

We need to keep track of all values in at least one of the arrays. To do this, and to avoid a nested loop, we can store these values in a hash table (object). I’ll call mine lookup.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};

Using a for of loop, we iterate through the firstArr. Inside of the for of block, we assign the key to the result of value * value.

The value in this key/value pair will be a frequency counter that reflects how many times a specific value is “seen” in the firstArr.

First, we check if lookup contains an entry for value * value, if it does, we add 1 to it. If it does not, we assign the value to 0 and then add 1.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};

  for (value of firstArr) {
    lookup[value * value] = (lookup[value * value] || 0) + 1;
  }

Once the firstArr is finished looping, the lookup should contain these values:

{
  1: 1,
  4: 1,
  9: 1
}

Compare array values

Now that we have iterated through all of the values in the firstArr and stored them as their respective squared value, we want to compare those values to the values in the secondArr.

We start by creating another for of loop. On the first line inside of our new for of block, we write a conditional statement to check if the current value from our secondArr is not inside of our lookup. If it is not, we stop looping and return false.

If the value from the secondArr is in our lookup, we want to decrement the value of that entry. We can do so by using the -= assignment operator.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};
  for (value of firstArr) {
    lookup[value * value] = (lookup[value * value] || 0) + 1;
  }
  for (secondValue of secondArr) {
    if (!lookup[secondValue]) return false;
      lookup[secondValue] -= 1;
    }

After we are finished looping through the secondArr, our lookup should have these values:

{
  1: 0,
  4: 0,
  9: 0
}

Wrapping up our "sameSquared" function

If we finish iterating through the secondArr without returning false, that means that our firstArr contains all values that are in a squared state in the secondArr. Therefore, we return true outside of for of loop.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};
  for (value of firstArr) {
    lookup[value * value] = (lookup[value * value] || 0) + 1;
  }
  for (secondValue of secondArr) {
    if (!lookup[secondValue]) return false;
    lookup[secondValue] -= 1;
  }
  return true;
}

Let me show you another example which is used very commonly in coding assessments (so you might’ve seen this problem before).

The "isAnagram" exercise

• Write a function called isAnagram which accepts two strings
• The function should return true if the two strings parameters are anagrams of each other

What is the optimal outcome?

After our function is written, we should expect our isAnagram function to return these values.

isAnagram(“silent”, “listen”); _// true_

isAnagram(“martin”, “nitram”); _// true_

isAnagram(“cat”, “tag”); _// false_

isAnagram(“rat”, “tar”); _// true_

Getting started

First, using the function keyword, we create a function with the identifier isAnagram:

function isAnagram() {

Our function isAnagram needs two parameters, a first string and a second string. In this example, we are passing these value, silent and listen.

function isAnagram(firstStr, secondStr) {

Check edge cases

On the first few lines of our function block, we want to address a few edge cases, just like in the first example.

Similar to isAnagram, we need to check that both parameters have truthy values, that is not null, undefined, and so on. We can check for a falsy value by using the ! operator. If firstStr or secondStr is falsy, we return false.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;

The next edge case we want to account for is to ensure that the length of both arrays are the same. If they are different, we know that they can not contain an equal number of shared values.

By checking the length property on both parameters, we can determine if they are the same. If they are not, we return false

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

Build a "dictionary" to avoid nested loops

Remember, we are using the frequency counter pattern and we need to keep track of all values in at least one of the arrays. Now we know that the best way to handle this is to store these values in a hash table (object). To keep things consistent, I’ll call mine lookup again.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

  const lookup = {};

Using a for of loop, we iterate through the firstStr. Inside of the for of block, we assign the key to the result of the expression value * value.

The value in this key/value pair will be a frequency counter that reflects how many times a specific value is “seen” in the firstStr.

Using a ternary operator, we check if lookup contains an entry for value * value, if it does, we use the += assignment operator to increment the value by 1. If it does not, we simply assign the value to 1.

function isAnagram(firstStr, secondStr) {
    if (!firstStr || !secondStr) return false;
    if (firstStr.length !== secondStr.length) return false;

    const lookup = {};

    for (first of firstStr) {

        lookup[first] ? (lookup[first] += 1) : (lookup[first] = 1);

  }

Once the firstStr is finished looping, the lookup should contain these values:

{
  s: 1,
  i: 1,
  l: 1,
  e: 1,
  n: 1,
  t: 1
}

Compare array values

Now that we have iterated through all of the values in the firstStr and stored their values, we want to compare those values to the values in the secondStr.

We start by creating another for of loop. On the first line inside of our new for of block, we write a conditional statement to check if the current value from our secondStr is not inside of our lookup. If it is not, we want to stop iteration and return false.

Otherwise, if the value from the secondStr is in our lookup, we want to decrement the value of that entry. We can do so by using the -= assignment operator.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

  const lookup = {};

  for (first of firstStr) {
    lookup[first] ? (lookup[first] += 1) : (lookup[first] = 1);
  }

  for (second of secondStr) {
    if (!lookup[second]) return false;
    lookup[second] -= 1;
  }

After we are finished looping through the secondStr, our lookup should have these values:

{
  s: 0,
  i: 0,
  l: 0,
  e: 0,
  n: 0,
  t: 0
}

Wrapping up our "isAnagram" function

If we finish iterating through the secondStr without returning false, that means that our firstStr contains all values that are in the secondStr. Therefore, we return true outside of for of loop.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

  const lookup = {};

  for (first of firstStr) {
    lookup[first] ? (lookup[first] += 1) : (lookup[first] = 1);
  }

  for (second of secondStr) {
    if (!lookup[second]) return false;
    lookup[second] -= 1;
  }
  return true;
}

In Summary

I hope this in-depth overview of the Frequency Counter pattern was helpful. Now that you know how the pattern works, I am confident that you will be able to impress your interviewer by showcasing your skills at an even higher level.

In my next article, I will be discussing another common problem-solving pattern called the Sliding Window. Thanks for reading, and happy interviewing!