And you’re wondering (rightly so), how to get in on the act? You're asking yourself, "how can I position myself to take advantage of this ‘tech’ thing? How can I get my own share of the insane dollars flying around in tech? How do I start my tech career?"

If these are some of the questions you have been asking, then no worries my friend, because I have some answers for you. The one thing I ask of you is that you stay open-minded and inquisitive while reading this article.

Ready to dive in?

Let’s start with what tech is. Really, what is tech?

What tech is

First off, the word tech is a less mouthful, mono-syllabic abbreviation for the word technology.

See? Easy peasy, can we all go home now? Well, not yet, because we haven’t talked about what technology is.

A quick Google search will show you tons of definitions of what technology is and here is one:

Technology is simply science or knowledge put into practical use to solve problems or invent useful tools.

Wikipedia has a more interesting definition:

Technology is the sum of any techniques, skills, methods, and processes used in the production of goods or services or in the accomplishment of objectives.

Keep these definitions in mind because I will make a reference to them later on in this article.

What tech isn’t

I just shared a simple but effective explanation of what technology is and you might be wondering, “why do I need to know what technology is not since I already know what it is?”.

I like that you are asking that - we promised to stay inquisitive and you are coming through! So, I’ll tell you why with a short story.

Several blind men encountered an elephant. The blind man who touched the trunk, said it felt like a snake. The blind man who touched one of the legs of the elephant said it was a tree. Are you already getting the picture?

Source: https://www.mdhadallas.org/blog/the-blind-men-and-the-elephant-how-an-ancient-parable-explains-the-need-for-shared-data/

So if you happened to meet the blind man who touched the legs of the elephant and asked him what the elephant was, he would describe it as a tree. Similarly the one who touched the trunk, would describe the elephant as a snake, a big snake.

Why am I saying all this?

It is in our human nature to overemphasize certain parts of a thing that we have experienced oftentimes at the expense of the other parts, that we haven’t experienced or do not know about.

A popular misconception flying around these days is that tech is coding. Did I hear you ask, what is coding? Thanks again for staying inquisitive.

Coding is essentially a conversation between a programmer (often a human being) and a computer asking the computer to carry out some certain tasks.

If you need someone to help you with a task, you would tell the person the details of the task and ask the person in a language the person understands. Coding is really no different from that.

Now we know what coding is about, here is what I want to say:

Coding is Tech but Tech Isn’t Only Coding

Read that again and understand it very well.

While coding is essentially the part where the computer is instructed to do certain things, tech is so much more than just coding. It is the sum of any techniques, skills, methods, and processes (remember the definition from Wikipedia) to produce a good or a service.

Essentially, tech is:

• Techniques
• Skills (coding being just one of them, but there are others)
• Methods
• Processes

So when you say you want to get started in tech, it doesn’t always mean that you have to learn coding (I’ll be happy if you decide to because I’m a coder myself).

You can find your path by gaining mastery and knowledge of any of the other techniques, skills, methods and processes required in tech.

So how do I find my path?

I know you have questions but first, let’s take a moment to acknowledge that you have already made some progress just by reading this article and your journey into tech has started.

Now you know what tech is and what it isn’t, a recommended next step would be knowing what paths to follow in tech because like I mentioned earlier, tech is vast and I believe everyone who’s genuinely interested can find their place in it.

It’s okay to roll your eyes at me because I’m about to go all motivational on you. 😄

I recently co-hosted a Twitter Space (remove link because no recording) where I talked about the different non-coding career paths for people looking to get started in tech. In that talk, I shared some tips, which I’ll share now, that can help you determine what career path you should follow.

One thing to note here is that these are not absolutes, they are guides. So here are the tips:

• Choose a path that aligns with your core strengths: If you find yourself drawn to abstract concepts, there's a chance you might be excel better in coding and other related career paths. If you have a thing for art and design, maybe being a User Interface/User Experience designer might be a good fit.

• Choose a path that you are passionate about and very interested in: If you are looking to build a career that will last, it is germane you choose a path that you are interested in, because that will help keep you going when the hurdles come because they will. And I just want to add that if all you’re interested in is the money, that’s okay too so long as you find fulfillment in that.

• Choose a path that leverages your previous experience: This might be more helpful for people looking to make a transition from a non-tech career into tech. Again these aren’t absolutes, but I’ve seen them work for other people and it just makes the transition easier.

With that said, let me now share some different career paths in tech.

Career Paths in Tech

This is by no means an exhaustive list of career paths in tech but I believe it is decent enough to serve as a guide to helping you make a decision.

I would have loved to talk a bit more about each of these paths but that would make this article too long; so instead I added links to each of the paths listed here so you can read more about them if you are interested - remember we said interest is key to helping you find your path.

Coding-Related Paths

Here are paths in tech that will have you holding conversations with a computer:

• Back-end Development: It involves building the behind-the-scenes services that power web/mobile applications.

• Blockchain: is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a business network.

• Cybersecurity: It describes the practice of protecting computers and critical systems from malicious attacks.

• Data Engineering: This focuses on using scientific methods and systems to extract insights from data.

• Data Science: This entails building the pipelines and systems for the storage and passage of data at scale.

• DevOps Engineering / Cloud Engineering / Infrastructure Engineering: Sometimes used interchangeably, this career path focuses on building and maintaining the pipelines and infrastructure used by applications.

• Game Development: This focuses on development of design and development of games across different platforms.

• Machine Learning / Artificial Intelligence: Machine learning (often viewed as a subset of artificial intelligence), but they both focus on creating intelligent systems that keep learning.

• Mobile Development: As a mobile developer, you will be tasked with development of applications for mobile devices

• Network Engineering: Network engineers design, build and maintain computer networks for organizations.

• Software Testing (Automated): It involves using software tools to automate a manual process of software testing.

• Web Development (Front-end): This involves developing applications to be viewed via a web browser with a focus on building the user interface of the web application.

• Web Development (Full-stack): This combines both front-end and back-end development defined above.

• Web3 Development: The hottest kid on the block, this focuses on building decentralized applications that run on either blockchain or other decentralized networks.

Non-Coding Paths

Also, here are paths in tech that won't require you having conversations directly with a computer:

• Data Analysis (some cases): This involves collecting, cleaning and interpretation of data to draw insights. This is often the entry path for people looking to go into data science.

• Data Privacy Management: This focuses on helping organizations maintain compliance with data privacy laws and regulations.

• Developer Advocacy/Developer Relations (some cases): This role focuses on building excellent relationships with developers, who mostly use a company’s products or services.

• Digital Marketing: Sometimes referred to as online marketing, it entails the promotion of goods and services using the internet and other forms of digital channels. Think of it as marketing powered by tech.

• Product Management: This career path focuses on planning, creating, managing and launching products and services within an organization.

• Project Management: It describes the use of specific knowledge, skills, tools and techniques to ensure delivery of something of value to people.

• Search Engine Optimization / Search Engine Marketing: Often used together, they both describe a form of internet marketing that involves the promotion of websites by increasing their visibility in search engines.

• Software Testing (Manual): In contrast with automated testing, this describes a manual process of testing software without the use of automated tools.

• Tech Community Management: This career path focuses on building, managing and growing tech communities.

• Tech Law / Intellectual Property Law: The body of law that governs the use of technology, with IP law being one of the hottest paths. So you can think of this as law but with focus on tech.

• Tech Recruiting: This comprises sourcing, screening, and assessing candidates who fit specific technical roles

• Technical Writing: Technical writers are professional communicators who seek to transfer technical knowledge to their audience through writing.

• User Experience Design: This focuses on creating products that provide meaningful and relevant experiences to users.

• User Experience Research: A UX researcher studies would-be users of a product, to understand their requirements and add these insights into the design of the product.

• User Interface Design: While a UX designer focuses on experience, a UI designer designs interfaces for applications with focus on look and style.

I tried to not overload you with a lot of information, believe me I did. One thing you should see however, is that there are a good number of career paths that don't require coding, if you believe coding is not your thing (I'll be curious to know why though).

Next Steps

By reading to this point, I assume that you have found a path you want to follow. Now it's time to take concrete steps to follow that path.

Here are some recommended next steps:

Research more on your chosen path

I highly recommend that you do some good research about the path you have chosen. Researching more about your chosen path will give you a better understanding of what the path entails but more importantly, it will paint to you a clear picture of the gulf between where you are and where you want to be - that should be the goal.

Like I mentioned earlier, I have added links to the different career paths. These links are a good first place to begin your research, but you should go beyond just reading the articles I've shared. I highly recommend speaking to someone who's an expert in your chosen field. If this is something you are interested in, you can complete this form where we will try to match you with someone who is an expert in your field of interest.

Develop a learning plan

So you have researched your chosen tech career path, you are very excited and you can't wait to get started. I'm not here to dampen that excitement because I'm also excited for you, but I want to highlight the importance of developing a learning plan.

A learning plan essentially is your system for getting you from where you are to where you want to be (which ties into the output of the research step).

Another thing a learning plan will help you do is to keep you going on those days when the excitement seems to have faded because there's a high chance that those days will come.

For easy reference, here's a sample of what my learning plan looked like at the time I wanted to learn about a certain technology - Docker:

• Read a new article on Docker every week (LEARN)
• Spend 1 hour every day writing Docker commands (DO)
• Talk to someone who is a Cloud/Infrastructure Engineer (CONNECT)

The last thing I want to mention here is that your learning plan is a living document, so you should keep updating it as you get more information.

Just start

As Nike says, "just do it".

Once you've developed a learning plan, just start. Starting might mean enrolling in a course or joining a community of other learners but hey, just start.

And don't worry if you feel dumb at the onset, all masters were once dumb when they started and here's a quote I find very interesting:

"Embarrassment is the cost of entry. If you aren't willing to look like a foolish beginner, you'll never become a graceful master".

Need I say more?

Set measurable goals to track your progress

Yes, you're going to learn but you also need to set goals (think of them as milestones) to track your progress.

I recommend breaking down your goals into items so that you can act on them every day, rather than waiting till the end of the month or year to achieve your goal.

Here are some examples of measurable goals:

• Complete a course module every day.
• Publish an article about what you have learned every week.
• Contribute to an open-source project every month.

Get an accountability partner

Life is better done with another person so on this journey, I'll recommend finding someone to keep you accountable. This can be a friend, a mentor - preferably a buddy, or even a community.

Whatever you choose should be based on your preferences and what works best for you. Don't be caught doing something because everyone else is doing it, it should work for you.

If after reading through this article, you are still unsure of what path you want to follow - that's absolutely fine. I'm happy to schedule a one-on-one chat with you, you can use this link or send me a DM on Twitter.

Some final words

As we conclude, let me share a personal story.

I went scuba-diving for the first time last year and one of the things I was told in preparation for that adventure was that scuba-diving was a lot easier if one knew how to swim. But more importantly, to enjoy scuba-diving, I had to wear the right kit to enable me to breathe more easily so I could navigate the beautiful ocean depths.

With the loads of information out there about tech, I hope with this article, I have given you all the courage, motivation and most importantly, the right knowledge (kit) you need before you go scuba-diving into the vastness that tech is.

I'm super excited that you have considered getting into tech because there are a ton of problems that we can solve in our world today. I could go on and on writing this article but I would rather pause here and have you channel your energy into taking the next steps as soon as possible.

So here's me, your number one fan rooting for you. I wish you all the best in your career.

You've got this!

In my next article, I'll be recommending some free resources - courses, articles and more, to help you get started in selected tech career paths. Please let me know which ones you are interested in the comment section so I can include them in the article.

Will you immediately dive into solving the problem or will you zone out as you try to think through the problem?

More often that not, a lot of people immediately go straight into trying to solve the problem. Some others will zone out in a bid to think through the problem while the good software engineers start by asking questions in a bid to understand the problem better because they know and understand the importance of asking the right questions and the role it plays in helping to develop the most optimal solution to a given problem.

You are a good software engineer, and that's why you are reading this article.

And so in this article, I will highlight 4 important questions that good software engineers ask during technical interviews. Using this knowledge, we will then see how this technique was/was not applied by the 30+ folks who took on the algorithm challenge for Week 4 of Algorithm Fridays.

It is important to note that these questions are not just suited for technical interview scenarios. Since technical interviews are mostly around solving problems, the lessons learned here can be applied to any problem-solving situation, which happens even while on the job.

So let's get started.

Conversation over Correctness

If you were asked what the main value in a technical interview is, would you say the value is in being able to solve the problem you are given or would you say the value is in the conversation that happens between you and your interviewer.

Which would you pick?

One of the things I learned from doing 60+ technical interviews in 30 days is that the real value in technical interviews is not the correctness of your solution or your ability to come up with a solution, it's the conversation that happens during those interviews.

Did I hear you say "wait, what?"

I know what you just read may seem counter-intuitive at a first glance but think about it.

I should however mention that by technical interviews, I am not referring to the 45-minute coding challenges, from Hackerrank or the likes. I'm referring to interviews where you engage with another person while solving a technical problem.

For those kind of interviews, yes the conversation that happens between you and the interviewer is more valuable than just solving the problem.

One reason for this is because more often than not, when a technical problem is presented to you, there might be some assumptions that you may have made about the problem. So, it is important to ask questions to validate or invalidate your assumptions before jumping right in to solve the problems.

Not doing so could prove costly in terms of time and effort as was the case during one of my interviews where I had assumed the input type, and had developed a solution only to find out later that it was a different type. Needless to say that my assumption cost me the interview because the amount of time I had spent in trying to develop the initial solution was gone.

Another thing to note is that, when you ask the right questions, you are indicating to your interviewer that not only do you recognize the need to clarify the problem statement, you also are a team-player.

Here's an excerpt from the article I wrote on the lessons I learned from doing 60+ technical interviews in 30 days:

Yes, your interviewer wants to see that you can come up with a solution, but one thing you must not forget is that they also want to see that you can collaborate with other team-mates to come up with a solution. While companies want rock-stars, they also want team-players.

I hope that by now you are already beginning to see the value in asking questions. I also imagine that you are already asking, what are some of the questions you could ask. That's exactly what I'll be sharing in the next section.

Walk with me. 🚶🏽‍♂️

Questions to Ask Your Interviewer

Good software engineers understand that part of developing a solution to a problem is testing every assumption you have made about the problem.

So here are examples of questions that good software engineers ask:

1. Questions about the input data

Good software engineers ask clarifying questions about the data to be processed. For example, if you are asked to write a function that transforms some input, you should ask the following questions:

• What is the data type?

  • Is it a string, a number, an object?
  • If it is an array for example, can the array be empty? Can the array contain different types of elements? For example in JavaScript, can you have a string and a number in the array?

• What is the data size?

  • How big is the input data that we are processing?
  • For example, if it is a number, how big can the number be? This is very important to know because some operations can't be carried due to overflow errors if the number is very big.

2. Questions about robustness

As a good software engineer, your aim should be to develop a system that is robust, can handle unexpected/invalid input without failing.

Some questions to ask include:

• Can the input data we are processing have some unexpected values like null or could they be undefined?
• How should we handle runtime errors? It is important to always check in with the interviewer to note how he/she wants you to handle the errors so that you don't spend a lot of time on it. For most interviews I've had, it was mostly enough to just talk about how you will handle the errors; the interviewer rarely asked me to code it up. However in some other ones, the interviewer wanted to see how I would make my solution more robust.

3. Questions about implementation & trade-offs

Good software engineers know that every solution comes with a cost and there are always trade-offs. If you design an algorithm using arrays instead of hash maps, there is a cost to it. It is important that you understand these and its trade-offs so you can ask questions around this.

This category of questions is mostly important for system design interview questions.

Here are some sample questions to ask:

• Is there a reason why one implementation method is preferred over another? For example, recursion over iteration? This may give you deeper insight about the problem.
• Is there a data structure you would prefer? One reason to ask this question could be to demonstrate your knowledge of different data structures that could be used for solving a problem.
• Is there an acceptable performance threshold? This is a really important question because while we can hope for the most-optimal and perfect systems, it is rarely possible in practice. So it is important to clarify what is tolerable for the solution you are designing. For example, if it is okay to develop a O(N log N) solution, or can we build a system with a 5% latency? This would help you decide on what implementation methods to use in developing the solution.

4. Questions about scale

Not all interviewers may need you to implement scalable solutions but most certainly, all interviewers will be impressed when you ask questions about scale.

These set of questions basically focus on clarifying how your system should behave when the amount of data to be processed as input increases significantly, or if your system

Examples of some questions to ask include:

• Do we expect that the input can increase significantly? For example if you had a in-memory solution that worked for processing 100 entries, you may want to rethink that if you are processing a billion entries.

Having gone through some of these questions, let's look at how we can apply this to an algorithm problem that was posed to participants in Week 4 of Algorithm Fridays.

Sample Application

The image below shows the algorithm problem for Week 4 of Algorithm Fridays.

Applying what we have learned, what are some of the questions we could ask about this problem? Anybody?

1. What is the expected input type? That's answered already in the question - an array.
2. Can the array contain different types? Again, that's answered already in the question - an integer array, so we know the array is made of numbers.
3. Can the input be null or undefined? The answer to this question is yes, because we have no control over what values are passed into the function. This tells you that your solution should be robust enough to handle unexpected/invalid input cases.
4. What kind of numbers does the array contain?

This last question is really important because if you assumed that the input array was made of positive numbers only, you would come up with a solution like this:

const productExceptSelf = (nums = []) => {
  if (!nums || nums.length == 0) return []

  // Step 1: Find the product of all the numbers first
 const product = nums.reduce((acc, num) => {
    return acc * num
  }, 1);

  // Step 2: Loop through each entry in the array and divide the product by the entry
  nums.forEach((num, index) => {
     nums[index] = product / num;
  });

  return nums;
}

The problem with this solution is that when you have an input array where one of the elements has a value of 0, for example nums = [4, 3, 0], this solution fails.

Can you see the reason why?

If one of the entries of the array is 0, the product of all the of all the numbers of in the array will be 0, leading to the result (in JavaScript) shown below:

productExceptSelf ([4, 3, 0]); ❌ // should return [0, 0, 12] but returns [0, 0, NaN]

Now we know we should handle the edge case for when one of the elements is 0, but before we rewrite our solution to handle the zero check, let's think about the problem a bit more deeply.

What if our array has more than one element whose value is 0, will that affect the final solution we come up with?

Yes, because if we have an array with at least two elements with a 0 value, the final result should be an array whose elements are all 0. How? Let's look at the image below:

The image shows us for each position i in the result array, the product of all other numbers except nums[i] will always be 0. So we can deduce that when there are at least two elements in nums with a 0 value, every element in the final results array will be 0, thus eliminating unnecessary work.

Taking into account all of these, we can come up with the final solution shown below:

const productExceptSelf = (nums) => {

   if (!nums || nums.length == 0) return [];

   let countOfZero = 0; // track the number of zero elements

  // Step 1: Find the product of all the numbers except zero
   const product = nums.reduce((acc, num) => {
      if (num === 0) {
          countOfZero++;
          return acc; // Skip multiplying if the element is 0
      }
      return acc * num
    }, 1);

    if (countOfZero > 1) {
      // Every element in the result array will be 0
      nums.forEach((num, index) => {
           nums[index] = 0;
      });
      return nums;
    }

    // Step 2: Loop through each element in the array and
   // populate the results array based on the value of the element
    nums.forEach((num, index) => {
      if (countOfZero === 1) {
          if (num === 0) {
            nums[index] = product;
        }
        else {
            nums[index] = 0;
        }
      }
      else {
          // There are no elements with a 0 value in the array
        nums[index] = product / num;
      }
    });

    return nums;
}

// Test case 1: When the array has no elements with a 0 value
console.log(productExceptSelf([4, 3, 2])); // ✔️ returns [6, 8, 12]

// Test case 2: When the array has only one element with a 0 value
console.log(productExceptSelf([4, 3, 0])); // ✔️ returns [0, 0, 12]

// Test case 3: When the array has only one element with a 0 value
console.log(productExceptSelf([4, 3, 0, 0])); // ✔️ returns [0, 0, 0, 0]
}

Winners of the $20 award

After reviewing almost solutions in 5 different programming languages, the $20 award for Week 4 of Algorithm Fridays goes to @Flappizy and @thisaliaba, and you can find their solutions here and here respectively.

We picked these solutions because apart from being correct and robust, they used a very intelligent approach in solving the problem. Also, the solutions are time and memory-efficient and passed the edge case of when one of the elements of the input array had a 0 value.

A special mention for @abiolaEsther_ who implemented a correct time-efficient O(N) solution and @toritsejuFO who implemented a correct O(N ^ 2) solution in Python using the lambda function.

Thank you once again, to everyone who participated.

Conclusion

I hope reading this article has made you see the importance of asking clarifying questions when developing a solution and also given you examples of the kinds of questions to ask.

Though these questions are by no means an exhaustive list of the kinds of questions you should ask, they show you an example of the things you should be thinking about when you are developing a solution to a problem, whether during a technical interview or in a problem-solving session at your job.

If you are looking for a risk-free, low-stakes opportunity to apply what you learned in this article, you should consider giving Algorithm Fridays a try. You'll love it.

Thanks for reading this article and see you later today for Week 5 of Algorithm Fridays. Have any questions, feedback or concerns? Please share it in the comment section below.

E go be!

Or, you can decide to arrange them based on their heights; in this case, you would likely bring the shorter students to the front of the line and the taller students to the back of the line.

Both of these methods define some way of arranging the students based on some property. This process is called sorting.

In this article, I will start with a brief introduction about sorting and then highlight briefly the different sorting algorithms and their performance. Then, I will apply that knowledge to the algorithm problem we solved for Week 3 of Algorithm Fridays and in doing so, we will see if using the sort function was the most optimal solution for the problem.

Let's begin with a brief introduction of sorting.

What is sorting?

Sorting is the process of arranging data in a particular format based on some attribute, for easier data retrieval.

That's all? Yes that is all.

Using the example of the class students, ordering those students whether by their names or heights is sorting.

Sorting algorithms define the step-by-step approach that describes how the data is sorted. Like with most other algorithms, sorting algorithms help make data more analyzable or easily retrievable.

Now that we know what sorting is and what sorting algorithms are, let's take a look at the different sorting algorithms that are available.

The Different Sorting algorithms

There are different sorting algorithms and I want to share this non-exhaustive list of sorting algorithms.

• Insertion sort algorithm
• Bubble sort algorithm
• Quick sort algorithm
• Merge sort algorithm
• Heap sort algorithm
• Radix sort algorithm
• Counting sort algorithm

Runtime complexity of sorting algorithms

The table below shows the runtime complexity of the different sorting algorithms using Big O notation :

One important thing to note from here is that the most optimal sorting algorithms have a O(N log N ) runtime complexity.

How do we apply this knowledge in developing a solution to the algorithm problem?

Algorithm Problem

Given the knowledge that we have now of the different kinds of sorting algorithms and their time complexity, let's look at the algorithm problem that more than 20 participants worked on for Week 3 of Algorithm Fridays:

How sorting helps us solve the problem

Looking at the problem definition, a possible first instinct would be to sort the array and then find the first and last occurrences of val in the array.

Here's what that solution (without taking care of edge cases) would look like in JavaScript:

const findFirstAndLastPositionOfVal = (nums, val) => {
    const sortedNums = nums.sort(); // This makes this function O(N log N)
    const start = nums.indexOf(val);
    const end = nums.lastIndexOf(val);
    return [start, end];
}

However, knowing that sorting algorithms have a O(N log N) time complexity, the question we should be asking is "there a way we can solve the problem faster by doing less work?"

Do we really need to sort?

As software engineers developing solutions, it is our place to re-interpret and re-define product requirements to allow us develop the most optimal solutions.

Let's think a bit more about the problem. Why are we sorting the array?

Sorting helps arrange the numbers in increasing order, as that will help us find the positions of val more intuitively.

For instance, if arr = [-2, 3, 0, 7, 11, 3, 3, -19, ] and val = 3, the image below shows us that the array would give us arr = [-19, -2, 0, 3, 3, 3, 7, 11] and we can easily identify the start and end positions of val = 3 being [ 3, 5]

The position of elements in the sorted array

But do we really need to sort the array to solve this?

Since the goal of sorting is to help order the numbers so that all numbers less than val are placed in front of val, is it possible that we can achieve the same result without doing the 'work' of sorting - again remembering that we want to do the most with the least resources?

What if we focused on finding the numbers that are less than val since we are sure that those numbers would be placed in front of val if we sorted the array? Armed with that information and the number of occurrences of val in the array, we could find the start and end positions of val.

The illustration below will help explain this better:

The solution in JavaScript is shown below:

const findStartAndPositionOfVal = (nums = [], val) => {
    if (typeof val !== 'number') throw new Error('Invalid input');

    if (!Array.isArray(nums) || nums.length == 0) return [-1, -1];

    let countOfNumsLessThanVal = 0;
    let countOfVal = 0

    nums.forEach((num) => {
      if (num < val) countOfNumsLessThanVal++;
      if (num === val) countOfVal++;
    });

    if (!countOfVal) return [-1, -1] // val is not found in array

    if (!countOfNumsLessThanVal) {
       // Edge case: val is smallest number in array
       return [0, countOfVal - 1];
    }

    const startOfVal = countOfNumsLessThanVal;
    // subtract one because of zero-based indexing
    const endOfVal = startOfVal + countOfVal - 1;

    return [startOfVal, endOfVal ] ;
}

/** Test case 1: When nums is null, should return [-1, -1] **/
console.log(findStartAndPositionOfVal (null, 5)); //✔️

/** Test case 2: When nums is an empty array, should return [-1, -1] **/
console.log(findStartAndPositionOfVal ([], 5)); // ✔️

/** Test case 3: When nums has just one occurrence of val, should return [0, 0]  **/
console.log(findStartAndPositionOfVal([0], 0)); // ✔️

/** Test case 4: When nums has multiple occurrences of val,  should return [0, 2] **/
console.log(findStartAndPositionOfVal([3, 3, 3], 3)); // ✔️

/** Test case 5: When val is the smallest number in nums, should return [0, 2] **/
console.log(findStartAndPositionOfVal([0, 8, 0, 0, 3, 12], 0)); // ✔️

/** Test case 6: When val is the biggest number in nums, should return [5, 5]  **/
console.log(findStartAndPositionOfVal([0, -8, 0, 0, 0, 3], 3)); // ✔️

/** Test case 7: When val is not the smallest nor biggest number in nums, should return [1, 4] **/
console.log(findStartAndPositionOfVal([0, -8, 0, 0, 0, 3], 0)); //  ✔️

The much improved solution has a linear, O(N) time complexity, because we only have to iterate through the items in the array just once. If you want to further optimize it, you can use the two-pointer approach I talked about last week in this article.

Winners of the $20 award

After reviewing all the solutions submitted, we have four optimal solutions for Week 3 of Algorithm Fridays.

The winners are:

• @freddthink, who was also the winner from Week 2. You can view his solution here.
• @chygoz2 and here is his solution.
• @tobi_bams, you can view his solution here.
• @deedee47 - our winner from Week 1. Her Java solution can be found here.

We picked these solutions because apart from being correct and robust, they all were able to solve the problem without having to sort the array - thus achieving a time complexity of O(N) which is better than O(N log N) caused by sorting.

Thank you to everyone who participated in Week 3 of Algorithm Fridays.

Conclusion

Sorting algorithms are powerful and best used when you want to arrange data in a specific format. However like with every other tool available to you, you should only use them when absolutely necessary because it comes with a cost.

Your goal should be to find ways to achieve the same results by doing less computation - less work.

I believe this was worth your read and I hope this challenges you to think a bit more deeply about the code you write when developing solutions.

Please feel free to share your comments or thought on this post or on the question tweet.

Thanks for reading and see you on Friday for Week 4 of Algorithm Fridays.

Have an amazing week ahead!

Further Reading

• Sorting Algorithms Explained with Examples in Python, Java, and C++
• Sorting Algorithms

This was the question that more than 25 participants tried to answer in Week 2's edition of Algorithm Fridays - a 39-week initiative aimed at promoting community learning around algorithms and problem-solving.

In this article, I will be explaining how the filter function and using that knowledge, we will see if using the filter function was the most optimal solution for the algorithm problem.

To start off, let's look at the algorithm problem that we worked on for Week 2 of Algorithm Fridays.

Algorithm Problem

The image above shows the algorithm problem for Week 2 of Algorithm Fridays.

Giving this problem a bit more thought and drawing from what we learned last week about doing less work , we can re-interpret this problem to be:

Given an array of numbers, write a function that returns the number of elements in the array nums whose value is not equal to val.

The first step to coming up with this solution will be to filter out those numbers in the array whose values are different from val.

What comes to mind when you think of this? That's right - the filter function!

What is the filter function?

Given a list of elements, the filter function returns a subset of the elements in that list that pass a given condition.

For most languages, the filter function has similar signature. It accepts a callback function that tests each element of the array to see if it passes a given condition.

In JavaScript, the signature of the filter function looks something like this:

const newArray = arr.filter(callback(currentValue[, index[, array]]) {
  // return element for newArray, if currentValue passes test
}[, thisArg]);

The filter function is not only common to JavaScript, it also exists in other languages.

While Java also calls it the filter function, C# refers to it to as the Where function while PHP has something similar, called the array_filter function.

How the filter function works

Given that many of the solutions for this algorithm problem leveraged the in-built filter function, it is valuable that we look under the hood to understand how the filter function works.

One really important thing to know about the the filter function is that it creates a new array consisting of elements from the original array that match a given condition.

To test this using JavaScript, run the code snippet below:

const originalArray = [0, 1, 2, 3, 4, 5]
const filteredArray = originalArray.filter((num) => num % 2 === 0)

console.log(originalArray === filteredArray); // This would print false because they are not equal

So, a new array is returned every time the filter function is called because in line with principles of immutability - a core tenet in functional programming, the filter function doesn't mutate the original (input) array passed to it.

What does this mean for the algorithm solution?

It means that using the filter function to solve the algorithm problem creates a new array.

While correct, this is not the most memory-optimal solution. In Big O terms, the solution is O(N) where N is the number of filtered elements; elements in the array that aren't equal to the input value, val.

And since our goal is to do the most with the least amount of resources possible, the question we should be asking is, do we really need to create a new array for this problem?

This brings us to our first solution.

Solution 1 - Loop through and maintain a count of non-equal elements

Since we have re-interpreted this problem as returning the number of elements in the array whose values are not equal to val, there really isn't a need to create a new array.

One solution that avoids creating a new array would entail looping through the elements in the input array and keeping a count of all the elements whose values are not equal to the input value, val.

In JavaScript, the code (without taking care of edge cases) will be something like this:

const getCountOfNonEqualElements = (array = [], val) => {
   let count = 0;
   array.forEach((element) => {
       if (element !== val) count++;
   });
  return count;
};

In terms of time complexity, this solution is linear - O(N), because we have to iterate through each element in the array.

Awesome! This works, but can we do better?

If we think about it a bit more, the main computation in our solution is iterating through the items in the input array. Is there a way we can iterate through the array faster?

To answer this question, let's look at what our code currently does.

The concept of two pointers

The image below is a graphical illustration of what our code currently does:

We have one pointer that moves through the array, pointing to one element at a time and checking to see if that element has a value equal to val.

Okay hold on for one second. Is there a reason why we have just one pointer looping through the array? Is it possible to add another pointer to help us move through the array faster?

Can we implement this solution using two pointers? So that while one starts counting from the beginning of the array, the other counts from the end of the array? Because doing that would halve the time needed to loop through the entire array.

That's exactly what the concept of two pointers is about.

Solution 2 - Use two pointers

A second, more optimal solution, will maintain two pointers start and end that will loop through the elements of the input array.

Pointer start will start counting from the beginning of the array whileend will count from the end of the array.

Since pointer start starts from 0 and increments towards the end of the array, we have to be careful to make sure that start doesn't end up doing the same work that end is doing. So how do we keep track of that?

Looking at the illustration below, we see that start keeps moving from 0 to the end of the array while end moves from the end of the array to the start.

This tells us that as both pointers keep moving, we will get to a point where start and end will either meet (they become equal) and/or they will cross themselves.

This is the point where our loop should end because anything from here on means that either pointer will be duplicating the work the other pointer has already done and we don't want unnecessary work in our code.

The final solution in JavaScript looks something like shown below:

const getCountOfNonEqualElements = (nums=[], val) => {
    let countOfNonEqualElements = 0;

   // When nums is null or undefined or an empty array
   if (!nums || nums.length === 0) { return countOfNonEqualElements };

   let start = 0;
   let end = nums.length - 1;

   while (start <= end) {
     if (start !== end) {
        // When pointers are not equal, 
        // check for elements at nums[start] and nums[end]
        if (nums[start] !== val) {
           countOfNonValElements++;
        }
       if (nums[end] !== val) {
           countOfNonValElements++;
        }
     }
    else {
       // When pointers are equal, no need to duplicate the work 
       // because nums[start] = nums[end]
       if (nums[end] !== val) {
           countOfNonValElements++;
        }
     }
     start++; // Move start pointer forwards
     end--;   // Move end pointer backwards
   };
   return countOfNonValElements ;
};

Winner of the $20 award

After reviewing the 24+ solutions across 4 different programming languages, the $20 award for Week 2 of Algorithm Fridays goes to @freddthink, and here is his solution.

We picked this solution because apart from being correct and robust, it is the most optimal of all the solutions with a time complexity of O(N/2).

A special mention to these solutions: @chygoz2 who implemented a clean O(N) solution with decent error-handling, @ibreathcode who coded an O(N) solution using PHP, @_darkmyke, @techgirlamaka and @tobi_bams who all added decent edge-case checks in their solutions and finally, @TobiAshiru who came up with a O(1) solution in terms of memory usage because he used modified the array in-place .

Thank you once again, to everyone who participated.

Conclusion

Even more important than knowing the in-built functions a programming language provides and when to use them, is knowing how these functions work under the hood to help you write optimal code.

I hope this was worth your read and I hope this spurs you on to read more about your programming language's in-built methods.

Please feel free to share your comments or thought on this post or on the question tweet .

Thanks for reading and see you on Friday for Week 3 of Algorithm Fridays. Have an amazing week ahead!

Hello everyone, last Friday was the first of 39 weeks of Algorithm Fridays - an initiative aimed at promoting community learning around algorithms and problem-solving.

Here is the algorithm problem that we worked on last week:

Algorithm Question

We received 20 solutions for this problem, with some really interesting solutions. Before we look the solutions, let's chat a bit about the problem.

Understanding the Problem

To solve any problem, it is important that you fully understand the problem while also ensuring that any assumptions you are making about the problem is correct.

One sure way to do that is to ask the right questions.

Asking the right questions.

To get a good understanding of the problem, it is important to ask the right questions. For this specific problem, here are some questions worth asking:

• How important is it for the solution to remove the duplicates from the array? Is it sufficient that the solution only returns the number of unique elements in the array, without needing to remove the duplicates? Because if you think about it, that's really what the problem is about. Since the expected result of the function is the number of unique elements in the array, if we can achieve that with less amount of code, the better. Answering this question strongly determines what the final solution will be.

• What is the expected input size? How many numbers will be in the input array? This question is important because the input size determines whether to use a data structure or not for the solution. Most entries that were submitted used a Set data structure; the trade-off with that is that most Sets (regardless of language) have a maximum limit of elements that it can store in memory.

• What order is the array sorted in? Ascending or descending? Whatever solution we come up with should work regardless of whether the array is sorted in an ascending or a descending order.

Thinking about edge cases

As software engineers, you always want to avoid the mistake of writing code that only works for the happy-path. Your solution should be as robust as is possible and should be able to handle edge cases.

Some edge cases to think about are:

• What should the expected result be if the input is an empty array?
• What should the expected result be if the input is null or undefined?

Solving the Problem

Given that there are two ways we can interpret this problem, there are possibly two solutions:

Solution 1: Removing the duplicates in the array

If we make the focus of the problem to be about removing the duplicates in the array, then one solution would be to use a new data structure to store only the unique elements in this data structure. Most of the solutions submitted used a Set data structure because the set ensures uniqueness.

One interesting memory-optimal implementation of this was by @tobiashiru who did this in-place without having to create a new array. You can view his solution here.

Solution 2: Counting the number of unique elements

If we think of this problem as finding the number of unique elements in the array, then our solution focuses on counting the unique number of elements.

The question now is how do we count the number of unique elements?

Our Solution

For a most optimal solution, we elected to go with interpreting the problem as counting the number of unique elements in the input array.

Since the elements are sorted in the array, our solution focuses on counting the number of unique elements by looping through every element in the array and keeping count of the number of times where we encounter a unique number for the first time.

But the next question is: "how do we know when we encounter a unique number for the first time?"

There are two scenarios where we possibly encounter a number for the first time:

• The first element in the array
• Whenever there is a change in the value of the element as we loop through the array.

The image below shows the times we encounter a unique number for the first time.

Below is the coded solution in JavaScript using JavaScript's reduce method:

This solution is most memory-optimal because it doesn't use any extra data structure and is linear - O(N), in terms of time efficiency: linear because we have to loop through every element in the array.

Winner of the $20 award

After reviewing the many different solutions and most of which were correct, the $20 award for Week 1 of Algorithm Fridays goes to DeeGenius47, and here is her solution.

We picked this solution because apart from being correct (passed the test cases), it is readable and it is robust - it took care of the edge cases - especially the edge case where the input has a null value, which a lot of the other solutions overlooked.

We also thought to give a special mention to these people: @nxbstxck who added all the different test cases in his solution, @franklin_ezeji whose solution was memory optimal as it didn't use another data structure and lastly, @daviddamilola20 and @bytedeveloper_ who both turned in one-liner solutions.

Finally, thanks to everyone who participated!

Conclusion

As software engineers, our work goes beyond just coding up a solution. Whatever solutions we develop should aim to use the least amount of resources as possible - memory, compute etc.

Equally important as developing a solution is understanding exactly what problem we are solving for and more often that not, this entails asking questions about product requirements in a bid to find the most optimal solution.

I hope this was worth your read and you were able to extract some problem-solving principles that can be applied to other problems even in your day-to-day job. Please feel free to share your comments or thought on this post or on the question tweet.

Thanks for reading and until we meet again this Friday for Week 2's challenge, keep doing more with less resources!

A couple of questions before we get started:

• What is the first thing that comes to your mind when you hear of the word algorithms?
• What is the predominant emotion? Fear? Anxiety? Excitement?

If you ask a good number of software folks today some of the things they dread most in their careers, even the really good ones too, there's a high chance technical interviewing would be mentioned - possibly next to resolving merge conflicts and writing documentation.

And there are very good reasons for that.

Many would posit that the prevalent technical interviewing process employed by many companies is flawed. Asking questions about arcane and mysterious data structures that may never be used on the job is hardly a good indication of an engineer's quality and I agree.

However, while I believe that the current technical interviewing process is flawed, I also believe that there is a lot of value in having a good grasp of some computer science fundamentals especially if you are looking to solve problems from first-principles .

In my experience, though I have rarely had to use algorithms at work, there have been a few times where my knowledge of data structures and algorithms were useful on the job and those are some of the most interesting problems I have solved.

Before we talk about what Algorithm Fridays is, it is important to define what algorithms are especially within the context of Algorithm Fridays.

What is an Algorithm?

An algorithm is a set of step-by-step instructions to solve a specific task or problem.

For example, if you are running out of groceries and you need to restock, your step-by-step approach to solving that 'problem' may look something like:

1. Determine what your budget is.
2. Draw up a list of groceries you can get with the amount from Step 1.
3. Choose the grocery store and identify how you'd get there (walking, driving, ordering online, etc).
4. Go (virtually or in person) to the grocery store.
5. Purchase the groceries.

That's your algorithm for solving the problem of grocery re-stocking.

An algorithm within the context of Algorithm Fridays will be no different in concept. It will be a step-by-step set of instructions, written in any programming language, to a specific task or problem.

So what then is Algorithm Fridays?

Algorithm Fridays is a community-focused initiative to help improve your technical problem-solving skills and reward that exercise.

How will this work?

• For 39 Fridays, starting from April 9th up until the last Friday in 2021, I will be posting some byte-sized, not-so-complex algorithm questions on my Twitter handle @meekg33k using the #AlgorithmFridays hashtag.

• You, along with other participants, will solve the algorithm problems in any of their preferred programming language. The goal here is not to test your expertise in a programming language but to improve your problem-solving skills.

• Solutions to the algorithm problems will be available the following week in a blog post here on Hashnode.

• The questions will be posted at 10.00 am PST every Friday.

What are the objectives?

The goal of Algorithm Fridays is to create value in the following ways:

• Create more awareness about algorithms and technical interviewing.
• Deepen knowledge of computer science fundamentals.
• Give participants exposure to practical algorithm problems.
• Help participants overcome the phobia of algorithms and technical interviews.
• Promote learning from one another in the community.
• Reward growth including the smallest wins.

What's in it for you?

If at the end of this program, you are more comfortable with solving algorithm problems, even if just a little, that's success for us.

In addition to the learning gains, there is a $20 appreciation award every week for one person.

How will we select the recipient of the award?

Since we mentioned that this is not a competition, the $20 award is not a prize.

That said, we will select awardees using the following metrics:

• Clean code.
• Code correctness.
• Most optimized solution.

Clean code

This includes everything from choosing proper variable and function names, writing modular and easy-to-test code, code that follows SOLID principles etc.

Code correctness

Your solution will be run against a number of test cases. It should be correct for all kinds of inputs and not fail on boundary conditions or edge cases.

Most optimized solution

The solution scales well, in terms of memory and time usage, regardless of input size. We will be using Big-O notation to measure performance.

How will participants submit their solution?

For ease of management and transparency, we ask that solutions be submitted by providing a link to a public GitHub gist via a comment on the question tweet.

What happens when there are many correct solutions?

In the event that there are many different correct solutions to a problem, we will pick awardees randomly.

While we will try to be as fair as possible, we understand that there are limitations with every random selection process and request that participants should accept that.

Who can participate?

Participation is by interest and so Algorithm Fridays is open to anybody and everybody.

Conclusion

I hope this is fun and exciting for you, because it is for us and I'm also confident you will benefit a lot from this over the next 39 Fridays.

Let's solve technical problems together.

See you on Friday!

"I know I need data structure knowledge to pass most technical interviews, but how much am I going to need it for my day-to-day job?"

My answer to them was mostly: "It depends on what kinds of problems you want to solve".

As engineers starting out get to know, there's no shortage of companies who use seemingly highfalutin computer science subject matter to vet engineering candidates, even if it's sometimes hard to draw a direct relevance from it to the specific job being interviewed for.

But in this article, I will get into a few examples where I have, in fact, put my data structure knowledge to good use on the job.

TLDR: I hope I can convince you, in the same way I try with my mock interviewees, that the knowledge of data structures is important – yes for acing that technical interview, but moreso to help you a become a better software engineer in practice.

Let’s jump right in!

Optimizing the page load time of a web application

I was involved in a project where we were building an in-memory caching layer for a micro-service that served learning content data to users via a web application.

The schema structure for the service started out with three main entities, each identifiable by an unique id, among other metadata:

• Classes
• Subjects
• Modules

The relationship between the entities was such that a Class could have one or more Subjects (1 to N relationship) and a Subject could have one or more Modules.

A simple entity-relationship diagram showing the relationship between a single Class entity and the other entities would be as shown below:

Given that there are more than one Class entities, what we would have is a forest of trees with the Class entities as the root nodes. Representing this in code using JSON format would be something like the code snippet below:

Imagine there is a request to get all the modules for a specific Class id. Given this structure, the pseudo-code for that logic would be something like:

• Iterate through the list of classes to find the Class that matches the Class id.
• Look up to find the list of subjects in the Class.
• Iterate through the subjects from step 2 and get a list of the modules in each Subject.
• Merge the list of modules for each Subject gotten from step 3 into one list.

This is an example of a request type that typically slowed down the render time of the web application. It became worse when we added Section entity to Modules and Example entity to Sections – this resulted in a tree-like data structure up to five levels deep!

If we analyze the steps in the pseudo-code above, we can see that using a list data structure for Subjects and Modules isn’t the most optimal as lists are not best suited for search operations.

To optimize this, we did the following:

• Flattened the hierarchy such that each entity was on the same level as the other. By replacing the tree-like structure with a dictionary that stored all the entities using its id as the key and the entity data as the value, we decreased the lookup time to find an entity.
• Create a dictionary of entity categories for faster category-level access.

Resulting in a data structure that looked like something below:

This optimization significantly reduced the page load time as lookup for entity metadata was a lot faster and it allowed us to easily scale by adding more entities.

Building an auto-suggest component

If you have ever performed a search for a product to buy on Amazon where as you type in a few characters you begin to see suggestions in a drop-down, then you have used an auto-suggest component.

Building that component was another interesting example for me of where the knowledge of data structures proved to be very valuable on the job.

To build this feature, we opted to use a third-party library. Using the library came with a number of benefits including but not limited to customizable options for the user interface, ease of styling, etc. However, it also meant that we were stuck with whatever the internal implementation was.

That turned out to be our bane.

This library’s implementation of the auto-suggest feature is such that it takes in a list of possible suggestions. When a user types in a character, it would perform a search by iterating through all entries in that list of suggestions to find the suggestions that are prefixed by the characters the user typed.

This worked okay for a small number of suggestions to the list, but as the number increased, we noticed a drop in performance of the component.

To solve this problem, we created a modified component that leveraged a Trie data structure constructed from the suggestion list passed to it. Each word in the list of suggestions is broken into characters, with each node in the Trie corresponding to a single character.

For example, given a list of suggestions made up of the words 'nike', 'nil', 'pea', 'eat', 'grind', 'vine', 'take', 'die', the resulting Trie data structure from the list of words is shown below:

Given this Trie data structure, when a user types the word ni, it returns the suggestions nike and nil. This is because the Trie was designed such that each node in the trie has a list of words whose prefix is made of a sequence of characters in the ancestor nodes and the character in the node.

For example, the node with character i has nike and nil in its list of words because both words have n (from the ancestor node) and i (from the current node) in its prefix.

Like with all decisions there are trade-offs.

Switching our implementation to leverage a Trie data structure came with a cost. For a suggestion list with less than 1,000 words, using a Trie seemed a bit of an overkill. So the final optimization we did was to only build the Trie data structure when the list of words was more than 1,000.

Building a queue system for a bidding service

The last instance where I remember how my knowledge of data structures proved useful in the real world was for a project to build a queuing system for a bidding application.

One of the core functionalities of the application was that users could see a list of items that were up for bidding and place bids for a specific item. Each item up for bidding had a bidding window, a time-frame within which bids should be placed.

If all the bids received for a particular item of the same amount (for example $30 as shown in the image below), the item will go to the user who placed the first bid once the bidding window elapsed.

However, if different bids of varying amounts were placed for an item during the bidding window, the item would go to the highest bidder once the window ends.

Based on the requirements, the one data structure that seemed ideal for this was the queue. The queue data structure, because of its FIFO principle, easily satisfied the requirement where the item should go to the first bidder if equal bids were received. This is because the first bid that was made during the bidding window would be at the start of the queue.

However, the system needed to take into account that for cases where different bid amounts were received for an item, at any point in time, the highest bidder should always be at the start of the queue.

Basically, it would have to sort the bids based on amount first, and then based on time of creation. These sets of requirements made the priority queue an ideal data structure for this system.

Conclusion

You may not have to use the most arcane data structures every day at your job, but having a sound knowledge of data structures is important. In short, you can think of data structures are a powerful tool in the repertoire of a software engineer to help them come to solutions faster and write cleaner, more efficient code.

So the question I'll leave you with is, "what kinds of problems are you looking to solve"?

E go be! ✌️

Further Reading

• What You Need to Know About Data Structures to be a better Software Engineer
• Data Structures & Algorithms I Used Working at Tech Companies
• Real-Time Application of Data structures

Sometime between January and March 2020, I wanted to change jobs and was looking to join a new company. This, among other reasons, led me to embark on a marathon of technical interviews – 60+ technical interviews in 30 days .

Doing that many number of interviews in such a short time meant I had an interesting mix of experiences from the various companies I interviewed with, each with their unique culture and values that often reflected in the way their interviews were conducted, intentionally or not.

In this article, I will be sharing some of the red flags I observed while I was on this marathon of technical interviews. I will not be mentioning names of any companies because that’s not the intent behind this article.

The goal of this article is also not to make you paranoid and be on the hunt for red flags in your next interview, far from it. Rather the goal is to equip you with knowledge to help you immediately identify exactly the same or similar red flags in your next interview, and hopefully identifying them will set you up to better handle them.

Even though the stories I’ll be sharing come from my marathon of technical interviews, these red flags do not apply only to technical interviews. They apply to all kinds of interviews and so there’s a lot to learn here for everyone.

The Red Flags

1. Your interviewer is only open to solving the problem ONE way

In the world of computing and in life generally, for any given problem, there is typically more than one way to solve that problem. For example, given a sorting problem, you could solve it using a merge-sort algorithm or a heap sort algorithm.

Having this rich number of techniques to solve a problem makes it even more interesting and the general expectation in technical interviews is that you should have the flexibility to solve a problem using your preferred technique.

I had an interview where the interviewer asked me to solve an algorithmic problem. I had started solving the problem using a specific technique when the interviewer stopped me in my tracks and asked that I use another technique.

When I probed a bit further to know why, it appeared that the reason he asked that I used the second wasn’t to test my knowledge of that second technique; it was because he was more ‘comfortable’ with that approach.

It is different if the interviewer wants to test your knowledge of something very specific. For example, given a problem that can be solved using iteration and recursion, the interviewer may want to test your knowledge of recursion and can ask you to solve the problem recursively. That wasn’t the case here.

I ended up using both techniques and discussed the trade-offs but frankly that experience left a bad taste in my mouth especially because that interview was with the hiring manager — my would-be manager, who is someone that can significantly influence your career growth and trajectory.

2. Undue pressure to accept an offer letter

It’s very exciting and fulfilling when you go through all preliminary stages of a technical interview, through to the onsite interview (remote or in-person) and then you receive that “Congratulations , we are pleased to offer you…” email.

However, that excitement often becomes short-lived when there is some form of pressure from your soon-to-be employer to accept the offer. It’s a bit more manageable when the pressure comes from someone in HR or the recruiter, but when it’s from the hiring manager, that can be harder to manage.

That was the case for me when I interviewed with a startup based in Palo Alto. They were a small company in terms of staff strength. My onsite interview with them had gone quite well. I had a good conversation with the hiring manager and an even better conversation with the VP of Engineering, so much so that I could tell that I was going to be extended an offer. I asked to know how long I had to accept the offer letter and I was told seventy-two hours.

The offer letter arrived later that evening, and it looked great — a six-figure offer definitely didn’t seem like a bad start. I was also at the final stage of the interview process with other companies too and thankfully, I had enough time to negotiate and accept the offer, or so I thought.

Then the pressure started, incessant calls from the hiring manager and the VP of Engineering, back-to-back emails, all within the allotted time. So much was the pressure that it got to a point where I wasn’t sure I wanted to negotiate the offer anymore. I turned down the offer.

I turned down the offer because the experience got me thinking about the company’s work culture. Were the methods employed by the company to get me to accept the offer indicative of their work culture? If they needed to get something done, how far would they go?

Now don’t get me wrong, yes the company wants to employ you, yes the recruiting team wants to ‘close the deal’ however, it’s very important to pay attention to how the company does this. Do they remain professional about it?

A company’s values go beyond what they say, it shows in what they do and how they do it.

3. Not enough clarity about your role

Among the many reasons why you would join a company is your desire to be involved in valuable work. I had the opportunity to join a US company based in Boulder, Colorado. They had contracted a recruiting agency to help them find someone to fill a Software Engineer position in their firm.

The hiring process started with an exploratory interview with the recruiting agency closely followed by a second interview with a recruiter from the company. In both interviews, I couldn’t get a clear sense of the details of my specific role was — what team I would be on, what kinds of projects I’d be working on, what the career growth pathway was, etc.

I understand that sometimes companies can be going through restructuring, but that didn’t seem to be the case here. It seemed more like the company was focused on completing their headcount. Even though there’s nothing wrong with completing a headcount, I think there is everything wrong with not having a clear purpose for a role for a couple of reasons:

• It means the role may not be critical to the company’s core business.
• If the role isn’t that important, it may mean when a layoff comes, your position may be impacted.

On a more personal note, I don’t want to be just a number. I want to work at a place where I have the opportunity to contribute in an impactful way, and I like to believe you would too. So it’s important to get clarity about your role, for where you are today and for future career growth.

4. Consistent lack of interest or low morale from interviewers

When looking to join a company, one of the things you simply must care about is the team you will end up working on. At least 25% of your waking hours will be spent interacting with that team whether in-person or virtually.

Interviews offer you an opportunity to experience firsthand what it will look like to work with your prospective teammates, especially since, unless you’re interviewing at a huge company, your interviewers are likely to become your teammates.

If through all the different stages of the interview process, you experience a consistent lack of interest or low morale from your interviewers, you might want to pay attention .

When I experienced that during one of my interviews, I couldn’t exactly tell what the cause was, but I knew something just wasn’t right. After some internal tussle, I decided to trust my gut feelings and ended the interview process with the company.

Fast forward to two months after, two of my interviewers (would-be teammates) had left the company and joined another company (no I wasn’t stalking 🙄, I just checked on LinkedIn ).

Now I’m not saying that during the interview process, there won’t be one or two people, who because of their busy schedules, would have preferred to be doing something else rather than interviewing. Yet, when all of the interviewers don’t want to be there, you certainly want to pay attention to that.

A lack of interest or low morale could be pointers to a combination of any of the following:

• Your prospective team-mates may be experiencing burnout.
• Some internal dissatisfaction with company — culture, policies, something, anything.
• The team isn’t that interested in you (hard pill to swallow?), maybe they don’t see you as a long-term hire.

Or it could be for reasons that I have not included here, but I implore you to not ignore this red flag if you see it in your next interview.

5. Your interviewers aren’t prepared for the interview

Have you been in an interview before where the interviewer doesn’t seem to have any questions to ask you? Trust me it can get really awkward.

That was my experience during a technical phone-screen interview with an educational technology company based in California. The interviewer wasn’t prepared for our interview and didn’t have any questions at hand. He wasn’t even sure of who he was interviewing and what role I was interviewing for. It wasn’t a pleasant experience.

I understand that there are a myriad of reasons why interviewers may not be prepared for an interview. Some of which include:

• Lack of proper planning by the HR/recruiting team.
• Last-minute changes on the interviewee.
• Busy schedules for the interviewer.
• The interviewer just wasn’t prepared.

I typically won’t act on this red flag in isolation. I will be looking for other red flags in a bid to form a cluster of patterns before making any decision.

6. Lack of a clear direction on where the company is headed

It’s fulfilling to be a part of a company that is involved in meaningful work that creates value for its users. Joining such a company would mean you have the desire to contribute in helping the organization meet its goals. This invariably means the organization must have some goals right?

I was contacted by a startup based in San Francisco via AngelList. I had a first introductory call with a recruiter from the company, closely followed by a phone screen technical interview.

In both interviews, even though the interviewers shared some details about the company, there was a lot of vagueness and about the company’s direction and where the company was headed.

I particularly remember that one question I asked at the time, was about how the company would deal with its growing competition. Sadly, the answers I got didn’t seem convincing and the company later got acquired by the competition.

When you are interviewing to join a company, you are selling more than just your skills, but also yourself — your unique experience. While it’s important to do that, I think it’s equally important that the company should be able to sell you on its vision and what it hopes to achieve.

When I think of joining a company, I picture myself in that company for the next 2–5 years. If my vision for where I want to be in my career doesn’t align with the company’s vision, that is a mismatch that shouldn’t be ignored.

Conclusion

We sometimes focus more on securing the job which is important. But equally important or even more important than getting the job is staying fulfilled on the job. For me, fulfillment meant joining a company that had a clear vision of where they were headed, working in a role that was critical to the company’s business while being equipped with a lot of growth opportunities.

Hopefully, these red flags I have shared will equip you to make better decisions on what companies you choose to grow your career with. I would generally not advise making a decision based on one or two red flags, but if you see a cluster of red flags, you shouldn’t ignore them. I wish you the best in your career journey.

If you ever need someone to do a mock interview with you, feel free to schedule one here or you can reach out directly to me on Twitter @meekg33k .

This massive amount of data generated has to flow through software systems from point of creation to the point where they are stored and on to the point of consumption, as efficiently as possible. I often think of software systems as a conduit for passage of data.

It therefore becomes critical that software applications and systems employ very optimal ways of representing data that passes through its system. Little wonder most technical interviews at companies that process massive data test the candidate’s knowledge of data structures.

I held over 58 free mock technical interviews in 2020 and during these interviews, one question I got asked a lot was: How much of data structures does one need to pass an interview and to become a sound software engineer?

Is it sufficient to know just a few basic data structures or do I need to know all data structures including red-black trees , tries etc? Which of the many data structures do I need to know? Is there a silver-bullet data structure that can solve all problems or like an MIT Professor once said, “when in doubt, throw in a hash map”?

This article will be my attempt to answer these questions.

I'll start by talking about what data structures are before moving on to what I think are the important things to know about each data structure. Finally, I'll pick a few fundamental data structures and do a deep dive on them especially highlighting their uniqueness and the use cases they are best suited for.

I recognize that some of the ideas in this article are subjective and that there could be a different perspective about this. I'd love to hear your thoughts on this.

Let’s jump right in!

What are data structures?

Data structures are a way of representing data.

Sorry, did you expect something overly technical? Hang on for a second.

Imagine you have a set of books. How would you arrange them?

You could decide to place them on top of each other as shown in the image above.

Or you could place them side-by-side (an array, a list), as in the image shown below.

Imagine if you were searching for the last book, which of the two layouts would make it easier for you to find the last book?

Hopefully, you said the side-by-side arrangement because you could just go straight to the book whereas, with the first layout, you’d have to remove every book on top of it first before getting to the last book.

So basically if you know you would be searching for books a lot, the side-by-side arrangement seems like a better choice.

However, imagine that the first book is the one you are currently reading and all you care about is that you want to be able to access that book. Then either arrangement would be fine right?

This is what data structures are about really.

A data structure presents a unique layout in memory for storing and organizing data. And just as we’ve seen with the example above, the arrangement of the data in determines the efficiency of certain operations.

Do you still want a more ‘technical’ definition? Alright then, here’s one:

A data structure is a data organization, management, and storage format that enables efficient access and modification.

What data structures should you know?

I’ll intentionally skip this part and answer this later, so let’s move on.

Okay I’m kidding.

There’s a lot of existing content that tells you what data structures you should know. I’m careful not to add to it because I don’t think anyone should put a cap on how much you can know.

That said, I believe in the 80–20 principle. What 20% of data structures do you need to know to not just excel at a technical interview, but to be a better software engineer at your job?

Here’s what I think that 20% would look:

• Arrays
• Linked Lists
• Hash Tables
• Trees
• Graphs

Sorry if that looks like 50 not 20.

The data structures listed above are important because they form the building blocks for a number of more sophisticated data structures. Red-black trees for example, are first trees, before anything else; and trees are just a bunch of connected linked lists with some defined hierarchy. Similarly, sets use hash tables for their internal implementation.

In addition to knowing these fundamental data structures, it is crucial that you have an in-depth knowledge of the data structure(s) you use every day at work or at a company you hope to work for. For example, if you hope to work at a graph database company or on the Google Maps team, having a rich knowledge of graphs and trees would better set you up for success.

With that said, let’s talk about the important details you should know about a data structure.

What about a data structure should you know?

If you had infinite time, infinite mental resources and you love learning, you may want to try to learn everything about all the data structures. Sadly, infinite time and resources are still a utopian dream.

To utilize our finite resources efficiently, we need to focus on the more important things, the biggest bang for our buck. What then are the important things a good software engineer (and that’s you because you are reading this article) should know about data structures?

Here are the main things you should know about a data structure:

• Read/Access time: How long does it take to read from the data structure?
• Write time: How long does it take to update an existing entry in the data structure?
• Insert time: How long does it take to insert a new entry into the data structure?
• Delete time: How long does it take to remove an entry from the data structure?
• Search time: How long does it take to find an entry in the data structure?

It is important to note that the times listed above are measured using something called the Big-O Notation.

One other thing I will add to this list will be: does each record in the data structure have an associated overhead? For example a node entry in a linked list, has more memory footprint than an entry in an array.

Knowing these things help you understand what each data structure is best suited for and making better decisions about when to use which.

Some fundamental data structures

Now that we know what we should be looking for in a data structure, let us apply this to a few fundamental data structures in a bid to understand their peculiarities and what use cases they are best suited for.

1. Arrays

An array is a data structure that stores a collection of elements in contiguous memory, with each element identifiable by its index or position.

Contiguous is a big word for saying side-by-side. Arrays use a memory layout that allows elements to be placed side by side (think to our side-by-side book arrangement).

The more important things to know about the array are:

• Read/Access: Constant time
• Write: Constant time for fixed-size arrays. Constant amortized time for dynamic arrays with linear time as worst case.
• Insert/Delete: Linear time because though you can directly access the element to delete using its index, you have to move elements after the target element.
• Search: Linear time - you have to explore each element.
• When to use: You get the gains of an array (constant time read/write) when you have a fixed number of elements to store, e.g. number of alphabets, countries in Asia etc.
• When not to use: Arrays aren't best suited for search operations. They also aren't best for cases with frequent inserts and delete operations because it has to copy all the elements after the index of the inserted/deleted element.

2. Linked Lists

A linked list is a linear collection of elements where each element (often called a node) is 'linked' to the next element. Each node stores a reference (something that points it) to the next node, something almost akin to a chain.

Traversing a linked list starts from the first node and uses the reference to the next node, all the way till the final node in the list.

Here are the things to note about the linked list:

• Read/Access: Linear time
• Write: Linear time.
• Insert/Delete: Constant time if inserting/deleting at the beginning. Linear otherwise.
• Search: Linear time as you have to explore each node.
• When to use: Linked lists are best suited for cases when you expect frequent insert/delete operations at the top or end of the list. A good example would be stacks and queues.
• When not to use: Don't think linked lists if you want fast search or read operations, except you are reading from the top or the end of the list.

3. Hash Tables

A hash table is a data structure that stores data in an associative manner by storing key-value pairs. By using a hashing function for each key, the hash table ensures that no two keys in the hash table are the same.

Sets and hash maps make use of hash tables as their internal implementation.

There’s more to say about hash tables and I will do a deeper dive in my upcoming series on data structures but for now, the key things to know about the hash table are:

• Read/Access: Constant time
• Write: Constant time.
• Insert/Delete: Constant time
• Search: Constant time.
• When to use: Always baby, always! But seriously, hash tables have a broad range of use cases because of its constant read, write and insert time.
• When not to use: Hash tables aren’t the best when it comes to iterating over its entries. Also because of its associative nature, each record in a hash table comes with extra memory overhead so use it when you absolutely need the keys. For example, if all you need is constant read/access time for a fixed data, then a simple array is more memory-optimal.

4. Trees

A tree is a non-linear data structure that represents the relationship between a root node and zero or more sub-trees in a hierarchical structure.

There are different implementations of the tree data structure including but not limited to: binary trees, binary search trees, red-black trees, AVL trees and n-ary trees. If you will like to learn more about these implementations, I’ve added some links in the resources section.

The time efficiency for the different operations using the tree data structure are:

• Read/Access: Best-case: Logarithmic, Worst-case: Linear
• Write: Best-case: Logarithmic, Worst-case: Linear.
• Insert/Delete: Constant time if inserting/deleting at the beginning. Linear otherwise.
• Search: Linear time as you have to explore each node.
• When to use: When you want to represent hierarchical relationships and when you want faster search on sorted data (binary search tree).
• When not to use: Unsuited for searching through unsorted data.

As you may have noticed, I have skipped the section on Graphs because graphs are simply a collection of connected trees and so the same things mostly apply.

TL;DR

I once worked on a project where a big part of the optimization that needed to be done in reducing the page load time of the app was to change the data structure used for storing a part of the app state from an array to a hash-map. We were carrying out a lot of search operations and an array data structure wasn’t the best for it.

It is therefore important to know the unique features of each data structure and what use cases they are best suited for.

So summarily,

• For fast lookup operations, a hash-map should be one data structure to consider.
• For numeric search operations, think binary search trees.
• For character search operations showing relationships between the elements, think tries.
• For fast reads and writes, think hash tables and arrays (when the data is of a known size).
• For frequent inserts and deletes at the start/end of the data structure, linked lists are your best bet.
• To represent relationships between entities, trees would be the most suitable.
• To represent directed or undirected non-hierarchical relationships between entities, think graphs.

Conclusion

Understanding data structures is not just another item to mark off your checklist for a technical interview. Data structures are a powerful tool in the repertoire of a software engineer to help you write cleaner, more efficient code.

The best engineers know their tools and know when to wield which to solve a specific problem.

A good tool improves the way you work, a great tool improves the way you think

Let’s all aim to use great tools today. 😊

If you are interested in a more detailed study on each data structure, I will be starting a series next month where I’ll be doing a deep-dive into the data structures I’ve listed here and a few others. Please subscribe here so you don’t miss out on it.

I'll also be resuming free mock interviews for 2021 by next month, March. So if you ever need to do a free mock technical interview, please feel free to reach out on Twitter @meekg33k .

I hope this was worth your time. E go be! ✌️

Further Reading

• Tries, dictionaries, and queues: Applying data structure knowledge on the job

• Data Structures & Algorithms I Used Working at Tech Companies

• 8 time complexities that every programmer should know

• Everything you need to know about tree data structures

• When not to use hash tables

• Real-time application of Data Structures

Some of the questions I got include:

“How is it possible to do that many interviews in such a short time?”

“How do you fail one interview and immediately move forward to the next one?”

In that article, I briefly touched on the experiences that formed my motivation for going on that intense run of technical interviews. I also shared lessons I learned from that experience and, thankfully, they’ve turned out to be useful to a lot of people around the world.

What I hadn’t shared yet were specific examples of some of the things I encountered during this period. In this article, I’ll get into some of those details by sharing the most eventful moments during my marathon month of technical interviews – including technical content and personal experiences.

The technical content will focus more on the most challenging algorithmic questions, projects, and coding challenges I faced, while the personal part will be about my experiences — successes, struggles, etc – and the lessons I extracted from these eventful moments. I hope in this you, dear readers, can find something useful to apply to your professional lives.

Navigating the introductory phone call I was least prepared for

At the time I started interviewing, I had a full-time, non-remote day job as a software engineer with a company in the San Francisco Bay Area. That means I had a busy work schedule, typical of any software engineer.

On one particular day, I had just finished from a technical meeting and got on this call with a recruiter from a certain mid-size technology company based in Palo Alto, California. I joined that call straight out of a meeting and because of that, I didn’t have the time to do proper research on the company – or at least that’s what I told myself.

The phone call turned out to be not so introductory, rather it seemed to be a mini technical interview. Not only was I asked about my experience and some of the projects I had worked on, I was also asked to explain some technical concepts. Some of the concepts I vividly remember include:

• Closures in JavaScript
• Concurrency and lock-mechanisms
• Difference between hashing and encryption

All in an introductory phone interview? Yes, my friend.

Even though I attempted to answer all of these questions, I wasn’t very coherent in my answers. In addition, the fact that I didn’t do my research on the company before the call didn’t help, as I couldn’t ask a lot of insightful questions about the company and couldn’t also give a good answer when the interviewer asked what I knew about the company.

Some of the lessons I took out of that experience are to never get on a phone call with an interviewer without knowing at least these two things:

• The first name of your interviewer
• At least one tangible thing about the company — what they do, where they are located, any recent news, something

The other thing I’ll say is when you are asked questions that you weren’t expecting, try to stay composed and make an attempt at answering them to the best of your knowledge. And if you don’t know about it, it’s okay to say you don’t.

Tackling the most challenging algorithm question

Over the course of my interviewing period, I encountered some challenging algorithmic questions ranging from dynamic programming problems to problems where I used Dijkstra’s Shortest Path algorithm.

The one algorithmic problem, however, that still stands out to me as the most challenging was a problem that involved constructing words from a 2-D array. Below is the problem statement:

Given a 2-D board and a list of words from the dictionary, find all words in the board that are contained in the list. Each word is formed by sequentially adding characters in adjacent cells, whether horizontally or negatively and no character in a cell should be used more than once in a word.

The problem statement written in JavaScript code is seen below:

My approach in solving this problem is outlined in the steps below:

• Build a Trie using the words in listOfWords.
• Using a combination of recursion and backtracking, explore each cell in the 2-D array starting with the first cell to see if its character matches the first character of any word in the Trie data structure.

The image below highlights characters in the matching cells that match the words in the Trie.

As seen in the image above, the subset of words in listOfWords that can be formed from the characters in the 2-D array are eat, grind, and nike.

For more details about this problem and the Trie data structure, I’ve added some links in the resource section at the end.

Getting a little too ambitious on a take-home project

I got about 18 take-home “expect-to-spend-5-hours” projects for the period I was on this interviewing marathon. As I mentioned in my first article, one of the companies offered to pay $68/hour to candidates working on their take-home projects. (I wish I could say that was the project I found most interesting.)

The project I found most interesting was one where I was asked to build a font-scraper service. The requirements for this service was such that it would provide an endpoint that accepts a source URL, access the page at that URL, and extract all the fonts on the page set via inline, internal, and external styles. In addition, the service would access every outgoing URL found as a link on the source page, extract fonts from all those pages, and keep doing this recursively.

In addition to the requirements above, the service was meant to be configurable such that the consumer of the service could pass two parameters:

• A crawlType param that determines how the pages would be traversed using either bread first search or depth first search
• A pageLimit param that determines how many pages should be explored. (Interesting stuff!)

This project tested everything from knowledge of good system architecture and API design to my decision-making – especially as it concerns structuring a project – and from code readability to code extensibility. It was a very well-thought-out project.

Some of the good things I did on this project were:

• Unit/Integration tests (more than 700 lines of code with ~90% coverage)
• Implemented rate limiting. (This wasn’t part of the requirements but if you’re building APIs, you should be thinking about this)
• Implemented some form of queuing system for handling failed scrape jobs. (Again this wasn’t part of the requirements but hey, why not?)

The one thing I did wrongly that cost me dearly was I wrote the font-parsing algorithm to extract the CSS from the HTML myself. Because I love to solve problems from first-principles, I was ambitious and wanted to tackle this head-on. Bad move!

It’s important to know when to express your love for challenges; doing that in an interview may not always be the best idea. If you’re going to reinvent the wheel, make sure your wheel is better. I could have just gone with a library that already solved that problem.

For take-home projects, spend time on the core requirements and make sure those work before moving on to extra requirements. I learned that the hard way, you don’t have to.

Solving a Tricky System Design Question

I was asked to build an interactive shell that allows access to a transactional in-memory key/value store.

The shell would accept the following commands:

• SET [key] [value]: Sets the given key to the specified value. If the key is already present, overwrite the old value.
• GET [key]: Prints out the current value of the specified key. If the key has not been set, it prints a default message.
• DELETE [key]: Deletes the given key. If the key has not been set, ignore.
• COUNT [value]: Returns the number of keys that have been set to the specified value. If no keys have been set to that value, prints 0.
• BEGIN: Starts a transaction. These transactions allow you to modify the state of the system and commit or rollback your changes.
• COMMIT: Commits the changes made within the context of the active transaction and ends the active transaction.
• ROLLBACK: Throws away changes made within the context of the active transaction and ends the active transaction. If no transaction is active, prints NO TRANSACTION

Implementing the SET, GET, DELETE and COUNT commands didn’t seem difficult. The trickiness was in implementing the abstraction that would represent a transaction.

A transaction is created with the BEGIN command and creates a context for the other operations to happen. For example if the following sequence of commands were entered in the interactive shell

> BEGIN //Creates a new transaction
> SET X 5
> SET Y 19
> GET Y
Y = 19

The expectation was that a transaction would be created (because of the BEGIN command) and all the following operations would happen and work as they should. However, they would work only in the context of that transaction that was created. This transaction would be the active transaction.

It is also expected that until the active transaction is committed using the COMMIT command, those operations do not persist, and the ROLLBACK command throws away changes made by those operations in the context of the active transaction.

The snippet below provides more clarity about the expected behavior:

> BEGIN //Creates a new transaction which is currently active
> SET X 5
> SET Y 19
> GET Y
Y = 19
> ROLLBACK //Throws away the changes made
> GET Y
Y not set // Changes made by SET Y 19 have been discarded

The trickier part of this question was understanding that each transaction could spawn a new transaction (think of it as a child transaction).

The newly spawned transaction inherits the context (variables) from its parent transaction and changes made in the context of a child transaction and committed would reflect in the parent transaction because committing wrote directly to the key/value store.

Here is another sequence of operations that explains this better:

> BEGIN //Creates a new transaction which is currently active
> SET X 5
> SET Y 19
> BEGIN //Spawns a new transaction in the context of the previous transaction and now this is currently active
> GET Y
Y = 19 //The new transaction has access to the context of its parent transaction
> SET Y 23
> COMMIT //Y's new value has been persisted to the key-value store
> GET Y
Y = 23 // Changes made by SET Y 19 have been discarded

This question tested everything from understanding of good system design, knowledge of data structures – especially for designing the abstraction that represented a Transaction – and how to write highly performant code.

Handling the most hurtful failure

Doing 60+ technical interviews in such a short time meant I had a good dose of failures, all coming at a really fast pace. Some I could shake off easily, a few others would hit at the core of my sanity and make me question how good a software engineer I was. Those latter ones were harder to shake off.

The one that turned out to be the most hurtful failure, and I still vividly remember it, came during an interview with a data infrastructure firm headquartered in Denver. The company was looking to fill a senior software engineer position and they reached out to me because they thought I was a good fit.

The introductory call went well, the first technical interview went even better, but it was the second technical interview that went south. I was asked to write a function that took in a list of times and calculated the minimum time difference between different times.

One reason why this hurt really bad was because I know I solved the problem correctly, and even the interviewer confirmed it. I had identified the boundary conditions and ensured that the code I wrote handled those conditions and other edge cases. I even went on to ask the interviewer if I should care about cases where the time string was wrongly formatted (12.30 for example vs 12:30). With such a bullseye, then, did I move on to the on-site?

It’s one thing to not pass an interview because you didn’t do well, but to do well and still not pass the interview? I couldn’t wrap my head around that. I remember the day I got that rejection email. I was so devastated that I had to reschedule the remaining interviews I had that day.

After much thought, I had to accept that sometimes the reason you don’t scale an interview may not be you; there could be myriad of other reasons, from a change in company’s hiring plans, an interviewer having a bad day, etc.

That experience taught me that there are things I can control and there are things I can’t. You can control how well you do in the interview, the quality of the code you write, how well you communicate your thought process, etc. One thing you can’t control is the outcome – you can only hope that the things you can control, your actions, can influence the outcome.

So separate yourself from “failed” interviews. When the failures come, seek to take the best lessons out from them and apply it to your next interview. In other words, fail forward.

Celebrating my biggest win

Going through 60+ technical interviews in 30 days definitely had more downs than ups. However, when the wins started coming, it was very exciting and fulfilling.

Whether the win was as small as passing a technical phone-screen or a HackerRank coding challenge, or as big as getting to an on-site interview or even the many offers that came, I learned to celebrate every win.

And it was in celebrating all these wins that I discovered the biggest win of all: By going through this exercise, I had grown immensely and I had become more confident in handling technical interviews. That truly was my biggest win!

Sounds like a simple answer, but it’s the truth.

To you

You may not embark on a technical interviewing marathon like I did, but most definitely you are facing your own daily challenges as you strive to be better every day. Progress is sure when you’re consistent. Keep plugging away and the wins will come.

I sincerely hope reading about my experiences has been rewarding to you, but more importantly, I hope you have taken away vital lessons that you can apply to your professional and personal lives. I wish you the very best in your career!

I’ll be writing a series on data structures in a few weeks where I’ll be explaining how to know what data structure to use when designing an algorithm. If that’s something you’re interested in, please follow me on Twitter where I post about my articles.

Also, if you ever need someone to do a mock interview with you, I’ll be more than happy to — free to reach out to me on Twitter @meekg33k.

E go be ✌️

Helpful Resources

• Trying to Understand Tries
• Get Hired: The System Design Interview, Explained
• Breadth First Search Tutorials
• Depth First Search Tutorials

I’ve grouped the lessons into three categories to match the phases of a typical recruitment process.

While most of the lessons apply directly to software engineers and technical professionals, the principles behind these lessons can be applied to all careers. I hope you find something useful that you can apply to your professional lives.

How did I get started?

“If you’re going to fail, do it fast.” — Unknown

Like any other software engineer, I’ve had different types of technical interviews - from the dreaded whiteboard coding interview to the unreal 45-minute coding challenge on platforms like HackerRank. While some of my experiences in these interviews were great, others were bad. Really bad.

But I wanted to get really good at interviewing. I wanted to learn to overcome the interviewing phobia and exude confidence at interviews. Like a skilled surfer, I wanted to learn to ride the high pressure waves that came with interviews. I was also looking to change jobs at the time.

So from January through early March 2020, I applied to and was contacted by companies based in the US and Europe. From early-stage startups like Coda to later stage startups like Crunchbase, from mid-size companies like Affirm, to bigger companies like Amazon and even remote companies like Webflow.

109+ applications later, I landed myself more than 60 interviews. These comprised more than 60 introductory phone interviews, 50+ technical phone screen interviews, 18 take-home coding projects, 11 coding challenges and 8 on-site interviews including 3 virtual ones.

What did I learn?

For better appreciation, I have grouped the lessons into three categories to match the different phases of a typical recruitment process.

Pre-Interview Phase

This covers everything from the initial contact with a company to the point where the first interview happens.

1. What I learned about applications

When I started applying to companies, I imagined that the more applications I submitted, the higher my chances of getting an interview would be. Seems logical, huh? So I set a target of 5 applications a day, aiming for 1 interview for every 5 applications.

But my strategy didn’t work as I hoped it would. The number of interview requests I got often fell short of my target. It was almost a 1:12 ratio - 1 interview for every 12 applications.

I was faced with the question: do I need to increase my daily target to, say, 10 companies? Or was there something else I needed to change?

With every unsuccessful application, I saw that something needed to change.

That change came when I took a break from meeting my daily numbers and began to think of my applications differently. I began to see each application as a sales pitch to the hiring manager or whoever was going to be reading my application, but here the product being sold was me.

If a company needed to fill a talent gap and I say I had the skills, I needed to find a way to convince them that I did.

My new task then became to find a way to effectively pitch my unique skills, experience and personality in a way that convinced the hiring manager that I was the right fit for the job.

Here is an example of one of such pitches I came up with:

Backed with my resume, this cover letter had a 95% success rate. The one time this didn’t work, the hiring manager still replied to let me know that the position was no longer available but he would like to connect in the future.

The lesson here is, be very intentional about the application you put forward – quality over quantity. Better still do both. Know your unique competencies and experience and present them in a way that matches the company’s needs without sacrificing your personality.

It is also important to understand the peculiarity of the company you are applying to and its specific needs. A startup or a smaller-sized company may have different needs from a bigger company, thus requiring a different skill-set.

Sell yourself and be sure to back your sales pitch during the interview.

2. What I learned about recruiter in-mails

During this period, I received a number of in-mails from recruiters (mostly unsolicited) for open roles, the majority of which were roles I wasn’t interested in.

Granted, it was sometimes a lot given my busy schedule but I learned to be empathetic, understanding that these recruiters were only trying to do their jobs.

I stopped seeing these in-mails as noise in my inbox and started making the effort to reply to all recruiter in-mails, even for positions I was not interested in. By doing this, I succeeded in building a network of recruiters that have become a rich resource if I have to switch roles in the future.

Now I don’t expect you may want to start replying to every in-mail you receive. But it might interest you to know that some of the interview requests I got were from recruiters I had replied to before for roles I wasn’t interested in. It never hurts to reply.

The Interview Phase

This covers everything about the interview itself, cutting across the different interview types.

3. How to handle introductory phone calls

Yes I get it, you’re busy and many things are competing for your time. But hey, you are also an excellent professional, and that means you never get on a phone call without knowing at least these two things:

• the first name of your interviewer, and
• at least one tangible thing about the company — what they do, where they are located, any recent news, something, anything!

I noticed that for interviews where I put in the effort to make these findings, I always came across as being genuinely interested in the company. That’s something recruiters typically look for in these kinds of interviews.

4. How to handle technical phone screens

The one thing that can almost single-handedly decide how well you do in a technical phone screen interview is your ability to communicate your thoughts clearly.

You may have heard stuff like this before: “The interviewers care about your thought process. Yes they can see your code but importantly, they want to know why you are doing what you’re doing.”

The interviewer isn’t there with you and so does not have the luxury of seeing other non-verbal cues like your hand gestures or nuances. All the interviewer has is your voice as a means of understanding your thought process.

Now you know how you should lead this conversation, the next question is how do you become good at this? Because the truth is, while expressing your thoughts may come naturally to some people, it doesn’t to others – including me.

So – Practice! Practice!! Practice!!!

Practice doing a lot of mock interviews. Doing these mock interviews with friends made me better and more confident in explaining my thought process. But more interestingly, it helped me develop a new mindset about interviews.

I began to see interviews as a conversation with a friend or a team member. I visualized the interviewer on the other end as one of my friends (I sometimes gave the interviewer a name in my head). So what would have been a high-pressure interview I now saw as a friendly ‘chat’ about a technical problem.

This new mindset, aided by the many practice interviews, helped me grow in confidence so much so that I started enjoying interviews, sorry, technical chats. How to get started on a problem

Never start solving a problem without fully understanding the problem statement. You are almost never wrong if you start by asking clarifying questions. It’s also a good sign to your interviewer when you ask those questions rather than run with your assumptions.

5. How to solve the problem

Good candidates know how to solve a problem (e.g. a sorting problem), but the best candidates know multiple solutions to a problem and understand the trade-offs of one solution versus the other.

The interviews where I performed the best (Cruise comes to mind) are the ones where I didn’t just solve the algorithmic challenge – I was also able to provide alternative solutions and discuss the trade-offs.

Aim to provide multiple solutions to a problem, be willing to discuss the trade-offs, and be able to implement at least one of them.

For technical interviews, write clean code. Most interviewers care about your code quality as well as the correctness of your solution. Aim for modular code, separate reusable logic into utility functions, name variables and methods properly, and just be a boss!

6. What to do when you’re stuck on a problem

There will be times when you’re stuck. And this could be caused by a number of reasons: you don’t have the requisite knowledge, incorrect assumptions, missing details, and so on.

I used to think that at such times I was being judged by how fast I could come up with a solution. So I would be quiet, thinking, not communicating with the interviewer, just thinking.

And this is where a lot of us get it wrong. I get it, you need some alone time to think. But sorry to burst your bubble, that alone time is not when you’re being interviewed by a person.

Yes, your interviewer wants to see that you can come up with a solution, but one thing you must not forget is that they also want to see that you can collaborate with other team-mates to come up with a solution. While companies want rock-stars, they also want team-players.

Since your interviewer is a friend, a buddy, a team member who’s on your side and means well for you (Refer to 4), talk to them while you're figuring it out.

Share your thought process up till the point you got stuck and do it confidently, not like some cry for help. By doing so you just may uncover the solution, as was the case during my interview with Coda.

7. How to handle coding challenges

The lessons here apply to interviews that take the form of coding challenges on platforms like Hackerrank, Codility, and so on. Typically these are timed challenges, say 45 minutes or sometimes could be more.

Some of the lessons I shared earlier are useful here, while others like asking clarifying questions don’t apply since there’s no one to ask. So here are some steps I recommend:

• Read through and fully understand the problem.
• Write code that works first, even if it’s a brute-force algorithm. It may not pass all the test cases but get some working code out there first, hopefully within the first 15–20 minutes.
• Test your code with different input types, as this helps you handle edge cases.
• Optimize for efficiency (runtime and space complexity).
• Repeat Steps 4 and 5, till the very last minute.

A good grasp of computer science fundamentals is key here. I’ve added some links to helpful resources in the Resources section below.

8. How to handle take-home projects

Take home projects are an opportunity to really shine because you have more time. This also means they can be time-consuming.

One of the companies I interviewed with provided hourly pay, about $68/hr, for the number of hours you worked on their take-home project — it’s that serious, so you should be serious about it. Be sure you really want to be a part of a company before investing your time in the take-home projects.

Never compromise on code quality for take-home projects. Be very intentional about your design decisions, naming conventions, code structure and so on, and be ready to defend your choices.

9. What tools should you use?

During my interview with Course Hero, I used regex to solve a problem I could have solved using a simpler string parsing algorithm. It turned out to be a bad decision as I didn’t pass the interview.

The lesson: only use tools you’re very comfortable with and have a lot of experience with.

10. How to approach on-site interviews

Get a good night's sleep the night before. Arrive early on the day of your interview and smile a lot (it helps portray confidence, but more importantly helps you stay relaxed and be in control).

Confront your fears and accept that even if this doesn’t work out it’s not going to be the end of the world – after all you’re just going to have another technical chat. Then go in and absolutely chat away.

11. How to approach virtual on-site interviews

These can be very different from on-site interviews because everybody’s eyes are on you – literally – and that can be nerve-racking.

I had three virtual on-site interviews and I didn’t pass any of them. Sorry I’m not your guy for this one, but I’ve shared some resources that I think you may find helpful below.

After the Interview

12. How to handle failure

There are many reasons why you didn’t pass an interview. Some of the best engineers I know have failed interviews at some point and still do.

So separate failed interviews from yourself, look for the learning points from each failed interview, and use those to forge ahead. As they say – we move!

13. What about success?

Celebrate your successes, regardless of how small you think they are. I have a few ideas for celebration.

Am I better after doing this?

I’m not going to tell you that I've aced every interview that has come my way since I embarked on this journey. But assuredly, I can tell you I have gotten better at interviewing and my confidence levels have really grown. And yes, I also got multiple offers too 😊.

What should you do next?

• Practice doing a lot of mock interviews with friends. While I don’t totally agree that practice makes perfect (because perfection sounds like a moving target to me) practice helps you quickly identify patterns in interview questions, grow in mastery and ultimately your confidence.

• For technical interviews, nothing beats a very good understanding of the fundamentals of data structures and algorithms. I’ve added links to resources I think you may find helpful.

• Start interviewing and keep interviewing. Even if you have a job, aim to interview every now and then — maybe once every other month or a quarter. Interviewing is a skill, so keep honing it.

I really hope this was helpful to you. And hopefully some of the lessons shared here will make you more confident and better at interviewing – and will ultimately help you land that job you really want.

If you ever need someone to do a mock interview with you, feel free to reach out to me on Twitter @meekg33k.

E go be. ✌️

Helpful Resources

• The Ultimate Guide to Acing Your Technical Interview | Learn to Code With Me
• How to Ace Your Technical Interview
• The Essential Guide to Take-home Coding Challenges
• The Anatomy of the Perfect Technical Interview from a Former Amazon VP
• 9 Tips for Mastering Your Next Virtual Interview | HBS Online
• 8 Skype Interview Tips: Ace Your Virtual Job Interview

How a utility function was born

If you had to write logic to check if an object of a certain type is defined and if the object actually has any keys, a simple way to do it in TypeScript would be:

If you had to use this logic repeatedly, an ideal thing to do would be to create a function that encapsulates this logic. Written in TypeScript, this function would look something like:

Good stuff right? Let’s consume this utility function and see what happens. The code snippet below shows what we see in a VS code editor when we use the utility function.

Okay, what just happened? Why are we having the error above?

If you look closely at the code snippet above, the logic inside the function is the same logic we used before we wrote the function but for some reason, TypeScript is complaining. What are we doing wrong?

Issue I: TypeScript doesn’t “recognize” the logic in the utility function

How do we solve this issue with TypeScript not recognizing the correct logic contained within the isPresentSomeObject utility function?

One way to fix this would be to use the non-null assertion operator (!) in TypeScript which is basically you telling the compiler, you know what you are doing.

While this works, I’m not a huge fan of this approach maybe because I’m lazy and don’t want to type the non-null assertion operator (!) every time I have to use this function.

But seriously is there a better, more scalable way we could rewrite this? Hold that thought while we look at what the second issue with this function is.

Issue II: The utility function does not currently support other types

Our utility function works with arguments of SomeObjectType type, what if we had to use the same function with another object of a different type, AnotherObjectType? We could refactor the utility function to support the new type by creating a union of the existing type and the new type, as shown below:

Okay, say we have to support a third type and a fourth type? Add the types to the union? Seriously? What if there was a fifth type?

You’ll agree that creating a union of more types is not scalable and at this point, you may catch yourself thinking “Why not just make the argument of type any so it can accept ‘all’ types?”

Err, hang on! The challenge with using type any is that we lose the type safety that comes with TypeScript. So how can we rewrite this function without using type any?

Hello Generics

According to Wikipedia, Generics are a facility of generic programming that allows you extend a type system to allow “a type or method to operate on objects of various types while providing compile-time type safety”.

Imagine you had an identity function that takes an argument of a certain type and returns the argument. If you had to create one function each for a string, Boolean and number types, your code could possibly look like the code below:

Hopefully not because the code snippet above violates the DRY principle. What we need instead is a way to reuse this logic regardless of argument type. Already seeing the similarity between this and our utility function?

Generics provides that abstraction that allows you define parameter types (to be specified later) making it possible to reuse code with different types. With generics, the identity function above becomes:

By doing this, we are telling the TypeScript compiler “hey, the argument type is of a parameter type, T, and you’ll find out what T is at compile time”. This allows us to pass any type as a parameter without losing type-checking.

Rewriting our utility function to use generics, the function becomes:

With this, you get both the dynamism that comes with using any type and the safety that comes with type checking: double win, if you ask me.

Challenge 1 solved! Next stop, how do we get the compiler to “recognize” our utility function?

Introducing User-Defined Type Guards

If you’ve used TypeScript for a while but haven’t heard of type guards, you’re in good company. Until we ran into this challenge, I hadn’t heard of them either.

Let’s imagine you have the following defined interfaces:

If you had to implement logic that would check for what type an animal is, how would you do it? One way would be to use a type assertion:

Great! What happens if more types are added to the Animal type union?

type Animal = Cat | Dog | Goat | Horse | Kangaroo | ...

Writing a function for each new type isn’t scalable. How then can we create a utility function that allows the TypeScript compiler infer the type of a variable without having to explicitly use type assertion? This is where type guards come to play.

From the TypeScript documentation, a type guard is some expression that performs a runtime check that guarantees the type in some scope.

What does that even mean?

The gist is that with type guards, you can instruct the TypeScript compiler to infer a specific type for a variable in a certain context.

By using a feature called type predicates , type guards allow you to tell the TypeScript compiler that the type of an argument is what you say it is. This process of refining types to more specific types is called narrowing and it ensures that the variable type is the exact type you expect at runtime.

Predicates are functions that return Boolean values. Type predicates are of the form parameterName is Type , parameterName being the name of the function argument and Type the argument type, and they also return Boolean values.

How do you define a type guard?

To define a type guard, simply define a function whose return type is a type predicate.

So an isCat type guard is a function that has the animal is Cat predicate as its return type as shown below:

Note that I didn’t even have to implement any ‘serious’ logic in the function, all I had to do was return true because remember, predicates are functions that return Boolean values.

The isCat type guard tells the type system that we’ve confirmed that the animal argument passed is a Cat, so when the compiler does its control flow analysis and sees our type guard, it says “Oh! Whatever is passed into this function has to be a Cat if it returns true”.

It then narrows the argument type from Animal to Cat, that way, we are guaranteed that what the type we get at runtime will be a structure that is consistent the Cat interface definition.

To further appreciate type guards, let’s use it in an if-else block:

Remember again that we didn’t implement any ‘serious’ logic in the isCat type guard, but the compiler sees the return type as a Cat because of the animal is Cat predicate; so it doesn’t throw any error in the if block of the code snippet above.

What happens in the else block however is more interesting.

Because the compiler expects a Cat type in the if block, it says whatever is in the else block has got to be a different type — that type is the never type which is a type used for values that never occur, hence the error message you see in the else block.

Hopefully that was clear, now let us apply type guards to our utility function and see how that solves the problem we described in the first challenge.

Converting our utility function to a type guard

Since a type guard is just a function whose return type is a type predicate, all we need to do is to modify our utility function to return a type predicate.

What type predicate however, do we use for this utility function?

Recall that generics allow you to define parameter types which then get assigned at compile time. To convert our utility function to a type guard, we would take advantage of that and make our return type a type predicate of the form arg is T where T is the argument type.

And now it works!

Conclusion

Thank you for reading. I hope reading this has raised your knowledge level about TypeScript generics and user type guards but more importantly, I hope it has stoked your interest in understanding how the TypeScript compiler works.

If you want to learn more about type guards, the type system or the compiler generally, you may find the links in the Further Reading section helpful.

If you’d like to chat about this or anything at all, I’ll be happy to connect via Twitter or LinkedIn.

Stay safe 😊.

TL;DR:

• If you catch yourself using type any as a way of making a piece of code more robust, think generics.
• Type guards are powerful for narrowing types, satisfying the TypeScript compiler’s control flow process and guaranteeing runtime type-safety.
• Think type guards when the type you want to use is not as specific as you’d want or when you want to verify that external data is of a specific type.
• There are built-in type guards that come with TypeScript like typeof and instanceof but user-defined type guards can be more powerful when used right.
• Like all things powerful, user-defined type guards shouldn’t be abused; they shouldn’t be thought of as a way to hack the TS compiler.

Further Reading

• Type guards and conditional types in typescript & prelude-ts
• How to get the types you want with TypeScript type guards | Rangle.io
• Narrowing
• Control Flow Based Type Analysis in TypeScript
• Type Narrowing in TypeScript

Recently, I was working on a grocery shopping app and one of the UI screens had the requirement to build an activity showing a list of products such that when a user clicked to add a product to cart, the count of that product would be updated and all other occurrences of that same product elsewhere in the app would also be updated.

Since an image is worth more than a thousand words, let me spare you many words — the image below describes the expected behavior.

Thinking through this problem and the interacting pieces, I felt this would be a good case to apply a software design pattern.

Introducing the Observer Design Pattern

According to Wikipedia, the observer design pattern is a software design pattern in which an object (called the subject) maintains a list of its dependents (called observers) and notifies them automatically of any state changes, usually by calling one of their methods

From the definition, the Observer pattern seemed ideal for this problem. This doesn’t mean other patterns wouldn’t work — at least the Publish-Subscribe Design pattern, which is subtly different from the Observer pattern, could also work. If you want to know more on the differences between the two patterns, here is an article by Ahmed shamim hassan, who did a great job in explaining the difference between both patterns.

Now to the more interesting part of this — the application & implementation of this pattern to solve this interesting problem.

Identifying the key components

When implementing a software system, it’s important to identify the key components that interact in the system and what roles they play. The key components in an observer pattern are the subject and the observers.

For this specific requirement, the subject is the Cart model and the observers are…? (You want to take a guess?) To appreciate what components constitute the observers, it’s important to understand the expected functionality of this activity screen.

The requirement is such that when a user adds a product to a cart, the count of that product is updated in that current view and the count of every other occurrence of that same product in a view is also updated. So if Product A was listed under the Featured Products section and also listed under Fresh Foods Department, the count of both instances in their respective views would be updated if Product A was added to the cart. This suggests a 1-to-N relationship between product and view as illustrated below.

I’m guessing by now you’ve been able to figure out what the observers are? That’s right, the product views are the observers.

Implementing the Observer Pattern

To implement this pattern, first there had to be a way for the observers to subscribe to changes in the subject (Cart) state. To do this, I created an interface in the Cart class that would be implemented each product view.

public class Cart {
    /**
     *  Listens for cart state change events
     */
    public interface OnStateChangeListener {
        void onStateChange(View v);
    }
}

Each product view simply had to create an instance of this interface (with its implementation) — one listener per product view.

So now we have instantiated these view listeners but they are not listening for changes to the Cart model. To attach listeners to the subject, the Cart class exposes a static setOnStateChangeListener method that takes a reference to the product, a reference to the product view and an instance of the OnStateChangeListener interface as arguments as shown below. This process of attaching listeners to the Cart is how the view subscribes to the subject.

//view subscribes by attaching listener to Cart state 
Cart.setOnStateChangeListener(product, view, mCartListener);

The more interesting part is what goes on in the Cart class when a call is made to the setOnStateChangeListener method. Internally, the Cart class maintains two HashMaps -one for Product listeners and the other for View listeners.

private static HashMap<OnStateChangeListener, View> viewListeners = new LinkedHashMap<>();
private static HashMap<Product, ArrayList<OnStateChangeListener>> productListeners = new LinkedHashMap<>();

Hang on, hang on! I am guessing you’re wondering why I had to maintain two HashMaps, I’ll explain shortly.

From earlier explanations, we can agree that there is a 1-to-1 relationship between listener and view because each view has its own instance of CartStateListener. The viewListeners HashMap as shown in Fig. 3 below, is a data representation of that listener-view mapping

The productListeners hash on the other hand maintains a bucket of listeners for each specific product because a single product can be listed in many places (views) in the app and each view has its own listener.

For example, from the illustration below, Product A is listed in three places: ProductView #1, ProductView #2 and ProductView N having listeners viewOneListener, viewThreeListener and viewNListener respectively. These means all three listeners have to be aware of changes to the Cart state that affects Product A.

So it’s safe to say the listeners act as some bridge (in the sense of bridge table) between the two maps, linking the product model and the product view.

Every time there is a change to Cart state either because a product is added to the cart or removed, the Cart model publishes these changes by making a call to some notifyAllListeners(product) method passing the specific product as an argument. This is what happens when that call is made:

//Get all the listeners for this specific product
ArrayList<OnStateChangeListener> x = productListeners.get(product);

//For each listener
for (OnStateChangeListener listener: x){

    //Get the view that owns this listener
    View v = viewListeners.get(listener);

    //Trigger update on the subscribed view 
    listener.onStateChange(v);
}

The code below shows what happens in the view

mCartListener = new Cart.OnStateChangeListener() {
    @Override
    public void onStateChange(View productView) {
        //productView gets updated here
    }
};

And voilà, it works!

Possible Optimizations

Since optimize is the name of the game, we always want to look out for ways we could optimize. One I thought of was adding logic to remove listeners from the HashMaps for products not in the user’s view; that way ensuring that the size of the HashMaps don’t grow considerably.

Summary

Knowing when to apply a software design pattern to a specific problem first requires a good understanding of the workings of the specific pattern you want to use and an equally good understanding of the problem you are trying to solve but most importantly, understanding if the software pattern is a good fit for the problem.

I hope that wasn’t too long a read (I bet it was…) but I hope even more that it was worth your time. If there’s a better way you would have implemented this and would like to chat about it or you would love to chat anything else over coffee I hope, feel free to reach out on Twitter @meekg33k.

E go be! ✌️✊✌️