DEV Community: Jim Stoik

The Last Thing You Should Read Before a Full-Stack Interview

Jim Stoik — Fri, 06 Mar 2026 10:30:29 +0000

TL;DR: I condensed years of Staff Engineering interview experience into a 30-minute "panic button" guide. Grab the Fullstack Interview Pocket Guide here.

You know the moment.

It’s 45 minutes before the interview.

Your laptop is open.

Your coffee is getting cold.

Your brain suddenly decides to forget every concept you’ve learned in the last 10 years.

Questions start spinning in your head:

Wait… how exactly do I explain the Event Loop again?
What’s the clean way to describe closures?
Why do I always over-explain useMemo and confuse myself?

You’ve built production systems.

You’ve fixed outages.

You’ve reviewed pull requests for years.

You’ve shipped real software used by real users.

But interviews do something strange to engineers.

They scramble your thoughts.

The real reason good engineers fail interviews

Most engineers don’t fail interviews because they lack knowledge.

They fail because they can’t articulate what they already know under pressure.

Technical interviews are not really knowledge tests.

They are communication tests disguised as technical tests.

Strong candidates don’t just know things.

They explain them:

clearly
calmly
with structure

That’s the difference between someone who knows JavaScript and someone who sounds like a senior engineer.

The problem with most interview prep

Most interview prep material looks like this:

300 page books
endless video courses
deep academic explanations

But right before an interview you don’t need more information.

You need clarity.

You need something that helps you quickly remember:

how to structure answers
how to explain concepts
how to think out loud like an experienced engineer

Something you can read before the interview starts.

The Full-Stack Interview Pocket Guide

So I created something I always wished I had before interviews.

The Full-Stack Engineer Interview Pocket Guide.

You can check it here:

https://jimstoik.gumroad.com/l/Full-Stack-Engineer-Interview-pocket-guide

This is not a course.

It’s the last thing you read before an interview to reset your brain.

Think of it as a mental warm-up for engineers.

Athletes warm up before a match.

Musicians tune their instruments before performing.

This guide does the same thing for your technical thinking.

What makes this guide different

Most interview prep teaches:

“What things are.”

This guide focuses on something much more practical:

How senior engineers explain them during interviews.

Every topic follows the same simple structure.

First: a one-liner.

The kind of answer that immediately shows confidence.

Example:

“A closure is when a function retains access to variables from its lexical scope even after the outer function has finished executing.”

Short. Clear. Direct.

Then comes a clean explanation.

Something structured that you can say calmly without rambling.

After that, the guide explains why interviewers ask the question in the first place.

Because most questions are not about trivia.

They’re about whether you understand:

debugging
performance
scalability
real engineering trade-offs

Finally, it covers common follow-ups and real world trade-offs.

Not theoretical definitions.

The kind of thinking experienced engineers use in real systems.

What’s inside

The guide compresses a lot of common interview topics into a quick refresh format.

JavaScript

The concepts that appear in interviews again and again:

closures
the event loop
promises vs async/await
microtasks vs macrotasks
this binding
immutability
prototypes
async anti-patterns

TypeScript

The things that separate mid engineers from senior ones:

any vs unknown
generics
utility types
discriminated unions
mapped types
as const
React + TypeScript patterns

Node.js & backend fundamentals

Topics backend interviews love:

the Node event loop
libuv basics
streams and backpressure
worker threads
clustering
JWT vs sessions
debugging production crashes
security thinking

React architecture

Common frontend interview discussions:

the virtual DOM
reconciliation
hooks internals
performance optimisation
memoization trade-offs
state management
SSR vs CSR vs SSG

Databases & system design

Simple explanations for:

data modelling
SQL vs NoSQL decisions
scalability thinking
architecture trade-offs

SOLID and design patterns

Not academic definitions.

Just how they actually appear in real codebases.

Behavioural interviews

Because interviews are also about:

communication
ownership
decision making
explaining trade-offs

How to use it

This isn’t meant to be a long study resource.

It’s designed to be used like this.

Full read: about 90 minutes.

Quick refresh: 30–45 minutes before an interview.

The idea is simple:

skim what you already know and focus on areas where your explanations feel weak.

Why this works

Interviewers are not looking for people who memorise documentation.

They look for engineers who can:

explain ideas clearly
reason about trade-offs
stay calm under pressure
think like owners

In other words, people who sound like someone they want to work with.

If you have an interview coming up

Keep the guide somewhere easy to access.

Read it before the interview.

Reset your thinking.

Walk in calm.

You can find it here:

https://jimstoik.gumroad.com/l/Full-Stack-Engineer-Interview-pocket-guide

Final thought

Most engineers already know the material.

They’ve written the code.

They’ve debugged the systems.

They’ve solved the problems.

Sometimes they just need a structured reset before the interview begins.

That’s what this guide is for.

If you're curious, take a look here:

https://jimstoik.gumroad.com/l/Full-Stack-Engineer-Interview-pocket-guide

And if you’ve done a lot of interviews, I’m curious:

what question shows up almost every single time?

Interview in an Hour? Read This Fullstack Pocket Guide.

Jim Stoik — Thu, 22 Jan 2026 12:13:18 +0000

TL;DR: I condensed years of Staff Engineering interview experience into a 30-minute "panic button" guide. Grab the Fullstack Interview Pocket Guide here.

You know that feeling.

It’s 45 minutes before The Big Interview. You’re sitting in your car (or staring at a blank VS Code window), and suddenly, your brain decides to dump every piece of technical knowledge you own.

"Wait, what exactly is the difference between useMemo and useCallback again?"
"Can I explain the Node.js Event Loop without sounding like I'm guessing?"
"What does the 'L' in SOLID stand for?"

You don't have time to read "Cracking the Coding Interview" cover-to-cover. You don't have time to watch a 4-hour Udemy course.

You need a refresh. You need high-signal, low-noise answers.

I wrote the Fullstack Engineer Interview Pocket Guide for exactly this moment. It is designed to be consumed in 30 to 60 minutes. It cuts the fluff and gives you the "Staff Engineer" answers, pragmatic, concise, and technically accurate.

Here is a sneak peek of what’s inside.

⚡️ The 5-Minute Refresher (Samples from the Book)

Here is how we condense complex topics into interview-ready nuggets.

1. JavaScript: The Event Loop (Simplified)

Don't get lost in the weeds. Explain it like this:
JavaScript is single-threaded. It uses the Call Stack to run code, the Web APIs (like setTimeout or fetch) to handle async tasks, and the Callback Queue to hold finished tasks.

The Golden Rule: The Event Loop simply checks: "Is the Call Stack empty?" If yes, it pushes the first item from the Queue to the Stack.
Microtasks (Promises) have priority over Macrotasks (setTimeout).

2. React: `useMemo` vs `useCallback`

Stop mixing them up. It comes down to Value vs. Function.

useMemo: Caches the result of a calculation. Use it when the calculation is expensive (looping millions of items).
useCallback: Caches the function definition itself. Use it to prevent a child component from re-rendering just because a function prop "changed" (reference equality).

3. Database: ACID Properties

If they ask about transactions, just remember:

A (Atomicity): All or nothing. If one part fails, the whole transaction rolls back.
C (Consistency): The DB moves from one valid state to another (constraints are respected).
I (Isolation): Concurrent transactions don't mess with each other.
D (Durability): Once saved, it stays saved. Even if the power goes out.

4. Node.js: The "Single Thread" Myth

Interviewer: "Is Node.js strictly single-threaded?"
Your Answer: "The Event Loop is single-threaded, which makes Node great for I/O-heavy tasks. However, Node uses libuv to offload heavy operations (like file I/O, crypto, or compression) to a pool of worker threads at the C++ level. So, it's single-threaded orchestration, multi-threaded execution."

5. SOLID Principles: The Liskov Substitution Principle (LSP)

The hardest one to explain simply.
The Gist: Subclasses should be substitutable for their base classes.
The "Duck" Test: If it looks like a duck and quacks like a duck but requires batteries, you have the wrong abstraction. If you override a parent method but throw an error because "this subclass doesn't support that method," you violated LSP.

🧠 Behavioral: The STAR Method

Technical skills get you the interview; soft skills get you the job. When asked "Tell me about a time you failed," use the STAR pattern:

Situation (The context)
Task (The goal)
Action (What you specifically did)
Result (The outcome, preferably with numbers)

Why I wrote this guide

I am a Staff Software Engineer who has conducted hundreds of interviews. I realised that most candidates know the code, but they struggle to communicate the concepts clearly under pressure.

I didn't want to write another 400-page textbook. I wanted to create the "Cheat Sheet" I wish I had before every interview.

The Guide Covers:

✅ Modern JavaScript (ES6+) & TypeScript
✅ Node.js Internals
✅ React Patterns & Hooks
✅ Databases (SQL vs NoSQL)
✅ Design Patterns & SOLID
✅ Behavioral Questions & "Red Flags" to avoid

🚀 Get the Edge

Don't let a mental block cost you the offer. Keep this guide on your phone or Kindle. Read it while you wait. Walk into the interview with the confidence of a senior engineer.

👉 Download the Fullstack Engineer Interview Pocket Guide

Good luck. You've got this.

Introduction to Jest: Unit Testing, Mocking, and Asynchronous Code

Jim Stoik — Wed, 30 Oct 2024 22:59:11 +0000

Introduction to Jest

Jest is a library for testing JavaScript code.

It’s an open source project maintained by Facebook, and it’s especially well suited for React code testing, although not limited to that: it can test any JavaScript code. Its strengths are:

it’s fast
it can perform snapshot testing
it’s opinionated, and provides everything out of the box without requiring you to make choices

export default function sum(a, n) {
  return a + b;
}

divide.test.js

import sum from './sum';

// Describe the test and wrap it in a function.
it('adds 1 + 2 to equal 3', () => {
  const result = sum(1, 2);

  // Jest uses matchers, like pretty much any other JavaScript testing framework.
  // They're designed to be easy to get at a glance;
  // here, you're expecting `result` to be 3.
  expect(result).toBe(3);
});

Matchers

A matcher is a method that lets you test values.

toBe compares strict equality, using ===
toEqual compares the values of two variables. If it’s an object or array, it checks the equality of all the properties or elements
toBeNull is true when passing a null value
toBeDefined is true when passing a defined value (opposite to the above)
toBeUndefined is true when passing an undefined value
toBeCloseTo is used to compare floating values, avoiding rounding errors
toBeTruthy true if the value is considered true (like an if does)
toBeFalsy true if the value is considered false (like an if does)
toBeGreaterThan true if the result of expect() is higher than the argument
toBeGreaterThanOrEqual true if the result of expect() is equal to the argument, or higher than the argument
toBeLessThan true if the result of expect() is lower than the argument
toBeLessThanOrEqual true if the result of expect() is equal to the argument, or lower than the argument
toMatch is used to compare strings with regular expression pattern matching
toContain is used in arrays, true if the expected array contains the argument in its elements set
toHaveLength(number): checks the length of an array
toHaveProperty(key, value): checks if an object has a property, and optionally checks its value
toThrow checks if a function you pass throws an exception (in general) or a specific exception
toBeInstanceOf(): checks if an object is an instance of a class

Dependencies

A dependency is a piece of code that your application depends on. It could be a function/Object in our project or a third-party dependency (ex axios)

A piece of code becomes a true dependency when your own application cannot function without it.

For example, if you implement a feature in your application to send email or make api requests or build a configuration object etc

There are two ways that we can add dependencies in our code in a js project:

Imports

import { name, draw, reportArea, reportPerimeter } from './modules/square.js';

Dependency Injection

Just a fancy term on a simple concept.

If your function needs some functionality from an external dependency, just inject it as an argument.

// Constructor Injection

// DatabaseManager class takes a database connector as a dependency
class DatabaseManager {
    constructor(databaseConnector) {
        // Dependency injection of the database connector
        this.databaseConnector = databaseConnector;
    }

    updateRow(rowId, data) {
        // Use the injected database connector to perform the update
        this.databaseConnector.update(rowId, data);
    }
}

// parameter injection, takes a database connector instance in as an argument; easy to test!
function updateRow(rowId, data, databaseConnector) {
    databaseConnector.update(rowId, data);
}

Unit Testing

Unit tests are written and run by software developers to ensure that a section of an application (known as the "unit") meets its design and behaves as intended.

We want to test our code in isolation, we don't care about the actual implementation of any dependencies.
We want to verify

that our unit of code works as expected
returns the expected results
calls any collaborators(dependencies) as it should

And that is where mocking our dependencies comes into play.

Mocking

In unit testing, mocks provide us with the capability to stub the functionality provided by a dependency and a means to observe how our code interacts with the dependency.

Mocks are especially useful when it's expensive or impractical to include a dependency directly into our tests, for example, in cases where your code is making HTTP calls to an API or interacting with the database layer.

It is preferable to stub out the responses for these dependencies, while making sure that they are called as required. This is where mocks come in handy.

By using mock functions, we can know the following:

The number of calls it received.
Argument values used on each invocation.
The “context” or this value on each invocation.
How the function exited and what values were produced.

Mocking in Jest

There are several ways to create mock functions.

The jest.fn method allows us to create a new mock function directly.
If you are mocking an object method, you can use jest.spyOn.
And if you want to mock a whole module, you can use jest.mock.

The jest.fn method is, by itself, a higher-order function.

It's a factory method that creates new, unused mock functions.

Functions in JavaScript are first-class citizens, they can be passed around as arguments.

Each mock function has some special properties. The mock property is fundamental. This property is an object that has all the mock state information about how the function was invoked. This object contains three array properties:

Calls [arguments of each call]
Instances ['this' value on each call]
Results [the value that the function exited], the results property has type(return or throw) and value
- The function explicitly returns a value.
- The function runs to completion with no return statement (which is equivalent to returning undefined
- The function throws an error.

// 1. The mock function factory
function fn(impl = () => {}) {
  // 2. The mock function
  const mockFn = function(...args) {
    // 4. Store the arguments used
    mockFn.mock.calls.push(args);
    mockFn.mock.instances.push(this);
    try {
      const value = impl.apply(this, args); // call impl, passing the right this
      mockFn.mock.results.push({ type: 'return', value });
      return value; // return the value
    } catch (value) {
      mockFn.mock.results.push({ type: 'throw', value });
      throw value; // re-throw the error
    }
  }
  // 3. Mock state
  mockFn.mock = { calls: [], instances: [], results: [] };
  return mockFn;
}

https://codesandbox.io/s/implementing-mock-functions-tkc8b

Mock Basic

test("returns undefined by default", () => {
  const mock = jest.fn();

  let result = mock("foo");

  expect(result).toBeUndefined();
  expect(mock).toHaveBeenCalled();
  expect(mock).toHaveBeenCalledTimes(1);
  expect(mock).toHaveBeenCalledWith("foo");
});

Mocking injected dependencies

const doAdd = (a, b, callback) => {
  callback(a + b);
};

test("calls callback with arguments added", () => {
  const mockCallback = jest.fn();
  doAdd(1, 2, mockCallback);
  expect(mockCallback).toHaveBeenCalledWith(3);
});

Mocking modules

Mock a function with `jest.fn`

import * as app from "./app";
import * as math from "./math";

math.add = jest.fn();
math.subtract = jest.fn();

test("calls math.add", () => {
  app.doAdd(1, 2);
  expect(math.add).toHaveBeenCalledWith(1, 2);
});

test("calls math.subtract", () => {
  app.doSubtract(1, 2);
  expect(math.subtract).toHaveBeenCalledWith(1, 2);
});

This type of mocking is less common for a couple reasons:

jest.mock does this automatically for all functions in a module
jest.spyOn does the same thing but allows restoring the original function

Mock a module with jest.mock

A more common approach is to use jest.mock to automatically set all exports of a module to the Mock Function.

import * as app from "./app";
import * as math from "./math";

// Set all module functions to jest.fn
jest.mock("./math.js");

test("calls math.add", () => {
  app.doAdd(1, 2);
  expect(math.add).toHaveBeenCalledWith(1, 2);
});

test("calls math.subtract", () => {
  app.doSubtract(1, 2);
  expect(math.subtract).toHaveBeenCalledWith(1, 2);
});

Spy or mock a function with jest.spyOn

Sometimes you only want to watch a method be called, but keep the original implementation. Other times you may want to mock the implementation, but restore the original later in the suite.

import * as app from "./app";
import * as math from "./math";

test("calls math.add", () => {
  const addMock = jest.spyOn(math, "add");

  // calls the original implementation
  expect(app.doAdd(1, 2)).toEqual(3);

  // and the spy stores the calls to add
  expect(addMock).toHaveBeenCalledWith(1, 2);
});

Restore the original implementation

// restore the original implementation
  addMock.mockRestore();

Javascript and the Event Loop

JavaScript is single-threaded: only one task can run at a time. Usually that’s no big deal, but now imagine you’re running a task which takes 30 seconds.. Ya.. During that task we’re waiting for 30 seconds before anything else can happen (JavaScript runs on the browser’s main thread by default, so the entire UI is stuck).
It’s 2020, no one wants a slow, unresponsive website.

Luckily, the browser gives us some features that the JavaScript engine itself doesn’t provide: a Web API. This includes the DOM API, setTimeout, HTTP requests, and so on. This can help us create some async, non-blocking behavior

setTimeout(function(){ console.log("Hello"); }, 3000);

Call Stack - When we invoke a function, it gets added to something called the call stack.
WebAPI - setTimeout is provided by the WebAPI, takes a callback function and sets up a timer without blocking the main thread
Queue - when the timer finishes, the callback gets added into the Queue
Event Loop - checks if the call-stack is empty, checks if there are any callbacks to be executed in the Queue, and moves to the call stack to be executed

const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 0);
const baz = () => console.log("Third");

Testing asynchronous code with Jest

Jest typically expects to execute the tests’ functions synchronously.

If we do an asynchronous operation, but we don't let Jest know that it should wait for the test to end, it will give a false positive.

test("this shouldn't pass", () => {
  setTimeout(() => {
    // this should fail:
    expect(false).toBe(true);
  });
});

Asynchronous Patterns
There are several patterns for handling async operations in JavaScript; the most used ones are:

Callbacks
Promises & Async/Await

Testing Callbacks

You can’t have a test in a callback, because Jest won’t execute it - the execution of the test file ends before the callback is called. To fix this, pass a parameter to the test function, which you can conveniently call done. Jest will wait until you call done() before ending that test:

//uppercase.js
function uppercase(str, callback) {
  callback(str.toUpperCase())
}
module.exports = uppercase

//uppercase.test.js
const uppercase = require('./src/uppercase')

test(`uppercase 'test' to equal 'TEST'`, (done) => {
  uppercase('test', (str) => {
    expect(str).toBe('TEST')
    done()
  }
})

Promises

With functions that return promises, we return a promise from the test:

//uppercase.js
const uppercase = str => {
  return new Promise((resolve, reject) => {
    if (!str) {
      reject('Empty string')
      return
    }
    resolve(str.toUpperCase())
  })
}
module.exports = uppercase

//uppercase.test.js
const uppercase = require('./uppercase')
test(`uppercase 'test' to equal 'TEST'`, () => {
  return uppercase('test').then(str => {
    expect(str).toBe('TEST')
  })
})

Async/await

To test functions that return promises we can also use async/await, which makes the syntax very straightforward and simple:

//uppercase.test.js
const uppercase = require('./uppercase')
test(`uppercase 'test' to equal 'TEST'`, async () => {
  const str = await uppercase('test')
  expect(str).toBe('TEST')
})

Tips

We need to have a good understanding of what our function does and what we are about to test
Think about the behaviour of the code that we are testing
Set the stage:
- Mock/Spy on any dependencies
- Is our code interacting with global objects? we can mock/spy on them too
- Are our tests interacting with the DOM? we can build some fake elements to work with
- Structure your tests
- Given ...
- When I call ....
- Then ... I expect.....

describe('first set', () => {
  beforeEach(() => {
    //do something
  })
  afterAll(() => {
    //do something
  })
  test(/*...*/)
  test(/*...*/)
})

describe('second set', () => {
  beforeEach(() => {
    //do something
  })
  beforeAll(() => {
    //do something
  })
  test(/*...*/)
  test(/*...*/)
})

FizzBuzz Typescript & SOLID Principles

Jim Stoik — Sun, 24 May 2020 22:30:39 +0000

"FizzBuzz" is a well-known programming assignment, often used as a little test to see if a candidate for a programming job could manage to implement a set of requirements, usually on the spot. The requirements are these:

Given a list of numbers from 1 to n.
If a number is divisible by 3 should be replaced with Fizz.
If a number is divisible by 5 should be replaced with Buzz.
If a number is divisible by 3 and by 5 should be replaced with FizzBuzz.

Applying these rules, the resulting list would become:

1, 2, Fizz, 4, Buzz … 13, 14, FizzBuzz, 16, 17 …

A simple solution often found online could be something like this:

class FizzBuzz
{
  generate(number: number) {
    let output: string[];
    for (let i = 1; i <= n; i++) {
        output.push(this.getReplacement(i));
    }
    return output;
  }

  getReplacement(number: number): string {
    if (number%3 === 0 && number%5 === 0) return "FizzBuzz";
    if (number%3) return "Fizz";
    if (number%5) return "Buzz";
    else return n;
  }
}

const fizzBuzz = new FizzBuzz();
const result = fizzBuzz.generate(100);
console.log(result.join(", "));

The Class above does the job. And solves the problem, BUT... what if we wanted to introduce a new rule?

For example:

If a number is divisible by 7 should be replaced with Bazz.

FizzBuzz Class and the Open/Closed Principle

If numbers divisible by 7 should one day be replaced with Bazz, it will be impossible to implement this change without actually modifying the code of the FizzBuzz class.

Currently the FizzBuzz class is not open for extension, nor closed for modification. Our current implementation violates the Open/Closed principle

The Open/Closed Principle says that the code should be open for extension but closed for modification. In other words, the code should be organized in such a way that new modules can be added without modifying the existing code.

FizzBuzz Class and the Singe Responsibility Principle

A class should have one, and only one, reason to change.

Our class has two responsibilities, therefore two reasons to change.

it generates a list of numbers and
it generates replacement for each number based on the FizzBuzz Rules

If we think about it. Every responsibility that a class has... is a reason to change.

Re-designing our Class

How can we make our FizzBuzz class more Flexible? What is likely to change?

The FizzBuzz rules are liable to change. And if we want to follow the Open/Closed principle, we should not need to modify the FizzBuzz Class itself.

Lets try to think about the problem we are trying to solve here.

We want to generate a list of numbers, replacing certain numbers with strings, based on a flexible set of "rules".

Lets start by introducing a RuleInterface

interface RuleInterface {
  matches(number: number): boolean;
  getReplacement(): string;
}

and lets extract the rules we need to solve the FizzBuzz challenge into their own classes and have them implement the RuleInterface

class FizzRule implements RuleInterface {
  matches(number: number): boolean {
    return number % 3 === 0;
  }

  getReplacement(): string {
    return "Fizz";
  }
}

class BuzzRule implements RuleInterface {
  matches(number: number): boolean {
    return number % 5 === 0;
  }

  getReplacement(): string {
    return "Buzz";
  }
}

class FizzBuzzRule implements RuleInterface {
  matches(number: number): boolean {
    return number % 3 === 0 && number % 5 === 0;
  }

  getReplacement(): string {
    return "FizzBuzz";
  }
}

And finally, lets make our FizzBuzz Class Open For Extension.

We allow our class to get a list of rules, and build the replacements based on them. These rules must implement the RuleInterface making our code flexible & extensible.

class FizzBuzz {
  rules: RuleInterface[] = [];

  addRule(rule: RuleInterface) {
    this.rules.push(rule);
  }

  generate(number: number) {
    const output: string[] = [];

    for (let i = 1; i <= number; i++) {
      output.push(this.getReplacement(i));
    }

    return output;
  }

  getReplacement(number: number): string {
    for (const rule of this.rules) {
      if (rule.matches(number)) {
        return rule.getReplacement();
      }
    }
    return String(number);
  }
}

const fizBuzz = new FizzBuzz();
fizBuzz.addRule(new FizzBuzzRule());
fizBuzz.addRule(new FizzRule());
fizBuzz.addRule(new BuzzRule());
const result = fizBuzz.generate(20);

// 1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz, 16, 17, Fizz, 19, Buzz
console.log(result.join(", "));

FizzBuzz Class and the Dependency Inversion Principle

The last of the SOLID principles of class design focuses on class dependencies. It tells you what kinds of things a class should depend on:

Depend on abstractions, not on concretions.

The principle tells we should always depend on abstractions(Interfaces, Abstract Classes) and not on concrete implementations.

Applying the Dependency Inversion principle in your code will make it easy for users to swap out certain parts of your code with other parts that are tailored to their specific situation. At the same time, your code remains general and abstract and therefore highly reusable.

By introducing the RuleInterface and adding specific rule classes that implemented this interface, the FizzBuzz class started to depend on more abstract things, called "rules".

When creating a new FizzBuzz instance, concrete implementations of RuleInterface have to be injected in the right order. This will result in the correct execution of the FizzBuzz algorithm.

The FizzBuzz class itself is no longer concerned about the actual rules, which is why the class ends up being more flexible with regard to changing requirements.

Now the hardest part... Naming things!

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Now we have a highly generic piece of code, which “generates a list of numbers, replacing certain numbers with strings, based on a flexible set of rules”.

There is nothing FizzBuzz specific about our class anymore!

Our class is generic and it should be renamed. Maybe something like NumberListReplacer, not ideal, but more generic.

class NumberListReplacer
{
  rules: RuleInterface[] = [];

  addRule(rule: RuleInterface) {
    this.rules.push(rule);
  }

  generate(number: number) {
    let output: string[] = [];

    for (let i = 1; i <= number; i++) {
      output.push(this.getReplacement(i));
    }
    return output;
  }

  getReplacement(number: number): string {
    for (let rule of this.rules) {
      if (rule.matches(number)) {
        return rule.replacement();
      }
    }
    return String(number);
  }
}

const fizBuzz = new NumberListReplacer();
fizBuzz.addRule(new FizzBuzzRule());
fizBuzz.addRule(new FizzRule());
fizBuzz.addRule(new BuzzRule());
const result = fizBuzz.generate(100);


// ex. replace all even numbers with a 'text'
const evenNumberReplacer = new NumberListReplacer();
evenNumberReplacer.addRule(new EvenNumberRule());
const result = evenNumberReplacer.generate(100000);
console.log(result.join(", "));

Links:

Principles of Package Design: Creating Reusable Software Components is a brilliant book by Matthias Noback, it explains the SOLID principles brilliantly(and not only), the idea for the FizzBuzz implementation on example above is taken from there. https://matthiasnoback.nl/book/principles-of-package-design/
https://khalilstemmler.com/articles/solid-principles/solid-typescript/

DEV Community: Jim Stoik

The Last Thing You Should Read Before a Full-Stack Interview

The real reason good engineers fail interviews

The problem with most interview prep

The Full-Stack Interview Pocket Guide

What makes this guide different

What’s inside

JavaScript

TypeScript

Node.js & backend fundamentals

React architecture

Databases & system design

SOLID and design patterns

Behavioural interviews

How to use it

Why this works

If you have an interview coming up

Final thought

Interview in an Hour? Read This Fullstack Pocket Guide.

⚡️ The 5-Minute Refresher (Samples from the Book)

1. JavaScript: The Event Loop (Simplified)

2. React: useMemo vs useCallback

3. Database: ACID Properties

4. Node.js: The "Single Thread" Myth

5. SOLID Principles: The Liskov Substitution Principle (LSP)

🧠 Behavioral: The STAR Method

Why I wrote this guide

🚀 Get the Edge

Introduction to Jest: Unit Testing, Mocking, and Asynchronous Code

Introduction to Jest

Matchers

Dependencies

Imports

Dependency Injection

Unit Testing

Mocking

Mocking in Jest

Mock Basic

Mocking injected dependencies

Mocking modules

Mock a function with jest.fn

Mock a module with jest.mock

Spy or mock a function with jest.spyOn

Javascript and the Event Loop

Testing asynchronous code with Jest

Testing Callbacks

Promises

Async/await

Tips

Links

FizzBuzz Typescript & SOLID Principles

FizzBuzz Class and the Open/Closed Principle

FizzBuzz Class and the Singe Responsibility Principle

Re-designing our Class

FizzBuzz Class and the Dependency Inversion Principle

Now the hardest part... Naming things!

2. React: `useMemo` vs `useCallback`

Mock a function with `jest.fn`