TL;DR — Using AI during coding interviews is the most polarizing topic in tech hiring right now. I’ve heard every argument on both sides — and I’ve had to wrestle with them more than most, because I actually built a tool that does exactly this. This article isn’t a defense or an attack. It’s the real debate, with the strongest arguments from each side, and where I’ve landed after sitting with it for a long time.

A few months ago, I published an article about how I made a desktop app invisible to screen sharing. The technical content did well, but I knew what the real conversation would be about. Not the rendering tricks or the Electron APIs — the ethics. The inevitable questions: is this helping people lie their way into jobs? Will it get unqualified devs hired and ruin teams?

Fair questions. All of them.

I teased in an earlier article that the ethics conversation deserved its own space. So here it is. Not a hot take. Not a defensive rant from someone protecting their project. A genuine attempt to lay out both sides of this debate with the seriousness they deserve — and then tell you exactly where I stand.

Because I think the worst thing anyone can do with a topic like this is be wishy-washy about it.

The Elephant in the Room: I Have Skin in This Game

Before anything else, let me be transparent about something.

I built Ezzi. It’s an open-source desktop application that provides AI-powered assistance during technical interviews through an invisible overlay. I designed it. I wrote a lot of the code. I put it out there under an MIT license for anyone to use.

So when I write about the ethics of AI coding assistants in interviews, I’m not a neutral observer. I’m someone who actively contributed to the thing people are debating about.

I say this upfront because I think intellectual honesty matters — especially on a topic like this. You should know my bias going in. And I should be willing to name it.

That said, having skin in the game also means I’ve spent more time thinking about these implications than most commenters dropping hot takes on Twitter. I’ve been turning this question over in my head since I started building the thing — most often at 2 AM, staring at my commit history.

Let me walk you through that debate.

The Case Against: Why Using AI in Interviews Is Cheating

I’m going to start with the strongest arguments against using tools like Ezzi in interviews. And I mean the genuinely strong ones — not the strawmen that are easy to dismiss.

It’s Fundamentally Deceptive

This is the hardest argument to counter, and I want to give it the respect it deserves.

When you sit down for a coding interview, there’s an implicit agreement. The interviewer believes they’re evaluating your abilities — your problem-solving, your coding skills, and your ability to think under pressure. When you use an AI assistant they can’t see, you’re breaking that agreement.

It doesn’t matter if the tool is just “helping you think.” It doesn’t matter if you “already knew the answer.” The interviewer didn’t consent to evaluating you plus an AI. They consented to evaluating you.

This is a real argument. Deception is deception, regardless of whether you think the system being deceived is fair.

It Undermines Meritocracy

Tech has always prided itself — sometimes naively — on being a meritocracy. The idea that anyone with the skills can get the job, regardless of their background, pedigree, or connections.

If AI interview tools become widespread, you introduce a new variable: who has access to the best tools, who knows they exist, and who’s comfortable using them. That’s not meritocracy. That’s a different kind of advantage that has nothing to do with engineering ability.

The dev who grinds LeetCode for three months and solves the problem on their own gets the same result as the dev who opens an overlay and copies the AI’s approach. Except one of them actually demonstrated the skill.

It Hurts Candidates Who Don’t Use Tools

This one keeps me up at night more than the others.

If AI-assisted interviewing becomes normalized — even quietly — you create a prisoners’ dilemma. Candidates who refuse to use these tools on principle are now competing against candidates who do. The “honest” candidates are actively disadvantaged.

That’s not a hypothetical. That’s game theory. And the equilibrium it reaches is one where everyone feels pressured to use the tools just to keep up, regardless of their personal ethics.

It Could Lead to Genuinely Unqualified Hires

Let’s not dance around this one. If someone who can’t actually code uses AI to pass a technical interview and gets hired, that’s bad for everyone involved — the team that carries the weight, the company that made a costly mis-hire, and the person themselves, because they’ll be exposed eventually.

The argument isn’t that this happens every time. The argument is that it can happen, and when it does, the consequences are real. Teams carry dead weight. Projects suffer. And the person who got hired under false pretenses lives in constant anxiety.

The Slippery Slope Is Real

Today it’s coding interviews. Tomorrow it’s design reviews. Next week it’s architecture discussions in your actual job. If we normalize hiding AI assistance, where does it stop?

There’s a legitimate concern that accepting AI cheating in interviews sends a cultural signal: it’s okay to misrepresent your abilities as long as you get the outcome you want.

I’ve laid these out as strongly as I can because I think they deserve it. If you read those arguments and thought “yeah, that’s pretty convincing” — good. They should be. They represent real concerns from real people who care about the integrity of the hiring process.

Now let me show you the other side.

The Case For: Why the System Is Already Broken

The Interview Doesn’t Measure What It Claims To

Let’s start with the foundational crack in the whole argument: coding interviews, as they exist today, are terrible at predicting job performance.

This isn’t my opinion. Google’s own internal research found that their interview scores had almost no correlation with on-the-job performance. They published this. They admitted it publicly.

The average coding interview asks you to solve algorithmic puzzles under time pressure, on a shared screen, while a stranger watches you type. When was the last time your actual job looked like that?

At work, you Google things and read documentation. You ask colleagues, use Copilot or ChatGPT, and take breaks when you need them. You think about a problem overnight and come back with a solution in the morning.

The interview strips away every single tool and process that makes you effective at your actual job, then judges you on the result. It’s like evaluating a carpenter by making them build a cabinet with no power tools and one hand tied behind their back, then concluding they “lack craftsmanship.”

Companies Already Use AI on Their Side

Here’s the double standard nobody wants to acknowledge.

Companies use AI to screen your resume before a human ever sees it and to generate interview questions. Some even analyze your facial expressions during video calls, and their code graders were built with AI assistance.

But you — the candidate — are expected to show up with nothing but your brain and your typing speed.

The power asymmetry is staggering. The company brings every tool in its arsenal to evaluate you, while insisting you face the evaluation naked. And then we call it “fair”.

Memorizing LeetCode Is Already “Cheating” — We Just Don’t Call It That

Let me ask you something. A candidate spends three months grinding LeetCode. They encounter a problem in their interview that they’ve already solved before — maybe multiple times. They reproduce the solution from memory.

Is that cheating?

Most people would say no. That’s preparation. That’s hard work. That’s the game.

But what exactly did that demonstrate? Not problem-solving ability — they already knew the answer. Not the ability to think under pressure — they were just recalling a pattern. Not engineering skill — LeetCode problems have almost nothing to do with building real software.

What it demonstrated is that they had the time, resources, and awareness to grind a specific platform for months. That’s a socioeconomic filter, not a skills filter.

A candidate who works a full-time job and has kids at home doesn’t have three months to grind LeetCode. They have evenings, maybe weekends, and whatever energy is left after everything else.

We’ve already accepted a version of “cheating” — we just drew the line in a place that advantages certain people and pretends that’s merit.

Preparation Has Always Been a Spectrum

Think about this spectrum for a moment:

• Reading a book about algorithms before an interview. Nobody objects to this.
• Practicing on LeetCode with hundreds of problems, including ones known to appear at specific companies. Still considered fine.
• Doing mock interviews with a friend who works at the target company and can hint at what topics will come up. Happens constantly.
• Paying for a coaching service that teaches you company-specific patterns. This costs $200–500/hour, and nobody bats an eye.
• Using ChatGPT to explain a concept you don’t understand while prepping the night before. Broadly accepted in 2026.
• Using an AI tool during the actual interview to assist with problem-solving. Suddenly this is where everyone draws the line?

Where’s the line? Everyone draws it somewhere different, and everyone thinks their line is the obvious one.

The Job Doesn’t Require What the Interview Tests

This is the argument I keep coming back to.

If I hire a dev to build features, fix bugs, and maintain a codebase — and in that actual job, they’ll have access to AI tools, documentation, their team, and the internet — then what am I actually learning by testing them without any of those things?

I’m testing their ability to perform in an artificial environment that doesn’t exist anywhere in professional software development.

You know what would be a better interview? Give someone a real task. Let them use whatever tools they want. Judge the output. That’s closer to what they’ll actually do at the job.

But companies don’t do this because it’s harder to standardize, harder to scale, and harder to evaluate. So they stick with the format they have, even tho they know it doesn’t work, and then act shocked when people optimize around it.

The Arguments Nobody Makes (But Should)

Before I tell you where I land, there are a few points that usually get lost in this debate.

The “Unqualified Hire” Problem Is Overstated

People love the scenario where someone who can’t code at all uses AI to get hired and then gets exposed. And sure, that can happen.

But here’s the thing — it also happens without AI. People lie on resumes, get referrals from friends and coast through interviews, or freeze and bomb them despite being excellent engineers. The signal-to-noise ratio of interviews has always been terrible.

The question isn’t whether AI tools introduce the possibility of bad hires. It’s whether they make it meaningfully worse than the already-broken system.

And if a company’s entire quality gate is a single technical interview that can be defeated by a tool, the problem isn’t the tool. It’s the gate.

Companies Could Fix This Tomorrow

If companies are genuinely worried about AI-assisted interviews, they have options.

They could do take-home projects with follow-up discussions. They could do pair programming sessions focused on collaboration, not performance. They could use trial periods or contract-to-hire arrangements. They could ask candidates to explain existing code instead of writing new code. They could evaluate portfolios, open-source contributions, and real work.

Most companies don’t do these things because they’re expensive and time-consuming. They’d rather keep the cheap, broken format and blame candidates for optimizing around it.

That tells you everything you need to know about how seriously companies take interview integrity.

The AI Genie Is Out of the Bottle

This is the pragmatic argument, and it’s powerful even if it’s uncomfortable.

AI coding assistants exist. They’re getting better. They’re not going away. Within five years, every developer will use AI tools as naturally as they use an IDE today.

Building a hiring process that depends on candidates not having access to AI is like building a hiring process in 2010 that depends on candidates not having access to Google. It’s a losing bet.

The companies that adapt their interviews to account for AI will hire better. The companies that try to police it will waste energy on an unwinnable arms race while their interview process becomes even less predictive than it already is.

Where I Land

Okay. I’ve presented both sides as honestly as I can. Here’s my actual position.

I think the current coding interview system is broken beyond repair, and AI tools are a symptom of that brokenness, not the cause.

I think using AI during an interview, in its current form, is deceptive. I won’t pretend otherwise. The interviewer expects to evaluate you without assistance, and using a hidden tool violates that expectation. That’s a real ethical issue, and I don’t dismiss it.

But I also think the system those interviews exist in is itself deeply unfair, and has been for years. It advantages people with time, money, and access. It tests skills that don’t predict job performance. And it creates artificial conditions that don’t exist anywhere in actual software engineering.

So here’s my specific stance: The moral weight of using AI in an interview is proportional to the fairness of the interview itself.

If a company gives you a thoughtful, realistic assessment — a take-home project, a pair programming session, a system design discussion where they genuinely care about how you think — using AI to fake your way through that is wrong. Full stop. That company made an effort to evaluate you fairly, and you’re undermining it.

But if a company throws you into a 45-minute LeetCode grinder as an early elimination round — one that can knock you out before you ever get to show your system design thinking or how you work with a team? The moral calculus shifts. That interview wasn’t designed to evaluate you fairly. It was designed to be cheap and scalable. Optimizing around it — by any means — is a rational response to an irrational system.

I’m not saying it’s right. I’m saying the wrongness is shared.

Why I Built Ezzi Anyway

The obvious question hangs over the whole project: if you see the ethical issues, why build it?

Because I think tools like Ezzi have a role that goes beyond the interview itself.

When I started working on Ezzi, the primary use case in my head wasn’t “help people cheat.” It was “help people learn.” The AI-powered overlay can explain concepts, walk through approaches, and help someone understand why a solution works — not just what the solution is.

Used as a learning aid — during practice sessions, during LeetCode grinding, during mock interviews — it’s genuinely useful. It’s like having a patient tutor who can explain dynamic programming for the fifteenth time without getting frustrated.

Does it also work during real interviews? Yes. I designed the invisible overlay specifically to work in that context. And I’m not going to pretend I didn’t know what people would use it for.

But I don’t think the tool is the problem. The ethics live in the use, not the existence.

That’s my position, and I hold it knowing full well that some people will disagree — loudly.

What Interviews Should Actually Look Like

I don’t want to just criticize without offering something constructive. Here’s what I think good technical hiring looks like:

Evaluate real work. Look at someone’s GitHub. Read their blog posts. Review a project they built. This tells you more about someone’s engineering ability than any whiteboard problem.

Test collaboration, not isolation. Pair programming sessions where you work together on a problem. How do they communicate? How do they handle getting stuck? How do they respond to feedback? These are the skills that actually matter on the job.

Let candidates use their tools. If a candidate will use AI tools on the job — and they will — let them use AI tools in the interview. Evaluate their ability to leverage those tools effectively. That’s a skill too.

Use longer, realistic assessments. A paid take-home project that resembles actual work. A trial day where they work on a real (sanitized) problem. These are more expensive, yes. But they actually work.

Focus on the conversation, not the code. Ask a candidate to explain their approach, their tradeoffs, their reasoning. That’s much harder to fake with AI than the code itself.

Some companies already do this. They’re the ones making the best hires. They’re also the ones who don’t need to worry about AI interview tools, because their process tests things AI can’t fake.

The Uncomfortable Truth

Here’s the thing nobody wants to say out loud.

The debate about AI in interviews isn’t really about AI. It’s about the fact that our industry built a hiring process that doesn’t work, made it the standard, and now doesn’t know what to do when technology exposes how fragile it is.

Candidates didn’t break the system. They’re just responding to the incentives the system created. When you make the hiring gate a performance that can be gamed, people will game it. With LeetCode grinding. With coaching services. With AI tools. With whatever the next thing is.

If we want to fix this, we need to stop blaming the people trying to get hired and start fixing the process that hires them.

That’s where the conversation should be. Not “should candidates be allowed to use AI?” but “why is our interview process so vulnerable to AI that it breaks?”

If you want to check out Ezzi yourself — whether as a learning aid, a practice tool, or just to see how the invisible overlay works under the hood — it’s open source and free: github.com/GetEzzi/ezzi-app

This is a debate that’s going to get louder, not quieter. I’d love to hear where you land — especially if you disagree with me. The comment section is open. Let’s have the conversation the industry keeps avoiding.

I hope this was helpful. Good luck, and happy engineering!

AI Coding Assistants During Interviews: The Ethics Nobody Wants to Talk About was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR — Building a desktop overlay that’s invisible to screen sharing requires going deeper than Electron’s surface-level APIs. You need to understand how each OS captures windows, use the right combination of BrowserWindow properties, handle platform-specific edge cases (especially macOS Zoom), and manage focus behavior so the overlay doesn’t leave traces. This article walks through the actual techniques I used building Ezzi.

The Problem

Here’s the situation. You’re building a desktop overlay — an always-on-top transparent window that floats above other applications. Maybe it’s a productivity tool, a note-taking overlay, a teleprompter, or in my case, an interview assistant called Ezzi.

The overlay needs to be visible to the user but completely invisible when they share their screen. Not “mostly hidden.” Not “kinda transparent.” Invisible. As in the person on the other end of the screen share sees absolutely nothing.

This sounds simple until you actually try to do it. And then you discover that “invisible to screen sharing” means different things on different operating systems, different video conferencing apps, and different capture methods.

Let me walk you through how I solved this.

How Screen Sharing Actually Works

Before we can hide from screen capture, we need to understand how screen capture works. And it’s different on every platform.

Windows: Three Capture APIs

Windows has evolved its screen capture APIs over the years. Modern apps use one of three approaches.

BitBlt (Legacy)

The oldest method. BitBlt copies pixels from one device context to another. Many older screen recording tools still use this. It operates on the GDI layer and captures whatever’s rendered to the screen device context.

Desktop Duplication API (DXGI)

Introduced in Windows 8. This is what most modern screen sharing apps use — Zoom, Teams, Discord. It captures the final composited desktop output directly from the GPU, which means it sees everything the DWM (Desktop Window Manager) composites together.

Windows Graphics Capture (WGC)

The newest API, introduced in Windows 10. This is what UWP apps and newer tools use. It can capture specific windows or the entire screen, and it’s the most “aware” of window properties and system policies.

The key thing here: all three methods respect a Windows API called SetWindowDisplayAffinity. This is our way in.

macOS: CGWindowListCreateImage and ScreenCaptureKit

macOS screen capture is conceptually simpler but has its own complications.

The traditional approach uses CGWindowListCreateImage, which composites windows into a single image. Apps specify which windows to include using various option flags. Most screen sharing tools on macOS use this under the hood.

Apple introduced ScreenCaptureKit in macOS 12.3 as a more modern alternative. It provides filter-based capture where apps can include or exclude specific windows and applications. Think of it as a query-based approach to screen capture — you describe what you want, and the system delivers it.

On macOS, the equivalent mechanism is the window’s sharingType property. Setting it to NSWindowSharingNone tells the window server to exclude the window from capture operations.

Both APIs respect this property. But — and this is a significant “but” — some apps have historically used more aggressive capture methods that bypass it. More on that when we get to the Zoom problem.

The Electron Foundation

Ezzi is built with Electron 37+ and React 19+. The overlay is an Electron BrowserWindow with a very specific set of properties. Let me walk through the ones that matter.

The Base Window Configuration

In Ezzi, the window config lives in a dedicated config file. Here’s what the base settings look like for the Live Interview mode:

// electron/window-config/configs/LiveInterviewConfig.ts
export const LiveInterviewConfig: WindowConfig = {
  baseSettings: {
    width: 500,
    height: 420,
    alwaysOnTop: true,
    show: true,
    fullscreenable: false,
    focusable: true,
    enableLargerThanScreen: true,
    frame: false,
    hasShadow: false,
    transparent: true,
    skipTaskbar: true,
    titleBarStyle: 'hidden',
    backgroundColor: '#00000000',
    type: 'panel',
    paintWhenInitiallyHidden: true,
    movable: true,
  },
  // ...behavior configs
};

Let’s break down why each property matters.

transparent: true with backgroundColor: ‘#00000000’ makes the window fully transparent. The #00000000 is ARGB with zero alpha. Without this combo, you get a white or system-colored rectangle. Not very invisible.

frame: false with titleBarStyle: ‘hidden’ removes the native window frame entirely. No title bar, no close/minimize/maximize buttons.

hasShadow: false is a macOS-specific detail. Windows get a subtle drop shadow by default. Even a transparent window can cast a shadow, and that shadow shows up in screen captures.

type: ‘panel’ is one of the less obvious but important settings. On macOS, this creates a panel-style window that behaves differently from a regular window. Panels don’t appear in the Dock’s window list and have different focus behavior — they can float above other apps without stealing the active state.

skipTaskbar: true hides the window from the Windows taskbar. You don’t want a mysterious app icon appearing while someone’s watching your screen.

enableLargerThanScreen: true lets the window extend beyond the screen edges. This is useful when moving the overlay around — you don’t want it snapping back when it partially goes off-screen.

The window creation in the main process then merges these settings with platform-specific options:

// electron/main.ts
const windowsSpecificOptions =
  process.platform === 'win32' && platformConfigForCreation.win32
    ? { thickFrame: platformConfigForCreation.win32.thickFrame }
    : {};

const baseWindowSettings: Electron.BrowserWindowConstructorOptions = {
  ...windowConfig.baseSettings,
  ...windowsSpecificOptions,
  x: state.currentX,
  y: 50,
  webPreferences: {
    nodeIntegration: false,
    contextIsolation: true,
    preload: isDev
      ? path.join(__dirname, '../dist-electron/preload.js')
      : path.join(__dirname, 'preload.js'),
    scrollBounce: true,
  },
};

state.mainWindow = new BrowserWindow(baseWindowSettings);t

Notice thickFrame: false on Windows. This disables the Windows “thick frame” style that allows resizing from the edges. Without it, Windows would render resize handles around the window — visible artifacts on a supposedly invisible overlay.

This gives you a transparent, frameless, always-on-top window. But it’s still visible to screen capture. The next step is the critical one.

The Invisibility Switch

Right after creating the window, we apply the three core protection calls:

// electron/main.ts
state.mainWindow.setContentProtection(true);
state.mainWindow.setVisibleOnAllWorkspaces(true, {
  visibleOnFullScreen: true,
});
state.mainWindow.setAlwaysOnTop(true, 'screen-saver', 1);

setContentProtection(true) is the core mechanism. Under the hood, it does platform-specific work.

On Windows, it calls:

// What Electron does internally on Windows
SetWindowDisplayAffinity(hwnd, WDA_EXCLUDEFROMCAPTURE);

WDA_EXCLUDEFROMCAPTURE was introduced in Windows 10. It tells the DWM to exclude this window from all capture operations. The window simply doesn’t exist as far as screen sharing is concerned.

Before this flag existed, the older WDA_MONITOR flag was the only option. It would replace the window content with a black rectangle in captures rather than making it fully invisible. WDA_EXCLUDEFROMCAPTURE is strictly better — the window doesn’t show up at all, not even as a blank region.

On macOS, it calls:

// What Electron does internally on macOS
[nsWindow setSharingType:NSWindowSharingNone];

NSWindowSharingNone tells the window server that this window should not be included in any screen sharing or capture operations. It’s been available since early macOS versions, tho the behavior has evolved across different macOS releases.

The interesting part is that this is a single Electron API call abstracting away two completely different OS-level mechanisms. You don’t need to write native code or use node-ffi. Electron handles the platform dispatch.

The Always-On-Top Level

Setting alwaysOnTop: true in the constructor is just the starting point. Electron lets you specify the *level* of always-on-top, and the level matters a lot. In Ezzi, all visibility states use ’screen-saver’:

// electron/window-config/configs/LiveInterviewConfig.ts
showBehavior: {
  opacity: 1,
  ignoreMouseEvents: false,
  skipTaskbar: true,
  alwaysOnTop: true,
  alwaysOnTopLevel: 'screen-saver',
  visibleOnAllWorkspaces: true,
  visibleOnFullScreen: true,
  focusable: true,
  contentProtection: true,
},

Electron supports several window levels: ’normal’, ’floating’, ’torn-off-menu`, ’modal-panel’, ’main-menu’, ’status’, ’pop-up-menu’, and ’screen-saver’.

For an interview overlay, you want it above everything — including the full-screen mode that some interview platforms use. ’screen-saver’ is the highest level before system-level windows, so it stays on top even when the interview platform goes full-screen.

The visibleOnAllWorkspaces: true with visibleOnFullScreen: true ensures the overlay persists across all macOS virtual desktops and doesn’t disappear when another app enters full-screen mode.

Config-Driven Visibility States

One design decision that paid off was treating visibility as a configuration problem rather than scattering setContentProtection and setIgnoreMouseEvents calls throughout the codebase.

Ezzi defines a WindowVisibilityConfig type:

// electron/window-config/WindowConfig.ts
export interface WindowVisibilityConfig {
  opacity: number;
  ignoreMouseEvents: boolean;
  skipTaskbar: boolean;
  alwaysOnTop: boolean;
  alwaysOnTopLevel:
    | 'normal'
    | 'floating'
    | 'torn-off-menu'
    | 'modal-panel'
    | 'main-menu'
    | 'status'
    | 'pop-up-menu'
    | 'screen-saver';
  visibleOnAllWorkspaces: boolean;
  visibleOnFullScreen: boolean;
  focusable: boolean;
  contentProtection: boolean;
}

Then a factory applies these configs atomically:

// electron/window-config/WindowConfigFactory.ts
private applyVisibilityConfig(
  window: BrowserWindow,
  config: WindowVisibilityConfig,
): void {
  const currentBounds = window.getBounds();

  if (config.ignoreMouseEvents) {
    window.setIgnoreMouseEvents(true, { forward: true });
  } else {
    window.setIgnoreMouseEvents(false);
  }
  window.setFocusable(config.focusable);
  window.setSkipTaskbar(config.skipTaskbar);
  window.setAlwaysOnTop(config.alwaysOnTop, config.alwaysOnTopLevel, 1);
  window.setVisibleOnAllWorkspaces(config.visibleOnAllWorkspaces, {
    visibleOnFullScreen: config.visibleOnFullScreen,
  });
  window.setContentProtection(config.contentProtection);
  window.setOpacity(config.opacity);

  window.setBounds(currentBounds);
}

Notice the setBounds(currentBounds) at the end. Without it, some Electron API calls can subtly shift the window position or size. Saving and restoring the bounds ensures the window stays exactly where it was.

This approach means every visibility state — show, hide, queue with screenshots, queue empty — is a declarative config object. Adding a new state means adding a new config, not tracking down scattered imperative calls.

Click-Through Transparency

An invisible overlay is useless if it blocks mouse interaction with the apps underneath. You need the overlay to be “click-through” — mouse events should pass right through it to whatever window is below.

Look at the ignoreMouseEvents field in the config. It switches between states depending on what the user is doing:

// electron/window-config/configs/LiveInterviewConfig.ts
showBehavior: {
  ignoreMouseEvents: false,  // interactive - user can click the overlay
  focusable: true,
  // ...
},
hideBehavior: {
  ignoreMouseEvents: true,   // click-through - events pass to app below
  focusable: true,
  // ...
},
queueWithScreenshots: {
  ignoreMouseEvents: true,   // click-through while displaying screenshots
  focusable: false,          // also not focusable at all
  // ...
},

The { forward: true } option passed to setIgnoreMouseEvents(true, { forward: true }) is important on macOS. Without it, the window simply stops receiving mouse events entirely. With it, mouse events are forwarded to the window below, but the overlay still receives mouse enter/leave events for hover detection.

The toggle between states happens via Cmd+B:

// electron/shortcuts.ts
globalShortcut.register('CommandOrControl+B', () => {
  this.deps.toggleMainWindow();
});

Which triggers this:

// electron/main.ts
let isToggling = false;
function toggleMainWindow(): void {
  if (isToggling) {
    return;
  }

  isToggling = true;

  if (state.isWindowVisible) {
    hideMainWindow();
  } else {
    showMainWindow();
  }

  setTimeout(() => {
    isToggling = false;
  }, 300);
}

The debounce is important. Without it, rapid key presses can trigger multiple show/hide transitions that get the window into a confused state. The 300ms cooldown prevents this.

Press Cmd+B to interact with the overlay. Press it again to make it click-through. This keeps the user’s interaction with the interview platform natural — they’re not alt-tabbing between windows, which would look suspicious.

Focus Detection Prevention

Here’s a subtle problem that most people miss when building overlays. Even if your window is invisible to screen capture, it can still be detected through focus behavior.

Interview platforms can monitor which window has focus. If your overlay steals focus when it becomes interactive, the interview platform detects that its window lost focus — a potential red flag.

What Interview Platforms Can See

Browser-based interview platforms typically monitor two things:

// What interview platforms might run
document.addEventListener('blur', () => {
  reportFocusLoss() // "User switched away from this tab"
})

document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    reportTabSwitch() // "Tab is no longer visible"
  }
})

The blur event fires when the browser window loses focus to another application. The visibilitychange event fires when the tab becomes hidden (e.g., the user switches to a different tab).

How We Handle Focus

The key insight is in how Ezzi shows the window. Look at this line in showMainWindow():

// electron/main.ts
function showMainWindow(): void {
  if (!state.mainWindow?.isDestroyed()) {
    if (state.windowPosition && state.windowSize) {
      state.mainWindow.setBounds({
        ...state.windowPosition,
        ...state.windowSize,
      });
    }

    const configFactory = WindowConfigFactory.getInstance();

    state.mainWindow.setOpacity(0);
    state.mainWindow.showInactive();  // <-- this is the key

    // Apply appropriate behavior based on current view
    configFactory.applyShowBehavior(state.mainWindow, state.appMode);

    state.isWindowVisible = true;
    state.shortcutsHelper?.registerAllShortcuts();
  }
}

showInactive() instead of show(). This is the critical difference. show() activates the window and gives it focus. showInactive() makes the window visible without stealing focus from the currently active application. The browser running the interview platform stays focused.

The opacity trick (setOpacity(0) before showing, then restored to 1 by the config) prevents a brief visual flash during the state transition.

On top of this, Ezzi re-applies platform-specific configurations whenever the window gains focus, to prevent the OS from overriding our settings:

// electron/main.ts
function handleWindowFocus(): void {
  preserveWindowConfiguration();
}

function preserveWindowConfiguration(): void {
  if (!state.mainWindow || state.mainWindow.isDestroyed()) {
    return;
  }

  const windowConfig = WindowConfigFactory.getInstance().getConfig(
    state.appMode,
  );
  const platformConfig = windowConfig.behavior.platformSpecific;

  if (process.platform === 'darwin' && platformConfig.darwin) {
    state.mainWindow.setWindowButtonVisibility(
      platformConfig.darwin.windowButtonVisibility,
    );
    state.mainWindow.setHiddenInMissionControl(
      platformConfig.darwin.hiddenInMissionControl,
    );
    state.mainWindow.setBackgroundColor(platformConfig.darwin.backgroundColor);
    state.mainWindow.setHasShadow(platformConfig.darwin.hasShadow);
  }

  if (process.platform === 'win32' && platformConfig.win32) {
    state.mainWindow.setMenuBarVisibility(false);
    state.mainWindow.setAutoHideMenuBar(true);
  }
}

Why re-apply on every focus gain? Because macOS and Windows can reset certain window properties during focus transitions. I learned this the hard way — the overlay would occasionally appear with a shadow or window buttons after the system handled a focus event. Re-applying the config on focus ensures consistency.

Platform-Specific Hiding

On macOS, there’s extra work to truly hide the window from the system UI:

// electron/window-config/configs/LiveInterviewConfig.ts
platformSpecific: {
  darwin: {
    hiddenInMissionControl: true,
    windowButtonVisibility: false,
    backgroundColor: '#00000000',
    hasShadow: false,
  },
  win32: {
    thickFrame: false,
  },
},

hiddenInMissionControl: true prevents the overlay from appearing in Mission Control (the three-finger-swipe-up view). Without this, swiping up during an interview would reveal the overlay window.

Why Native Windows Beat Browser Extensions

This is actually one of the key advantages of a native desktop overlay vs. a browser extension approach. Browser extensions that open new tabs, pop-ups, or iframes can trigger visibilitychange and blur events. A native Electron window sitting on top of the browser does not trigger visibilitychange at all — the browser tab is still technically visible and in the foreground.

The blur event is the one we need to manage carefully. And because we control the Electron window’s focus behavior at the OS level — with showInactive(), type: ‘panel’, and careful focus event handling — we have the tools to do it properly.

Shortcut-Based Interaction Model

Ezzi’s entire interaction model is built on global keyboard shortcuts. This isn’t just a convenience — it’s a stealth requirement. Every mouse click on the overlay risks a focus change. Keyboard shortcuts don’t.

Here’s the full shortcut registration:

// electron/shortcuts.ts
public registerAllShortcuts(): void {
  globalShortcut.unregisterAll();

  globalShortcut.register('CommandOrControl+H', () => {
    void (async () => {
      const mainWindow = this.deps.getMainWindow();
      if (mainWindow) {
        const screenshotPath = await this.deps.takeScreenshot();
        const preview = await this.deps.getImagePreview(screenshotPath);
        mainWindow.webContents.send('screenshot-taken', {
          path: screenshotPath,
          preview,
        });
      }
    })();
  });

  globalShortcut.register('CommandOrControl+Enter', () => {
    void this.deps.processingHelper?.processScreenshotsSolve();
  });

  globalShortcut.register('CommandOrControl+G', () => {
    this.deps.processingHelper?.cancelOngoingRequests();
    this.deps.clearQueues();
    this.deps.setView('queue');
    const mainWindow = this.deps.getMainWindow();
    if (mainWindow && !mainWindow.isDestroyed()) {
      mainWindow.webContents.send('reset-view');
    }
  });

  globalShortcut.register('CommandOrControl+Left', () => {
    this.deps.moveWindowLeft();
  });
  globalShortcut.register('CommandOrControl+Right', () => {
    this.deps.moveWindowRight();
  });
  globalShortcut.register('CommandOrControl+Down', () => {
    this.deps.moveWindowDown();
  });
  globalShortcut.register('CommandOrControl+Up', () => {
    this.deps.moveWindowUp();
  });

  globalShortcut.register('CommandOrControl+B', () => {
    this.deps.toggleMainWindow();
  });
}

But here’s the important detail — when the window is hidden, we unregister everything except Cmd+B:

// electron/shortcuts.ts
public registerVisibilityShortcutOnly(): void {
  globalShortcut.unregisterAll();

  setTimeout(() => {
    globalShortcut.register('CommandOrControl+B', () => {
      this.deps.toggleMainWindow();
    });
  }, 500);
}

The 500ms delay prevents a race condition where unregistering and re-registering the same shortcut too quickly can fail silently in Electron.

Why unregister shortcuts when hidden? Two reasons. First, it frees up key combinations like Cmd+H and Cmd+G for other apps. Second, it prevents accidental actions — you don’t want a stray Cmd+Enter generating a solution while the overlay is hidden.

Window Movement and Dynamic Sizing

An overlay that can’t be repositioned is impractical. But window movement introduces its own challenges.

Keyboard-Driven Positioning

Instead of drag-to-move (which requires the window to be interactive and focused), Ezzi uses keyboard shortcuts. The movement functions handle horizontal and vertical axes differently:

// electron/main.ts
state.step = 60; // pixels per move

function moveWindowHorizontal(updateFn: (x: number) => number): void {
  if (!state.mainWindow) {
    return;
  }
  state.currentX = updateFn(state.currentX);
  state.mainWindow.setPosition(
    Math.round(state.currentX),
    Math.round(state.currentY),
  );
}

function moveWindowVertical(updateFn: (y: number) => number): void {
  if (!state.mainWindow || !state.windowSize) {
    return;
  }

  const newY = updateFn(state.currentY);
  // Allow window to go 2/3 off screen in either direction
  const maxUpLimit = (-(state.windowSize.height || 0) * 2) / 3;
  const maxDownLimit =
    state.screenHeight + ((state.windowSize.height || 0) * 2) / 3;

  if (newY >= maxUpLimit && newY <= maxDownLimit) {
    state.currentY = newY;
    state.mainWindow.setPosition(
      Math.round(state.currentX),
      Math.round(state.currentY),
    );
  }
}

Notice the vertical movement has boundary constraints — the window can go 2/3 off screen in either direction. This lets users tuck the overlay mostly off-screen while keeping a sliver visible, without losing it entirely. Horizontal movement has no limits, which lets the window slide to a different monitor.

The 60-pixel step size is a UX tradeoff. Too small and repositioning feels sluggish. Too large and fine-tuning becomes impossible. 60px felt right after testing on multiple screen sizes.

Gaze Alignment

This is a subtle UX detail that affects stealth. The overlay should sit near the coding area of the interview platform. If the user is constantly looking at the top-right corner of the screen while typing in the center, it looks suspicious on camera.

Smart default positioning places the overlay adjacent to where the code editor typically sits in platforms like HackerRank and CoderPad. The keyboard shortcuts let users fine-tune this for each platform’s layout.

Content-Driven Resizing

The overlay also needs to resize based on content. A solution with a detailed thought process needs more space than a compact code snippet:

// electron/main.ts
function setWindowDimensions(
  width: number,
  height: number,
  _source: string,
): void {
  if (state.mainWindow && !state.mainWindow.isDestroyed()) {
    const [currentX, currentY] = state.mainWindow.getPosition();
    const primaryDisplay = screen.getPrimaryDisplay();
    const workArea = primaryDisplay.workAreaSize;
    const maxWidth = Math.floor(workArea.width * 0.4);

    const newWidth = Math.min(width + 32, maxWidth);
    const newHeight = Math.ceil(height);

    let adjustedX = currentX;
    let adjustedY = currentY;
    if (isWindowCompletelyOffScreen(currentX, currentY, newWidth, newHeight)) {
      adjustedX = Math.max(0, (workArea.width - newWidth) / 2);
      adjustedY = Math.max(0, (workArea.height - newHeight) / 2);
    }

    state.mainWindow.setBounds({
      x: adjustedX,
      y: adjustedY,
      width: newWidth,
      height: newHeight,
    });

    state.currentX = adjustedX;
    state.currentY = adjustedY;
    state.windowPosition = { x: adjustedX, y: adjustedY };
    state.windowSize = { width: newWidth, height: newHeight };
  }
}

A few things worth noting here. The 40% max width cap prevents the overlay from covering more than two-fifths of the screen — enough to display code, not enough to completely block the interview platform. The + 32 adds padding for content that sits flush against the edges.

The off-screen detection is a safety net. If the window somehow ends up completely off screen (can happen when an external monitor disconnects), it auto-centers instead of becoming lost forever.

The React renderer calculates the needed size based on its content, sends it to the main process via IPC, and the main process handles the actual resize with these constraints applied.

The macOS Zoom Problem

This is the single biggest platform-specific challenge I encountered building Ezzi. And it’s worth understanding in detail because it reveals how different capture implementations can behave differently even on the same OS.

What Happens

Most screen sharing on macOS uses either CGWindowListCreateImage or ScreenCaptureKit. Both respect NSWindowSharingNone. So when you set setContentProtection(true), the overlay is invisible in Teams, Chime, Google Meet, and all browser-based platforms.

But Zoom on macOS is different.

Zoom implemented its own capture pipeline that, in its default configuration, captures the raw display output rather than compositing individual windows. In this mode, it can see windows that have NSWindowSharingNone set, because it’s not querying the window server for individual window content — it’s reading the display buffer directly.

Think of it this way: NSWindowSharingNone tells the window server “don’t include me when someone asks for window data.” But if someone reads the entire display output instead of asking for window data, that instruction gets bypassed.

The Workaround

Zoom provides a setting called “Advanced Capture” with window filtering. When this is enabled, Zoom switches from display-level capture to window-level capture that correctly respects NSWindowSharingNone.

From the user’s perspective, the setup is:

1. Open Zoom Settings
2. Go to Screen Share
3. Enable “Use advanced capture with window filtering”
4. When sharing, select the specific application window (not “Desktop” or “Entire Screen”)

With this configuration, Zoom captures only the specified windows and correctly excludes content-protected windows from the output.

This is why Ezzi’s documentation notes that macOS Zoom requires “Advanced Capture with window filtering.” It’s not a limitation of our implementation — it’s a quirk of how Zoom handles capture on macOS.

Why Windows Doesn’t Have This Issue

On Windows, SetWindowDisplayAffinity(WDA_EXCLUDEFROMCAPTURE) is enforced at the DWM level. The Desktop Window Manager sits between applications and the display hardware. When a window has WDA_EXCLUDEFROMCAPTURE set, the DWM excludes it from all output paths — whether that’s BitBlt, DXGI Desktop Duplication, or Windows Graphics Capture.

There’s no way for Zoom (or any capture application) to bypass this on Windows, because the exclusion happens before the captured data is even made available to the application. It’s a fundamentally different architecture than macOS, and in this specific case, it works in our favor.

Staying Ahead of Zoom Updates

Zoom updates its capture implementation regularly. This is one of those things that requires ongoing testing. What works with Zoom 6.0 might behave differently with Zoom 6.1. I monitor Zoom release notes and test each major version to ensure compatibility.

My recommendation for anyone building similar tools: automate what you can, but accept that manual testing against third-party apps is unavoidable. Keep a test matrix and check it with every release.

Process-Level Stealth

Making the window invisible is only part of the story. Some detection approaches don’t look at what’s visible on screen — they look at what processes are running on the system.

Custom Application Naming

Ezzi supports build-time configuration of the application name. There’s a build script that patches the Electron builder config:

// scripts/build-config.js
const productName = process.env.PRODUCT_NAME || 'Ezzi';

const safeProductName = productName
  .replace(/[^a-zA-Z0-9\s-]/g, '')
  .replace(/\s+/g, '-');

const packagePath = path.join(__dirname, '..', 'package.json');
const packageJson = JSON.parse(fs.readFileSync(packagePath, 'utf8'));

packageJson.build.productName = productName;

packageJson.build.mac.artifactName =
  `${safeProductName}-Mac-\${arch}-\${version}.\${ext}`;
packageJson.build.win.artifactName =
  `${safeProductName}-Windows-\${version}.\${ext}`;

fs.writeFileSync(packagePath, JSON.stringify(packageJson, null, 2) + '\n');

Usage is simple:

PRODUCT_NAME="System Monitor" npm run build

This changes the process name in Activity Monitor and Task Manager, the application name in the dock/taskbar, and the artifact name for distribution.

If someone inspects your running processes, they see “System Monitor” instead of anything that would raise questions.

The script sanitizes the name with regex to create a safe filename version. No special characters, spaces become hyphens. This matters because the artifact name becomes the installer filename and the application bundle name on macOS. There’s no rename hack or post-build patching — the name goes into package.json before electron-builder runs, so it’s compiled with the custom identity from the start.

Testing Across Platforms

Here’s what made this whole project particularly challenging: you can’t just test on one machine and call it done. The behavior varies across:

• Windows 10 vs Windows 11
• macOS 12 through macOS 15
• Zoom vs Teams vs Google Meet vs Chime
• Native desktop apps vs browser-based platforms
• Different versions of the same app (Zoom changes capture behavior between updates)

My Testing Approach

Automated build verification. CI/CD pipelines build for Windows and macOS on every PR. This catches configuration regressions.

Manual capture testing. For each platform combination, I share the screen with a second device and verify the overlay is invisible. This can’t be fully automated because screen capture behavior depends on the capture application, its version, and its settings.

Focus monitoring. Run browser developer tools on interview platform mock pages and verify no blur or visibilitychange events fire when interacting with the overlay. This is scriptable and can be part of a semi-automated test suite.

Process inspection. Verify the custom app name appears correctly in Activity Monitor and Task Manager across different build configurations.

The matrix of combinations is large, and each OS or app update can potentially change things. This is ongoing maintenance, not a one-time implementation.

What I Learned

Building this taught me a few things that might be useful to anyone working with Electron overlays or OS-level window management.

Electron’s abstractions are good but not complete. setContentProtection works well for the common case. But understanding what it does at the OS level — SetWindowDisplayAffinity on Windows, setSharingType on macOS — helps you debug platform-specific issues and understand why certain edge cases exist.

Windows is actually easier here. WDA_EXCLUDEFROMCAPTURE is enforced at the DWM compositor level. No capture application can bypass it. macOS is more nuanced because different capture APIs have different levels of respect for NSWindowSharingNone, and apps like Zoom can choose which API to use.

Config-driven window management pays off. Scattering setIgnoreMouseEvents and setContentProtection calls throughout the codebase leads to bugs. Declarative config objects for each visibility state made the system predictable and easy to extend.

Focus management is harder than rendering. Making the window invisible to capture is relatively straightforward — it’s mostly one API call. Making sure it doesn’t trigger focus-loss detection on the interview platform is the more subtle engineering challenge. showInactive(), type: ‘panel’, and re-applying configs on focus events — these details make the difference.

Testing is never done. Every OS update, every Zoom update, every new interview platform version can change the capture behavior. You need an ongoing testing strategy, not just a one-time verification pass.

The Bigger Picture

The techniques here aren’t unique to interview assistants. Any application that needs to display sensitive or private content while the user is sharing their screen benefits from these patterns. Password managers, medical information overlays, confidential communications tools — they all face the same fundamental challenge.

The OS-level mechanisms exist precisely because there are legitimate use cases for windows that shouldn’t be captured. Electron makes them accessible through a clean API, and with the right combination of window properties, focus management, and platform-specific handling, you can build an overlay that’s truly invisible.

If you want to see this in action or dig through the actual implementation, Ezzi is open source: https://github.com/GetEzzi/ezzi-app.

If you’re building Electron overlays or working with screen capture APIs, I’d love to hear about your platform-specific war stories. The edge cases are endless, and sharing knowledge makes everyone’s implementations better.

I hope this was helpful. Good luck, and happy engineering!

How I Made a Desktop App Invisible to Screen Sharing (Electron + OS-Level Tricks) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR — Technical interviews in their current form don’t predict job performance. We’ve known this for years, yet the industry keeps doubling down on LeetCode-style assessments that burn out good developers and reward the wrong skills. I compare the most common interview formats, explain why each falls short, and argue for what a better process could look like. I also talk about why tools like Ezzi exist in the first place — they’re a symptom, not the disease.

The Interview That Changed My Mind

A few years ago, I bombed a technical interview at a company I genuinely wanted to join. The role was a senior backend position. I had years of production experience, had shipped systems handling real traffic, and could talk architecture all day.

The interview? Reverse a linked list on a whiteboard. Then implement a sliding window algorithm. Then do it again, but optimized.

I stumbled. Not because I didn’t know the concepts — I did. But the pressure of performing live, on a timer, with someone watching my every keystroke, made my brain lock up. I walked out feeling like a fraud. Two weeks later I landed a different role at a comparable company, where the interview was a system design discussion and a take-home project. Same me, same skills, wildly different outcome.

That experience stuck with me. It made me question what these interviews are actually measuring. And the more I looked into it, the more I realized: the entire system is broken.

The Disconnect Nobody Wants to Admit

Here’s the uncomfortable truth. The skills that make you good at passing a coding interview and the skills that make you good at your actual job have surprisingly little overlap.

Day to day, a software engineer reads existing code, collaborates with teammates, debugs production issues, reviews pull requests, designs systems, and writes code that other people will maintain. None of that is tested in a 45-minute LeetCode session.

What gets tested instead? Your ability to recall a specific algorithm under time pressure, write syntactically perfect code without an IDE, and explain your thought process while simultaneously solving a puzzle. That’s a performance, not an evaluation.

Google’s own internal research found that interview scores were essentially useless at predicting on-the-job performance. They studied it, published the findings, and then… kept doing interviews the same way. If that doesn’t tell you something about how deeply entrenched this system is, nothing will.

The LeetCode Grind Is Burning People Out

Let’s talk about what the current system actually does to candidates.

The expectation in 2025–2026 is that before you even apply, you should have ground through hundreds of LeetCode problems. There are entire communities, courses, and paid platforms built around this. People spend months preparing for interviews instead of, you know, building things.

I’ve seen senior engineers with a decade of experience spend their evenings and weekends drilling dynamic programming problems. Not because they enjoy it, and not because it makes them better engineers. Because it’s the toll you pay to switch jobs.

The result is a system that selects for people who have time and energy to grind. Young, single, no kids, no burnout yet. If you’re a parent, or you’re dealing with health issues, or you’re just exhausted from your current job — tough luck. The interview process punishes you for having a life outside of coding.

And the irony is that many of the best engineers I’ve worked with would struggle in these interviews. They’re great at thinking through complex systems over days, not at performing algorithmic gymnastics in 45 minutes.

Why Companies Keep Doing It Anyway

If the current system is so broken, why does it persist? A few reasons.

It’s easy to standardize. LeetCode-style problems have clear right and wrong answers. You can grade them. You can compare candidates. You can build rubrics. For companies hiring at scale — the FAANGs and their imitators — this matters more than whether the assessment is actually meaningful.

Nobody wants to be the one who changed it. If you’re a hiring manager and you switch to a new format, and a bad hire slips through, you’re on the hook. But if you use the standard LeetCode process and a bad hire happens, well, that’s just how it goes. The current system provides cover. It’s defensive hiring.

Interviewers don’t know what else to do. Most engineers who conduct interviews were never trained to do so. They pull a problem from a list, watch the candidate struggle, and try to evaluate “problem-solving ability” with no clear criteria for what that means. The LeetCode format feels structured, so they stick with it.

Candidates tolerate it. This is the part nobody likes to hear. We complain about the process, but we still prep for it. We still grind. We still show up. As long as candidates keep playing the game, companies have no incentive to change the rules.

Comparing the Alternatives

Not every company interviews the same way. Let’s look at the most common formats and where they fall short.

Live Coding (LeetCode Style)

The standard. You get a problem, you solve it live, the interviewer watches.

What it tests: Algorithm recall, performance under pressure, ability to think out loud.

What it misses: Literally everything about day-to-day software engineering. You don’t code from scratch in production. You don’t solve isolated puzzles. You don’t work without Google, documentation, or your IDE’s autocomplete.

The real problem: It rewards memorization over understanding. Someone who has seen the exact problem before will outperform someone who’s a better engineer but hasn’t memorized that specific pattern. That’s not signal, that’s noise.

Take-Home Assignments

The candidate gets a project (build an API, create a small app) and has a few days to complete it.

What it tests: Ability to write real code, make architectural decisions, handle edge cases, write tests.

What it misses: It doesn’t test collaboration or communication. And it’s hard to know how much help the candidate got.

The real problem: It’s a massive time ask. A “small” take-home can easily eat 4–8 hours. If you’re interviewing at three companies simultaneously, that’s a part-time job on top of your actual job. And many companies never even review the submission properly — they skim it in 10 minutes. The disrespect of candidate time is the biggest issue here.

System Design

The candidate is asked to design a system (URL shortener, chat application, distributed cache) at a high level.

What it tests: Architectural thinking, understanding of distributed systems, ability to reason about trade-offs.

What it misses: It heavily favors experienced candidates (which might be fine for senior roles). It’s also hard to standardize — two interviewers can evaluate the same session very differently.

The real problem: It’s often conducted poorly. Many interviewers have a specific solution in mind and penalize candidates who go a different direction, even if the alternative is perfectly valid. It becomes “guess what I’m thinking” instead of “show me how you think.”

Pair Programming

The candidate works on a real-ish problem alongside an engineer from the team, often using a real IDE with access to documentation.

What it tests: Collaboration, communication, how the candidate approaches a problem in a realistic environment.

What it misses: It’s time-intensive for the interviewing team. And shy or introverted candidates can underperform even if they’re excellent solo contributors.

The real problem: Very few companies do this well. It requires trained interviewers and carefully designed problems. Most companies that claim to do pair programming actually do live coding with an audience.

Tools Like Ezzi Are a Symptom

I built Ezzi — an invisible overlay that provides AI-powered assistance during coding interviews. I’ve written about the technical journey and the engineering behind it in previous articles. But here’s what I want to say in this context: Ezzi exists because the interview system created a market for it.

When the gap between what’s tested and what’s needed is this wide, people find ways to bridge it. Some memorize 500 LeetCode problems. Some hire interview coaches. Some use AI tools. The methods differ, but the motivation is the same: the process feels unfair, and people are looking for an edge.

I’m not going to moralize about whether using an AI tool during an interview is right or wrong. That’s a separate conversation (and one I’ll tackle in a future article). What I will say is this: if your interview process can be defeated by an AI reading the question and generating a solution, maybe the interview process is testing the wrong thing.

A good assessment should be hard to game not because it’s obscure, but because it genuinely measures what matters. If a candidate can have an AI solve the problem and still can’t do the job, that’s a bad hire. But if a candidate uses an AI tool and then performs well on the job — what exactly did your interview measure that mattered?

What a Better Process Could Look Like

I don’t think there’s a single perfect interview format. But I do think the industry can do a lot better than what we have now. Here’s what I’d want to see.

Paid trial days. Have the candidate work on a real (or realistic) task with the actual team for a day or two. Pay them for their time. This is expensive, yes. But it gives you more signal in a day than a dozen whiteboard sessions. Some companies already do this and swear by it.

Structured behavioral interviews. Not the “tell me about a time you showed leadership” fluff. Real, calibrated questions about technical decisions the candidate has made, how they handled disagreements, how they debugged a production issue. Research consistently shows that structured behavioral interviews are among the best predictors of job performance.

Portfolio and past work review. If a candidate has open-source contributions, a blog, side projects, or can walk you through a system they built at a previous job — that’s real evidence. It’s not perfect (not everyone has time for side projects), but it’s better than watching them sweat over a binary tree.

Realistic coding exercises with tools. If you insist on a coding component, let them use their IDE. Let them Google things. Let them use AI tools, even. Then evaluate the result: is the code clean, tested, well-structured? Can they explain their decisions? That’s closer to what the job actually looks like.

Shorter, more focused interviews. A five-round, full-day interview is an endurance test. It measures how well you perform while exhausted. Consider whether you really need five rounds, or if two well-designed sessions would give you the same signal.

The Cost of Doing Nothing

The status quo has real costs, and not just for candidates.

Companies miss great engineers who don’t interview well. They hire people who are excellent at interviews but mediocre at the actual work. They lose candidates to competitors who have a better process. And they contribute to an industry culture where preparing for interviews is a second job.

The candidates who are most hurt by the current system are often the ones companies claim to want: experienced engineers, career changers, people from non-traditional backgrounds, people with responsibilities outside of work. The grind favors the privileged.

If you’re a hiring manager reading this, I’d challenge you to ask one question: does your interview process test for what actually matters in the role? If the honest answer is “not really,” you have the power to change it. You don’t have to overhaul everything at once. Start with one round. Replace a LeetCode problem with a take-home review or a pair programming session. See what happens.

And if you’re a candidate going through this right now — I get it. The system is frustrating. Prepare as best you can, but don’t let a bad interview outcome define your self-worth. The interview is broken, not you.

Final Thoughts

I started thinking about this topic long before I built Ezzi. The frustration of going through hiring processes that felt disconnected from real work is something almost every developer I know shares. Building Ezzi was one response to that frustration. Writing this article is another.

The tech industry prides itself on innovation and disruption. We’ll reinvent everything from how people order food to how companies deploy code. But we’ve been interviewing engineers the same way for over a decade. That’s not tradition — that’s inertia.

Something needs to change. I don’t have all the answers, but I know the current system isn’t one of them.

I hope this was helpful. Good luck, and happy engineering!

If you want to check out the project that came from this frustration, Ezzi is open source on GitHub: github.com/GetEzzi/ezzi-app

Why Technical Interviews Are Broken (And What We Can Do About It) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Real examples from an open-source Electron app that went viral — and what I learned refactoring it.

TL;DR — I forked an open-source Electron project called Interview Coder to build my own app, Ezzi. The codebase was clearly vibe coded — functional but fragile. I found security holes, any types everywhere, 700-line monolithic files, and client-side credit management that should have been on the server. This article walks through real code examples of what I found and the patterns you should watch for when inheriting AI-generated code.

The Rise of Vibe Coding

“Vibe coding” is the new hot thing. You open Cursor or Claude, describe what you want, and let the AI write most of the code. Ship fast, iterate faster. The results can be impressive — entire apps built in a weekend.

But here’s what nobody talks about: what happens when someone else has to maintain that code?

I found out the hard way. In early 2025, I forked a project called Interview Coder — an Electron app that had blown up online. The concept was brilliant (an invisible overlay for coding interviews), and it worked. The creator had open-sourced it under MIT license. Perfect starting point for my own project, Ezzi.

Except the codebase was a mess.

Not broken. Not non-functional. It ran. It did what it promised. But the internals told a different story — one that I think is becoming increasingly common as more projects get built with AI assistance and less human oversight.

What I Actually Found

Let me walk you through real examples. These are not hypothetical “bad code smells” from a textbook. This is actual code from a project with thousands of GitHub stars.

1. The “any” Epidemic

The first thing I noticed was TypeScript being used as if it were JavaScript with extra steps. The type system was barely utilized.

Here’s the global type definitions file in its entirety:

// src/types/global.d.ts
interface Window {
 __IS_INITIALIZED__: boolean
 __CREDITS__: number
 __LANGUAGE__: string
 __AUTH_TOKEN__: string | null
 supabase: any // Replace with proper Supabase client type if needed
 electron: any // Replace with proper Electron type if needed
 electronAPI: any // Replace with proper Electron API type if needed
}

Three properties typed as any with comments that literally say “Replace with proper type if needed.” That’s AI placeholder text that was never cleaned up. The AI generated a TODO and the developer shipped it.

The pattern continues in the Electron API definitions:

// src/types/electron.d.ts
onDebugSuccess: (callback: (data: any) => void) => () => void
onProblemExtracted: (callback: (data: any) => void) => () => void
onSolutionSuccess: (callback: (data: any) => void) => () => void
onUpdateAvailable: (callback: (info: any) => void) => () => void
onUpdateDownloaded: (callback: (info: any) => void) => () => void

Every single callback parameter is any. The data flowing through the entire IPC layer — the communication bridge between the Electron main process and the renderer — has zero type safety. You could send anything and TypeScript would shrug.

And the core state management in the main process:

// electron/main.ts
function getProblemInfo(): any {
 return state.problemInfo
}
function setProblemInfo(problemInfo: any): void {
 state.problemInfo = problemInfo
}

The state object itself had problemInfo: null as any as its definition. This is the central piece of data the app revolves around — the extracted problem from screenshots — and it has no type definition. Any code that reads this data is flying blind.

The lesson: When AI writes TypeScript, it often defaults to any as a shortcut. It works, it compiles, and the AI moves on to the next function. But it defeats the entire purpose of using TypeScript. If you’re inheriting a codebase like this, search for any first. The count will tell you a lot about how much the original developer reviewed the AI’s output.

2. Security That Made Me Uncomfortable

This was the part that genuinely alarmed me.

The app stored the auth token in a global window object:

// src/App.tsx
if (data?.session?.access_token) {
 window.__AUTH_TOKEN__ = data.session.access_token
}

And then the Electron main process would retrieve it by executing JavaScript in the renderer:

// electron/ProcessingHelper.ts
private async getAuthToken(): Promise<string | null> {
 const mainWindow = this.deps.getMainWindow()
 try {
   await this.waitForInitialization(mainWindow)
   const token = await mainWindow.webContents.executeJavaScript(
     "window.__AUTH_TOKEN__"
   )
 return token
 } catch (error) {
   console.error("Error getting auth token:", error)
   return null
 }
}

executeJavaScript(“window.__AUTH_TOKEN__”) from the main process. This is the Electron equivalent of reaching into someone’s pocket. It works, but it bypasses the entire security model that Electron’s contextBridge was designed to enforce. The proper approach is IPC messaging through the preload script.

And then there was the credit management. Subscription credits were subtracted on the client:

// src/App.tsx
const { data: updatedSubscription, error } = await supabase
 .from("subscriptions")
 .update({ credits: currentSubscription.credits - 1 })
 .eq("user_id", user.id)
 .select("credits")
 .single()

The client fetches the current credit count, subtracts one, and writes it back. Without Row Level Security properly configured, anyone could modify the query to set their credits to whatever they wanted. Or skip the subtraction entirely. This is business logic that belongs on a server, behind authentication, with proper validation.

The lesson: AI tools don’t think about security architecture. They produce code that works for the happy path. When you see Supabase queries modifying sensitive data directly from the client, or auth tokens passed between processes through globals instead of proper IPC — these are not style issues. These are design flaws that undermine your entire trust model.

3. Monolithic Files

AI tends to keep adding code to whatever file it’s currently working in. The result is a handful of massive files that do everything.

ProcessingHelper.ts — 700+ lines. One class handling: credential retrieval, language detection, auth token management, screenshot processing, solution generation, debug processing, request cancellation, and error handling for all of the above.

App.tsx — 700+ lines. The root React component that manages: authentication forms, subscription state, credit management, Supabase real-time subscriptions, toast notifications, language preferences, and initialization logic.

main.ts — 660+ lines. The Electron main process containing: application state, window management, helper initialization, auth callback handling, window movement calculations, screenshot delegation, IPC setup, and environment variable loading.

Three files, over 2,000 lines, doing virtually everything the app does.

The ProcessingHelper class is a good example of the problem. Here’s its credit checking method:

// electron/ProcessingHelper.ts
private async getCredits(): Promise<number> {
  const mainWindow = this.deps.getMainWindow()
  if (!mainWindow) return 0

  try {
    await this.waitForInitialization(mainWindow)
    const credits = await mainWindow.webContents.executeJavaScript(
      "window.__CREDITS__"
    )

    if (
      typeof credits !== "number" ||
      credits === undefined ||
      credits === null
    ) {
      console.warn("Credits not properly initialized")
      return 0
    }

    return credits
  } catch (error) {
    console.error("Error getting credits:", error)
    return 0
  }
}

Look at that type check: typeof credits !== “number” || credits === undefined || credits === null. If typeof credits !== “number” is true, then checking for undefined or null is redundant. This reads like an AI pattern-matching from multiple examples without understanding the logic. It’s defensive coding that defends against nothing.

The same file has identical patterns for getLanguage() and getAuthToken() — each method polling the renderer’s global state through executeJavaScript. Three methods, same structure, same problems, no abstraction.

The lesson: If your inherited codebase has a few files that are 500+ lines each, that’s a strong signal of AI-generated code that was never decomposed. AI doesn’t refactor proactively. It just keeps adding functions to the current file until you tell it to stop.

4. The “window.__GLOBAL__” Pattern

Instead of using React Context, a state management library, or even Electron’s IPC properly, the app synchronized state through global window variables:

// src/App.tsx - setting global state
const updateCredits = useCallback((newCredits: number) => {
  setCredits(newCredits)          // React state
  window.__CREDITS__ = newCredits // also global state
}, [])

const updateLanguage = useCallback((newLanguage: string) => {
  setCurrentLanguage(newLanguage)   // React state
  window.__LANGUAGE__ = newLanguage // also global state
}, [])

const markInitialized = useCallback(() => {
  setIsInitialized(true)            // React state
  window.__IS_INITIALIZED__ = true  // also global state
}, [])

Every state update writes to two places: React’s state and a global window property. Two sources of truth. If they ever get out of sync — and they will — good luck debugging which one is correct.

The reason for the duplication is that the Electron main process needed access to these values. But instead of using IPC (which Electron is designed for), the main process reaches into the renderer via executeJavaScript:

// electron/ProcessingHelper.ts
const isInitialized = await mainWindow.webContents.executeJavaScript(
  "window.__IS_INITIALIZED__"
)
const credits = await mainWindow.webContents.executeJavaScript(
  "window.__CREDITS__"
)

This creates a tight coupling between the main process and the renderer’s implementation details. Change how React manages state, and the main process breaks. Rename a window variable, and nothing will tell you at compile time.

The lesson: AI tools often reach for the simplest working solution. Global state is simpler than proper IPC. It works in the demo, it passes a basic test, and the AI moves on. Watch for window.__anything__ patterns — they’re a sign that cross-process communication was hacked together rather than designed.

5. Duplicated Code Everywhere

AI tools don’t maintain awareness of what already exists in the codebase. If you ask for similar functionality in a different component, you get a fresh copy.

The sign-out logic was duplicated across two components, character for character:

// src/components/Solutions/SolutionCommands.tsx
const handleSignOut = async () => {
  try {
    localStorage.clear()
    sessionStorage.clear()
    const { error } = await supabase.auth.signOut()
    if (error) throw error
  } catch (err) {
    console.error("Error signing out:", err)
  }
}

// src/components/Queue/QueueCommands.tsx - identical copy
const handleSignOut = async () => {
  try {
    localStorage.clear()
    sessionStorage.clear()
    const { error } = await supabase.auth.signOut()
    if (error) throw error
  } catch (err) {
    console.error("Error signing out:", err)
  }
}

Same function, same logic, two files. If you need to change the sign-out behavior (and I did — I stripped out Supabase from the client entirely), you have to find and update every copy.

The same pattern repeated with screenshot mapping logic, tooltip visibility handling, and error display components. Each duplicated 2–3 times across the codebase.

The lesson: After inheriting AI-generated code, search for duplicated blocks. The AI doesn’t know (or care) that it already wrote the same function elsewhere. Deduplication is one of the first refactoring passes you should do.

6. Error Handling as an Afterthought

The error handling throughout the codebase followed a consistent pattern: catch the error, log it, move on.

// src/App.tsx
checkExistingSession()  // async function called without await, errors lost

This is a fire-and-forget call to an async function. If it throws, nobody catches it. The user won’t see an error, and the app might be in a half-initialized state.

The ProcessingHelper had nested try-catch blocks where errors were typed as any:

// electron/ProcessingHelper.ts
} catch (error: any) {
  mainWindow.webContents.send(
    this.deps.PROCESSING_EVENTS.INITIAL_SOLUTION_ERROR,
    error  // sending the raw error object through IPC
  )
  console.error("Processing error:", error)
  if (axios.isCancel(error)) {
    mainWindow.webContents.send(
      this.deps.PROCESSING_EVENTS.INITIAL_SOLUTION_ERROR,
      "Processing was canceled by the user."
    )
  } else {
    mainWindow.webContents.send(
      this.deps.PROCESSING_EVENTS.INITIAL_SOLUTION_ERROR,
      error.message || "Server error. Please try again."
    )
  }
}

Three things wrong here. First, the raw error object is sent through IPC before the type check — so the renderer gets an unserialized error object. Then, depending on whether it’s a cancellation or not, a second message is sent with a proper string. The renderer now gets two error events for one failure. Second, error: any means no type narrowing. Third, the error message fallback assumes error.message exists, which isn’t guaranteed for any.

And then there was a typo in the event constants that could cause silent failures:

// electron/preload.ts
UNAUTHORIZED: "procesing-unauthorized",  // "procesing" - missing a 's'

While main.ts had:

// electron/main.ts
UNAUTHORIZED: "processing-unauthorized",  // correct spelling

Different strings for the same event. The preload listens for “procesing-unauthorized” but main sends “processing-unauthorized”. The unauthorized handler would never fire.

The lesson: AI-generated error handling often looks correct at a glance but falls apart under scrutiny. Check for: unhandled promise rejections, catch (error: any) blocks, inconsistent error event naming, and duplicate error sends.

What I Did About It

When I started building Ezzi from this fork, my first month was almost entirely refactoring. Here’s the rough order of operations that worked for me:

1. Security audit first. I stripped out the client-side credit management, moved sensitive operations to the server, and replaced the window.__AUTH_TOKEN__ pattern with proper IPC. Security architecture issues are the ones that can actually hurt users.

2. Type safety pass. I searched for every any and replaced them with proper interfaces. This immediately surfaced several bugs where functions were receiving data in unexpected shapes.

3. Decompose monolithic files. I broke ProcessingHelper.ts into smaller, focused modules. Same with App.tsx — extracted the auth form, subscription management, and initialization logic into their own components.

4. Deduplicate. Extracted shared logic into utility functions and custom hooks. The sign-out logic became a single useSignOut hook.

5. Clean up error handling. Typed errors properly, removed duplicate error sends, fixed the event name typos, and made sure async functions were properly awaited.

It wasn’t glamorous work. But it was necessary. The app worked before I started, and it worked after. The difference is that now I can actually maintain it, extend it, and trust it.

A Checklist for Inheriting AI-Generated Code

If you’re about to fork or take over a vibe coded project, here’s what I’d check first:

Security
- Search for hardcoded API keys, URLs, and secrets
- Look for client-side operations that should be server-side (credit management, billing)
- Check how auth tokens are passed between processes
- Verify that sensitive business logic lives on the server, not in the client

Type Safety
- Count the any types — if there are more than a handful, expect problems
- Check if interfaces exist for the core data structures
- Look for AI placeholder comments like “Replace with proper type”

Architecture
- Check file sizes — files over 500 lines likely need decomposition
- Look for the window.__SOMETHING__ pattern
- Search for duplicated code blocks across components
- Verify that cross-process communication uses proper channels

Error Handling
- Search for catch (error: any) blocks
- Look for fire-and-forget async calls (async functions called without await)
- Check for duplicate error event sends
- Verify error event naming is consistent across files

The Bigger Picture

I’m not against vibe coding. I used AI assistants extensively while building Ezzi — Cursor, Junie, Claude Code. They’re genuinely powerful tools that let you move fast.

But there’s a difference between using AI as a collaborator and using it as a replacement for understanding your own code. The original Interview Coder project shipped fast and went viral. That’s a success by many metrics. But the code underneath was a liability waiting to happen.

The AI doesn’t care about maintainability. It doesn’t think about who will read this code next month. It optimizes for “does it work right now” and moves on. That’s fine for prototypes and hackathons. It’s not fine for software that handles auth tokens and financial transactions.

If you’re vibe coding your own project, at least do a review pass before shipping. And if you’re inheriting someone else’s vibe coded project, budget serious time for refactoring before you start building on top of it.

Git is your friend. Commit often. And read the code the AI writes.

I hope this was helpful. Good luck, and happy engineering!

If you’re curious about the result of all this refactoring, Ezzi is open source on GitHub: github.com/GetEzzi/ezzi-app

What Vibe Coding Taught Me About Maintaining Someone Else’s AI-Generated Code was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR — I built a desktop app called Ezzi (pronounced like “easy”) that acts as an invisible overlay during coding interviews. It gives you AI-generated solutions (even in your native language) without the interviewer noticing. I forked an early version of Interview Coder to my create my own spin on the idea. I’m excited to open-source Ezzi so others can use it and contribute to its future.

The Problem with Interviews

Many developers get burnt out by the broken hiring process. Technical job searches drag on with endless coding tests and whiteboard sessions, which can chip away at your confidence.

I often felt that acing these interviews was as much about endurance and luck. Even after countless evenings on LeetCode, we’d still get blindsided by questions under pressure. It struck me that the process is, frankly, broken - and I wasn’t alone in feeling this. I started wondering: What if I had a “coach” by my side during these interviews? Not a person, but an AI assistant that could hint or even show a solution if I got stuck.

That’s when I discovered Interview Coder, an open source project that had blown up online in April 2025. It was vibe coded and honestly a mess, but it worked. The concept was brilliant: an invisible overlay that only the candidate can see (not the interviewer). However, the project soon went closed source and development stagnated. I decided to fork one of the earlier open source versions and build my own take on the idea.

This concept was proof of how flawed the system is: if people are resorting to stealth tools to get through interviews, maybe the interviews need to change. But until they do, why not level the playing field a bit?

Building Ezzi

I set out to build a desktop app that could help with live interview support: If you choose, use it during a real interview (even while screen sharing) for undetectable assistance - a little safety net that only you can see.

The current version focuses on the core interview assistance functionality, with additional features like hint-only mode, LeetCode practice, and learning tools planned for the future.

I also had some personal motivations: after years as a backend engineer, I was itching to build a desktop application and learn something new. I’d never built an Electron app or done cross-platform UI work before. Plus, I was curious about the new wave of AI coding tools like Cursor, Claude, Codex, Junie. This project felt like the perfect sandbox to play with those while creating something potentially useful (or at least interesting!).

What is Ezzi?

In a nutshell, Ezzi (pronounced like “easy”) is an invisible overlay UI for coding interviews. It runs as a desktop app on your computer, sitting on top of your coding environment. When activated (via a hotkey), it shows an assistive panel only on your screen, not on the shared screen. The interviewer sees nothing unusual - just your coding window - while you see an extra panel with helpful info.

Under the hood, Ezzi uses AI (Claude 4 for now) to analyze the coding question you’re working on. It can give you a step-by-step thought process, explain which DSA pattern or algorithm might apply, and generate a complete solution.

Key Features

Invisible UI: The overlay window is designed to be 99% invisible to screen-sharing tools.

It won’t show up on Zoom, Google Meet, or common interview platforms (they’ll just capture your code editor, not the Ezzi window). This “stealth mode” means you can use it in live interviews without the tool itself being detected.

AI-Generated Solutions: Ezzi connects to AI models to provide context-aware help.

Multi-language Support: Delivers thoughts and hints in your preferred spoken language to reduce cognitive load during interviews.

Minimal Footprint & Undetectability: It doesn’t inject anything into the browser or interfere with the code editor; it’s a separate floating window. You toggle it with a hotkey, and it can overlay on top of any browser, IDE or coding pad. When off, it’s completely out of the way. Hotkeys look like a no-op to your coding environment.

In short, Ezzi turns those nerve-racking DSA interviews into a (slightly) more open-book experience. It’s like having an expert whispering hints in your ear, or a safety net ready to catch you if you get stuck. And since Ezzi is open source, you can build and customize this assistant yourself, or even run your own AI backend for it.

Building a Desktop App as a Backend Engineer

Building Ezzi was as much a personal learning journey as it was a software project. I spend most of my days in backend land - databases, APIs, cloud services - not building UIs. So, choosing Electron + React for a desktop app was me stepping out of my comfort zone.

Electron allowed me to write cross-platform desktop software in TypeScript (essentially creating a mini web app that runs on Windows, Mac, or Linux). With this, I could ensure anyone can use Ezzi regardless of their OS.

Tech Stack at a Glance

Electron & React: Electron provides the container (Chromium + Node runtime) to create the desktop app, and React + Tailwind CSS makes it easier to build a dynamic UI. The overlay’s interface (the hints panel, etc.) is just a web page rendered in a transparent Electron window.

Node.js backend: I built a companion backend service with NestJS. This handles things like processing the screenshots, communicating with the AI models, and any heavy logic that I didn’t want to run in the client for security. NestJS gives a structured way to build out a REST API. For example, when you hit “Solve” in Ezzi, the app sends the data to a NestJS API which then calls an AI service to retrieve hints or solutions, and sends it back to the app.

Infrastructure: the rest of the iceberg is here - databases, GitHub actions, deploy pipelines, Stripe integration, AI integration and so on.

How It Works

The Electron + React frontend communicates with a backend, which interacts with external AI APIs (like OpenAI’s GPT or Anthropic’s Claude).

In self-hosted mode, the user runs his own backend server; in cloud mode, Ezzi’s app talks to a managed server.

I made the overlay window click-through in solution mode by default. This way, you’re not accidentally selecting text on the overlay when you mean to code. Clicks in the app area are never attributed to the Ezzi window, so your browser or IDE never loses focus. And when hidden, the app is truly hidden (not just minimized - it doesn’t appear on the taskbar or Dock).

Development Journey (Forking, Fixing, and Learning)

Ezzi’s development began as a fork of the Interview Coder codebase. Interview Coder, for context, was a closed-source (initially) app that went viral in late 2024 for offering undetectable AI help in interviews. Its creator eventually put the code on GitHub (with an open-source license) and even encouraged folks to fork it.

However, diving into that code was quite an eye-opener. The project was functional, but the internals were… let’s say rough around the edges. It felt like large parts had been generated by an AI (the original dev likely used Cursor or something similar). There were huge files with little structure, minimal comments, and some very quirky code paths. My first challenge was simply getting the code to run properly and understanding how everything connected.

The lack of clear structure meant I had to do a lot of refactoring from day one. Functions had names that didn’t always make sense, there were unused variables and dead code branches, and TypeScript types were applied loosely (with plenty of any types floating around). I spent a good amount of time enforcing type safety - enabling stricter TypeScript config, adding interfaces for data objects (like the shape of a captured “problem” or a “solution” response), and removing redundant code. This process flushed out many hidden bugs.

// "any" typehints everywhere
function getProblemInfo(): any { // !!!
  return state.problemInfo
}

function setProblemInfo(problemInfo: any): void { // !!!
  state.problemInfo = problemInfo
}

// or no types at all
app.on("open-url", (event, url) => { // !!!
  console.log("open-url event received:", url)
  event.preventDefault()
  if (url.startsWith("interview-coder://")) {
    handleAuthCallback(url, state.mainWindow)
  }
})

// auth token is stored in the window object of the browser
const checkExistingSession = async () => {
      const { data: { session } } = await supabase.auth.getSession()
      if (session?.access_token) {
        window.__AUTH_TOKEN__ = session.access_token // !!!
        setUser(session.user)
        setLoading(false)
      }
    }

I also took the opportunity to try out AI coding assistants during development. I alternated between using Cursor, JetBrains Junie and Claude Code as I untangled the codebase and built new features (“vibe coding” kinda but with prior software engineering experience).

However, it wasn’t all magic - the AI sometimes produced messy or buggy code. It’s a bittersweet feeling when an AI speeds you to a solution that almost works, and then you dig for some time fixing edge cases. This was a big part of the development journey: embracing these tools for speed, but then stabilizing and refactoring the code to ensure Ezzi runs reliably.

Git is your friend.

Security and Privacy Enhancements

One alarming discovery was that the original app used Supabase endpoints without row security and hard-coded secrets that were never meant for production. It was possible to dump user data without proper auth. To get solutions without subscription or to generate subscription for yourself all without any authentication.

// App.tsx - subtracting user credits on the client
const { data: updatedSubscription, error } = await supabase
    .from("subscriptions")
    .update({ credits: currentSubscription.credits - 1 })
    .eq("user_id", user.id)
    .select("credits")
    .single()

// App.tsx - checking user subscriptions
// removing ".eq("user_id", user.id)" allowed to fetch all the users
setSubscriptionLoading(true)
try {
  const { data: subscription } = await supabase
    .from("subscriptions")
    .select("*, credits, preferred_language")
    .eq("user_id", user.id)
    .maybeSingle()

  setIsSubscribed(!!subscription)
  setCredits(subscription?.credits ?? 0)
  if (subscription?.preferred_language) {
    setCurrentLanguage(subscription.preferred_language)
    window.__LANGUAGE__ = subscription.preferred_language
  }
} finally {
  setSubscriptionLoading(false)
}

Knowing this, I prioritized security fixes: I stripped out any “must be backend” endpoints, secured the remaining ones with proper authentication, and moved all variables to .env files not tracked in git.

The bottom line is that no personal data or API keys are ever exposed in the repo or in network calls. This was a non-negotiable improvement for me after seeing what happened with the original.

I even considered the threat of the app itself being detected by anti-cheat measures, so I made it possible to change window title, process name, and other identifiable strings during build time.

Learning Desktop Packaging

As a backend/web guy, one of the steepest learning curves for me was packaging and distributing a desktop application. During development I was running Ezzi in dev mode with npm run dev command.

But to share it with others, I needed installers. I learned to use Electron Builder to create an installer for Windows (which packages the app and the Node runtime), a DMG for macOS, and even AppImage for Linux. Each had its quirks.

For Windows, I went through code signing - a process where you need a certificate to sign your executable so Windows will trust it.

For macOS, I navigated notarization (Apple’s security checks for distributed apps) and dealing with the screen recording permission pop-up (which is critical for the user to accept, otherwise the app can’t see the screen). These were all new concepts to me.

Seeing friends download the app and have it “just work” felt like magic - it’s easy to take for granted how much packaging work goes into software until you do it yourself!

Right now I do not provide packaged versions, instead the user can download the code and build for their own OS, modifying app title and/or icon for extra invisibility. This eliminates the problem with any signing, you can run anything you build locally without worrying about code signing.

Self-Hosting vs Cloud: Choose Your Own Adventure

One big decision I made was to keep Ezzi’s core functionality free and open-source, while offering a convenient managed cloud service as well. The entire frontend (Electron app) code is open for anyone to inspect, build, and deploy on their own. If you value privacy or just like to tinker, you can run Ezzi 100% self-hosted - no subscription needed, just your own API keys for the AI services. On the other hand, if you don’t want to deal with setting up servers or managing API quotas, you can opt to use the Ezzi Cloud (a hosted backend that I run). Both modes give you the same Ezzi app experience, but there are trade-offs.

Self-Hosted Mode (DIY)

You compile the open-source Ezzi app, and point it to your own backend. This could be a server you run at home or on AWS, or even your local machine. You’ll need to set up the backend (your favorite stack) and get API keys from AI provider.

The upside is it’s free (aside from any API costs you incur) and fully in your control. You can even modify the code - want to integrate a new model or change the UI? Go for it. The downside is the initial setup effort.

By my estimates, it takes around an hour to get everything configured and tested if you’re starting from scratch.

I’ve written detailed docs to guide you, but yes, self-hosting is for the more tech-savvy or motivated users.

Ezzi Cloud (Managed Backend)

This is the “plug and play” option. I run the backend for you in the cloud. All you do is build the Ezzi frontend, you sign in to the app, and it uses cloud servers. You get access to the premium AI model (Claude 4) without needing your own backend.

The cloud service is how I plan to cover server costs: it’s a paid subscription model, but you can just pay for a short period if you only need it for a couple of interviews. If that’s not your cup of tea, no worries - stick to self-hosted, and you’ll still have full access to all of Ezzi’s features.

Ultimately, the existence of the cloud option doesn’t change the open-source nature of Ezzi. The frontend is MIT-licensed. I want users to trust this tool, and part of that trust is knowing exactly what the code is doing.

What I’ve Learned (and What’s Next)

Writing Ezzi has been a wild ride. On the technical side, I went from 0 to 100 with desktop app dev, grappling with packaging Electron apps for three OSes, dealing with weird bugs, and integrating everything from database listeners to AI APIs.

I also learned that AI coding assistants are not a replacement for understanding your own codebase - they’re tools, not teammates. I had to rewrite large chunks of AI-generated code to make it maintainable. In a way, cleaning up the codebase was cathartic and made me a better developer.

From the perspective of the tech industry, building (and now releasing) Ezzi has reinforced my belief that technical interviews need reform. When tools like this exist - and people feel compelled to use them - it’s a sign that the interview format isn’t working. My stance is that learning and cheating often use the same tools; the difference is intent.

I built Ezzi primarily as a learning aid and confidence booster. Yes, it can be used to cheat in an interview - and I’m not here to moralize or encourage that - but I know realistically some will use it that way.

My hope is that interviewers and companies will focus more on practical assessments and maybe even embrace AI assistance as a positive (after all, a developer who can effectively use AI tools might be more productive on the job). If Ezzi sparks that conversation, I’d consider it a success beyond just the software.

On a lighter note, I also got a crash course in what not to do when launching a side project. Don’t leave keys in your repo 😅, don’t assume “no one will ever try X” because someone will, and definitely do invest in good documentation early. I spent some extra time writing docs so that new users and contributors can get onboarded easily, and that has already paid off.

So, what’s next for Ezzi? Now that it’s open source, I’m inviting the community to help shape its future. The roadmap includes several exciting features: hint-only mode for gradual assistance, LeetCode crusher for focused practice sessions, quiz mode for quick multiple-choice questions, and take-home algorithm support.

I’m sure the community will have even more creative ideas. If you’re an engineer who finds this project interesting, check out the GitHub repo.

How to Get Ezzi

# Build & run Ezzi in dev mode (Mac / Linux)

git clone https://github.com/GetEzzi/ezzi-app.git

cd ezzi-app && npm i && npm run dev

Ezzi’s source code is available on GitHub, and the README has instructions for both using the managed backend and running your own.

To try it out:

• Download the Ezzi app source code from the GitHub. It’s an Electron app, so one build works on your OS.
• Decide on self-hosted vs cloud - If self-hosting, follow the docs to deploy the backend (choose your favorite stack). If using cloud, simply create a free account via the app.
• Launch the app and log in or connect - On self-host, you’ll enter the URL of your backend and your API key. On cloud, just log in and choose a plan (there’s a free trial mode as well).
• Start a practice session - maybe open a LeetCode problem or some coding prompt, and hit the hotkeys to capture it. Play around with getting hints and solutions. The UI has tooltips explaining each button and shortcut.

I’m both excited and nervous to see Ezzi out in the wild. Excited because I truly believe it can help people learn faster and feel more confident in interviews.

Nervous because, well, anything touching the interview-cheating topic can be controversial. But open-sourcing it is the right move - it brings transparency and opens it up for improvement.

In closing, if you’ve ever felt that knot in your stomach before a technical interview, or found yourself blanking on a binary tree problem you know you studied, Ezzi might be the kind of backup you’d want. It’s like an AI pair-programmer for your interviews - there if you need it. I built it out of frustration, curiosity, and a desire to make the tech interview grind a little more human (ironically, by using AI).

GitHub: github.com/GetEzzi/ezzi-app

Website: getezzi.com

I hope this was helpful. Good luck, and happy engineering!

Building Ezzi: My Journey Creating an Invisible Tech Interview Assistant (Now Open Source) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the domain of web development, particularly within the Laravel framework, the structure of an application is intrinsically layered.

Understanding these layers is pivotal for Laravel developers, as they dictate how applications behave, scale, and maintain efficiency. The granularity of these layers is not arbitrary; it’s chosen based on the project’s scope, the developers’ proficiency, and the specific goals to be achieved.

Laravel, known for its elegant syntax and robust features, empowers developers to tailor their application architecture to the project’s demands.

Streamlining Development with Laravel

Developers can adopt a lean approach when crafting simpler applications or microservices with Laravel. In such scenarios, it’s acceptable to prioritize development speed over stringent adherence to certain “best practices.”

However, when scaling to a more monolithic structure, or when the application has to meet rigorous industry standards, Laravel’s architectural patterns offer the necessary sophistication. These standards are particularly relevant when considering data integrity and availability.

Laravel applications typically consist of some of the following layers:

1. Model Layer: Central to Laravel’s MVC (Model-View-Controller) architecture, the Model Layer interfaces with the database using Eloquent ORM, which simplifies data handling by representing database tables as classes.
2. Repository (or Interface) Layer: While not a default Laravel architecture, the Repository Pattern can be implemented to provide a further abstraction layer over Eloquent. This facilitates testing and swapping the ORM if needed.
3. Service Layer (Actions, Queries, Commands): encapsulates the application’s business logic, allowing interaction with the Model Layer or Data Transfer Objects (DTOs). Service classes in Laravel help in organizing business logic in a reusable and maintainable way.
4. Controller Layer: is where HTTP requests are processed. Controllers in Laravel validate user input and leverage services to execute business logic, adhering to the principles of thin controllers and fat models.
5. Middleware Layer: middleware intercepts HTTP requests to perform various tasks, such as authentication and logging, before the request hits the application or before the response is returned to the user.
6. View Layer: is tailored for API responses, where it manages the structure and delivery of data to clients. Leveraging Laravel’s resource classes, it provides a fluent and flexible way to transform models into JSON. This careful orchestration ensures that clients receive well-formed and consistent data payloads, crucial for robust API design and client-side integration.
7. Background Tasks Layer (Cron, Events/Listeners, Queue, Jobs): scheduler, event system, and queue management handle background tasks, allowing developers to schedule commands, listen for events, and queue jobs for asynchronous processing.

As we delve deeper into Laravel’s layered architecture, we will illuminate the roles and responsibilities of each layer and discuss the testing strategies that ensure their reliability and performance. By dissecting these layers, Laravel developers can build applications that are not only functionally rich but are also scalable and maintainable.

Model Layer

While it might be tempting to think that Laravel’s Eloquent models don’t require much testing, having a comprehensive test suite for your models (and factories indirectly) can save you time and headaches in the long run.

Even though Laravel and the Eloquent ORM are robust, tests assure that your additional configurations and relations are behaving as expected.

Repository Layer

Some engineers advocate for a repository layer as it can abstract the data access logic from the business logic. This layer acts as a bridge between the model and the business logic, which in theory, would simplify migration were you to switch ORMs mid-project. However, it’s important to note that Laravel comes with a single ORM — Eloquent — and does not natively support or expect you to switch out of it.

The repository pattern is not without its merits and drawbacks. Here is a concise examination of its implications:

Advantages of a Repository Layer

1. Decoupling: It separates the business logic from the data access layers, enhancing the maintainability of the codebase.
2. Testability: By using repositories, you can mock dependencies and write more isolated and focused tests.
3. Single Responsibility Principle: This design pattern is in line with the Single Responsibility Principle, ensuring each class has only one reason to change, thereby separating concerns effectively.

Disadvantages of a Repository Layer

1. Complexity: Implementing this pattern can add unnecessary complexity to the application, which might be unwarranted for smaller projects.
2. Leakage of Concerns: Fully abstracting the ORM is a challenge, and often Eloquent features end up being used directly, undermining the purpose of the pattern.
3. Learning Curve: For those unfamiliar with the pattern, it introduces an additional layer of learning, atop mastering Laravel and Eloquent.
4. Loss of ORM Features: Eloquent’s advanced features for handling relationships and other ORM-related tasks can be hindered by adding a repository layer.
5. Potential Over-Engineering: For many applications, the capabilities of Eloquent alone are adequate, and a repository layer could be considered an over complication.

Weighing Your Options

When deciding whether to introduce a repository layer to a Laravel application, the decision should be meticulously weighed. The perceived benefits of abstraction and testability must be balanced against the potential for increased complexity and the risk of losing out on some of the powerful features that Eloquent ORM provides.

For Laravel developers, the litmus test for introducing a repository layer is often the scale and expected growth of the application. Will the future of the application benefit from the abstraction, or will the immediate overhead outweigh the long-term benefits?

This decision must be informed by both the current state of your project and its trajectory. It is essential to consider your team’s familiarity with the Laravel framework and their ability to implement and maintain a repository pattern successfully.

Service Layer

As we delve deeper into the architectural components of Laravel, it becomes clear that the service layer holds a pivotal role. It is where the complex business logic and behavior of the application reside. Given its importance, the service layer is often a focus for extensive testing to guarantee the system operates as intended.

Testing in Laravel is an area where practicality should guide the process. Not every aspect requires the same level of scrutiny, but certain elements within the service layer demand thorough attention due to their critical impact on the application’s overall functionality and reliability.

Prioritizing Tests for the Service Layer

When it comes to testing the service layer, there are key areas that you should prioritize to ensure a solid foundation for your application:

1. Core Business Logic: This is the heart of your service layer. Tests should confirm that all fundamental operations, calculations, and logical conditions are working correctly.
2. Database Interactions: Given that services often handle data persistence, it’s crucial to test all Create, Read, Update, and Delete (CRUD) operations. These tests are vital for ensuring data integrity.
3. Data Transformation: If your service layer is responsible for transforming data — whether from database models to Data Transfer Objects (DTOs) or vice versa — tests should verify that this transformation is accurate.
4. Error Handling: Your service layer should gracefully handle errors and exceptional cases. Testing how the layer responds to unexpected scenarios is imperative to maintain stability.

Strategically Skipped Tests

In testing, efficiency is as valuable as thoroughness. Knowing what to skip can save time and resources while still maintaining a high-quality test suite:

1. Integration with Other Services: Within the service layer, you can skip testing the integration with external services or systems. Laravel provides an elegant way to mock such interactions, allowing you to simulate how your service layer would communicate with these external dependencies. This focus ensures that your tests remain within the scope of the service layer’s responsibilities and do not get bogged down by the intricacies of external services.

By emphasizing these areas, your testing efforts are directly aligned with the critical responsibilities of the service layer. Such a pragmatic and focused approach fosters a robust and maintainable test suite. It allows for rigorous verification of the service layer’s functionality while also keeping development agile and resource-efficient.

Conclusion

The strategy for testing a Laravel application’s service layer is not to cast as wide a net as possible, but rather to target the tests intelligently. By honing in on the most crucial components and interactions, and by leveraging Laravel’s features for simulating external dependencies, developers can create a test suite that is both comprehensive and efficient. It’s about ensuring quality where it matters most, while enabling the development process to remain lean and focused.

Controller Layer

The controller layer serves as a crucial nexus, orchestrating the flow between the user interface and the underlying business logic. Testing this layer is integral to ensuring that the user’s requests yield the right responses and that all the pieces of the application communicate seamlessly.

The Imperative of Testing the Controller Layer

The controller layer is the gatekeeper of your application’s HTTP interface, responding to user input, and marshaling resources to provide the desired output. Testing this layer is about validating the glue that binds the components of your application into a coherent, functioning whole.

Optimizing Controllers for Clarity and Maintainability

Aim for controllers that eschew bloat and focus sharply on their intended purpose:

1. Cleaner Controllers: Strive for controllers that are streamlined to address HTTP-specific concerns. This approach not only enhances readability but also simplifies maintenance, making your application more adaptable to change.

Core Areas for Controller Layer Testing

Controller testing in Laravel should target several key aspects to ensure comprehensive coverage:

1. Integration with Service Layer: Controllers should act as a thin layer that delegates business logic to the services. Tests need to confirm that controllers are correctly invoking services and handling the results as expected.
2. Access Control: Security is paramount. Your tests should verify that authorization and role-based controls are functioning correctly, and that routes intended to be protected are indeed inaccessible to unauthorized users.
3. Input Validation: The integrity of the data passing through your controllers is fundamental. Tests should be in place to ensure that user inputs are properly validated before they reach the core of your application.
4. Authentication: The robustness of authentication mechanisms cannot be overstated. Tests should ascertain that these systems are correctly recognizing valid users and effectively repelling unauthorized attempts.

Conclusion

Testing the controller layer in Laravel is less about examining of internal logic and more about ensuring the correctness of interactions and integrations. It’s a process that guarantees the user’s journey through your application is smooth and secure. By focusing on these key areas, developers can craft controllers that are not just functional, but also resilient and ready for the challenges of a dynamic web environment.

Middleware Layer

In the bustling digital ecosystem of a Laravel application, middleware stands as an unobtrusive yet vital guardian, orchestrating the smooth processing of HTTP requests and responses. It’s a layer that may not engage in the spotlight of business logic, but it is indispensable for maintaining the application’s technical integrity and operational efficiency.

Middleware in Laravel isn’t about flashy features; it’s about the essential, often invisible tasks that ensure your application remains secure, responsive, and well-maintained

Common Middleware Use Cases

The scope of middleware is vast, encompassing several non-negotiable aspects of modern web applications:

1. Rate Limiting: It’s the sentry that ensures your application can handle the influx of requests without compromising service.
2. CORS Handling: This function is the diplomat, determining which cross-origin requests are permissible, safeguarding against potential security issues.
3. Caching: Middleware acts as the efficient librarian, storing and recalling data to speed up response times.
4. Debugging: Think of this as the detective in your application, gathering clues to troubleshoot issues effectively.

Middleware Testing

Testing the middleware layer is like checking the reflexes of your application — it must respond correctly under various conditions:

1. Logging: Tests must ensure that activities within the application are being recorded accurately, helping you keep a vigilant eye on operations and issues.
2. Metrics Collection: Just as a doctor monitors vital signs, your tests should confirm that key performance metrics are being duly noted for analysis.
3. Request Routing: Ensuring that the application’s traffic control system is directing requests properly is akin to testing the reliability of a city’s traffic lights.
4. Authentication and Authorization: Occasionally, middleware takes on the role of a bouncer, deciding who gets in and who doesn’t, a critical aspect that must be tested for robust security.

Conclusion

Testing the middleware layer in Laravel is critical. It keeps the application secure and efficient by managing requests and maintaining performance. Solid middleware testing ensures a stable and secure application foundation.

View Layer

In Laravel, the view layer holds a significant role, especially in shaping how data is presented to the end-users. Testing this layer is paramount in API-driven applications, where the correctness and structure of the output are as critical as the back-end processing.

What to Test in the View Layer

1. API Resources: Ensure that the API outputs are presenting data in the correct structure and include all necessary fields. Pay attention to pagination and other factors that affect the stability and performance of the application.
2. Response Validation: It’s essential to verify that the application’s responses are as expected, regardless of the complexities or operations performed in the back-end. The end-user’s experience is defined by the accuracy and consistency of these responses.

The goal is to ensure that any changes to the application’s internal logic do not adversely affect the user’s experience. By diligently testing the view layer, you affirm that the application reliably communicates with clients, maintaining the contract expected by API consumers. This step is vital in sustaining the application’s functionality and user trust.

Background Tasks Layer

The Background Tasks Layer is indispensable for handling asynchronous operations and ensuring scalability. This includes managing events, queues, and scheduled tasks, which, if properly utilized, greatly enhance the application’s performance and responsiveness.

What to Test in the Background Tasks Layer

1. Cron Jobs: Verify that cron jobs are triggering at their designated times and performing their intended tasks correctly.
2. Queued Jobs (Regular): Check that queued jobs are being processed and completed successfully.
3. Event Handling: Test that events trigger the right listeners and that those listeners respond correctly.
4. Database Integrity: For tasks that modify the database, it’s essential to confirm that these alterations are correctly implemented.
5. Asynchronous Processes: Evaluate the sequence and execution of asynchronous operations, particularly in multi-step workflows.

With Laravel’s robust testing features, developers can effectively simulate background processes, ensuring these critical tasks perform reliably and contribute to the overall efficiency of the application.

Conclusion

In Laravel, implementing and testing various layers — from models to middleware to background tasks — ensures a robust, maintainable, and scalable application.

Thorough testing across these layers not only fortifies data integrity and application performance but also streamlines future development.

Ultimately, it’s the careful balance of structure and testing that lays the foundation for a Laravel application’s long-term success.

I hope this was helpful. Good luck, and happy engineering!

If you are a visual learner, check out my free Udemy course that covers Laravel Testing topics.

For part one of Laravel Testing series check here.

For part two of Laravel Testing series check here.

Laravel — Discover Application Layers for Testing was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we’ll discuss a variety of practices that can greatly enhance your test suite. Some of these are straightforward to implement, while others might require a paradigm shift in how you think about testing. These practices are particularly beneficial for larger projects, where development speed can often slow down as the application grows in complexity.

Strict Checks & Strong Typing

Let’s talk about strict checks and strong typing, which I consider to be essential elements for any long-term software project.

Strong Typing

Strong typing doesn’t just help us prevent coding errors, it also acts as a form of documentation via method signature type hints. With strong typing in place, it becomes easier to understand the properties and types of objects you’re working with. This is particularly useful for IDEs, which can provide hints and catch issues quicker.

<?php

declare(strict_types=1);

namespace App\DTO;

use Spatie\DataTransferObject\DataTransferObject;

class UserRegistrationDto extends DataTransferObject
{
    public string $firstName;

    public string $lastName;

    public string $email;

    public string $password;
}

Below is how you can handle a user registration Data Transfer Object (DTO) in a type-safe manner, thanks to strong typing:

Strict Checks

Strict type declarations are a PHP-specific feature that I personally like to include in every new PHP file I create, even configuration files. I strongly advocate for this approach because it adds another layer of reliability to your code.

For instance, consider a situation where a type mismatch occurs in a user delete request; the DTO is supplying an integer, but the model is expecting a string. If strict types are not enabled, PHP will do a silent type coercion.

In PHP, type coercion refers to the automatic or implicit conversion of values from one data type to another. This allows you to perform operations between different types without explicitly casting them. For example, when using the loose equality operator `==`, PHP may convert a string and an integer to the same type before performing a comparison (`”42" == 42` evaluates to `true`). While convenient, type coercion can lead to unexpected behavior and bugs, especially when you’re dealing with functions that expect specific types or when using loose comparison operators.

By adding declare(strict_types=1); at the top of your files, you disable PHP’s silent type coercion, thereby reducing potential errors.

Note: Strict checks only apply to the file that includes the declaration. Importing a “strict” file into a non-strict file doesn’t make the latter strict.

Strict Checks for Test Suite

For a more comprehensive layer of stability across your software project, you should also incorporate strict checks within your test suite.

The first step is to add declare(strict_types=1);at the top of each test case file.

<?php

declare(strict_types=1);

namespace Tests;

class AssertJsonTest extends TestCase
{}

Laravel provides a variety of useful testing helpers that may seem similar but actually behave differently in subtle ways. Understanding these nuances is crucial when aiming for stricter type checking in your project.

Now, let’s take a closer look at how assertEquals() differs from assertSame():

The usage of assertEquals() can result in silent type casting, meaning you could be validating two different types without even realizing it.

/** @test */
public function assertEquals_demo(): void
{
    $this->assertEquals(1, '1');
    $this->assertEquals(1, '1.0');
}

Switching to assertSame() immediately exposes any type discrepancies and will cause the test to fail.

/** @test */
public function assertSame_demo($actual): void
{
    $this->assertSame(1, '1');
    $this->assertSame(1, '1.0');
}

Failed asserting that ‘1’ is identical to 1.

Failed asserting that ‘1.0’ is identical to 1.

For this reason, I highly recommend using more rigorous test methods like assertSame() wherever possible.

For value assertions, assertSame() is often the go-to method, while assertJson() is commonly used for validating HTTP responses during integration testing.

However, it’s crucial to understand the difference between assertJson() and its stricter counterpart, assertExactJson(). The former only validates that the expected keys and values exist in the API response, but it ignores any additional data returned. For instance, if your response unintentionally includes sensitive information like a user’s password, assertJson() wouldn’t catch that issue.

/** @test */
public function assertJson_demo(): void
{
    $response = new TestResponse(
        new Response([
            'name' => 'Dmitry',
            'age' => 30,
            'password' => 'secret',
        ], 200)
    );

    $response->assertJson([
        'name' => 'Dmitry',
        'age' => 30,
    ]);
}

Switching to assertExactJson() offers stricter validation; it ensures that the response contains only the specified data, helping you identify any unintentional data leaks immediately.

/** @test */
public function assertExactJson_demo(): void
{
    $response = new TestResponse(
        new Response([
            'name' => 'Dmitry',
            'age' => 30,
            'password' => 'secret',
        ], 200)
    );

    $response->assertExactJson([
        'name' => 'Dmitry',
        'age' => 30,
    ]);
}

Failed asserting that two strings are equal.
<Click to see difference>

SQLite vs. DB Testing

By default, and as seen in numerous Laravel tutorials, testing against an in-memory SQLite database is a commonly recommended approach. This strategy is particularly useful for small demos, negating the need to set up additional databases or services. However, this approach comes with certain limitations that are critical to consider, especially if you’re not running SQLite in your production environment.

Key Differences Between SQLite and Traditional Databases like MySQL or PostgreSQL:

1. Foreign Key Constraints: In SQLite, foreign keys are disabled by default. Although Laravel 10+ has addressed this issue, it remains a concern for older projects. When testing with SQLite, you might overlook the absence of foreign key checks, creating a false sense of security.
2. Dynamic Typing: SQLite employs dynamic typing, which allows you to store any value of any data type in any column, regardless of the column’s declared type. While this may appear flexible, it poses a risk of data integrity issues that could easily slip past your test suite.
3. Database-Specific Syntax: If your application relies on database-specific syntax or functions, then testing with SQLite may not be viable at all.

Why These Differences Matter

Understanding these nuances is critical for validating the reliability of your test suites. While SQLite testing is quick and convenient, it might not comprehensively simulate a real-world, production database environment. Therefore, it’s advisable to not rely solely on in-memory database testing for complex, real-world projects.

DB Testing Performance

You might initially be concerned about the performance hit when shifting from SQLite to a more robust database like MySQL for testing. However, the slight decrease in speed is often outweighed by the benefits of more accurate testing. For small to medium-sized projects, you’ll likely find that the performance difference is negligible.

For larger projects, bootstrapping may take a bit longer as you’ll need to run all the database migrations first. However, the overall runtime of the test suite remains fairly comparable, especially when you’re testing against an empty database.

To improve test suite performance, you can use features like schema dumping (php artisan schema:dump) to reduce boot time or consider parallel testing. Laravel 10+ allows parallel testing by default; for older projects, you might want to look into using the paratest library.

Getting Started with Database Testing

To shift your primary testing database driver to something like MySQL, you’ll need to make appropriate changes in your phpunit.xml configuration file.

<?xml version="1.0" encoding="UTF-8"?>
...
    <php>
        <env name="APP_ENV" value="testing"/>
        <!-- <env name="DB_CONNECTION" value="sqlite"/>-->
        <!-- <env name="DB_DATABASE" value=":memory:"/>-->
        <env name="DB_CONNECTION" value="mysql"/>
        <env name="DB_DATABASE" value="forge"/>
    </php>
</phpunit>

By being aware of these limitations and performance considerations, you can make more informed choices about your database testing strategies, which will pay off in the long run.

Array Cache vs. Redis Cache

Testing Redis integration in a Laravel application can yield different outcomes compared to testing with Laravel’s default array cache driver. Understanding these differences is essential for ensuring that your application behaves as expected, especially if you intend to use Redis in production.

Cache Value Retrieval Differences

Here’s an example to illustrate the point. Imagine you store a float value in the cache and later attempt to retrieve it. Using Laravel’s array driver, you’ll get exactly the value you stored.

/** @test */
public function integrity_with_cache(): void
{
    Cache::set('rate', 1.55);

    $this->assertSame(1.55, Cache::get('rate'));
}

However, the Redis driver behaves differently. When you retrieve a value from Redis, it returns as a string, regardless of its original data type, and the same test will fail due to the type mismatch.

Failed asserting that ‘1.55’ is identical to 1.55.

Potential Issues and Solutions

1. Type Errors: If your application relies on strict data types, this discrepancy can lead to TypeError. In other words, passing a string-retrieved value from Redis into a function that expects a float will trigger an error.
2. Implicit Typecasting: When strict type checks are not enforced, PHP may implicitly cast the string to an integer, leading to unexpected behavior and even bugs that appear to be rooted in your business logic.

Therefore, if your production environment utilizes Redis, it’s advisable to use Redis for your cache testing as well.

Configuring PHPUnit for Redis Testing

To begin using Redis as your primary cache driver in your PHPUnit tests, you’ll need to adjust your phpunit.xml configuration file appropriately.

<?xml version="1.0" encoding="UTF-8"?>
...
    <php>
        <env name="APP_ENV" value="testing"/>
        <!-- <env name="CACHE_DRIVER" value="array"/>-->
        <env name="CACHE_DRIVER" value="redis"/>
        <env name="REDIS_DATABASE" value="10"/>
    </php>
</phpunit>

In summary, testing with a driver that you plan to use in production is crucial for catching subtle issues that may not surface when using Laravel’s array cache driver. The slight complexities of setting up your test environment to use Redis are outweighed by the benefit of knowing your application will behave as expected in a production setting.

Working With Dates

Date-related issues in your test suite can lead to flaky and unreliable tests, a problem that is particularly amplified when using PHPUnit with Laravel. Let’s delve into common challenges and solutions for ensuring date reliability in your tests.

Time-Dependent Tests

Say you have a reporting system that relies on date filters. You’d naturally want to assert that data points fall within a certain date range. A common practice is to use Laravel’s now() helper function to generate these data points. However, as your test suite grows, the variable execution time can cause now() to drift, leading to inconsistent results.

To address this, one option is to lock the value of now() using Carbon’s setTestNow() method, which ensures that now() returns a consistent time throughout the test run.

$now = now(); // this value is not fixed during test suite run
Carbon::setTestNow($now); // fixes now() to always return one value

Alternatively, you could specify explicit dates for your tests, particularly in scenarios where dates are crucial, like in reporting or data aggregation.

$now = CarbonImmutable::parse('2023-09-01 10:00:00');
Carbon::setTestNow($now); // fixes now() to always return one value

Explicitly setting dates in your tests not only eliminates flakiness but also improves code readability, aiding comprehension for future maintenance.

Daylight Saving Time (DST) Challenges

Another unexpected source of test flakiness is Daylight Saving Time changes, which can affect time calculations in your tests. For example, let’s say your tests are pegged to Canada’s DST schedule.

If your test suite runs on different dates around the DST change, you might experience time calculation discrepancies. The solution? Again, use explicit dates and times in your tests, and keep them constant across the test case.

App & Database Timezone

As an added layer of reliability, consider setting the default timezone to UTC in both your Laravel application and your database.

In PHP, you can verify the server’s timezone setting like so:

echo date_default_timezone_get();

Database timezone checks vary by engine. In a PostgreSQL database, you can check the current time zone setting by executing the following query:

SHOW timezone;

In MySQL, you can check the current time zone setting by executing the following query:

SHOW GLOBAL VARIABLES LIKE 'time_zone';

In summary, the key to a reliable, time-sensitive test suite is consistency. By explicitly setting date-time values and sticking to a standard timezone, you eliminate variables that can make your tests flaky and hard to debug.

I hope this was helpful. Good luck, and happy engineering!

If you are a visual learner, check out my free Udemy course that covers Laravel Testing topics.

For part one of Laravel Testing series check here.

Optimizing Your Laravel Test Suite: Paradigm Shifts was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

Laravel is one of the most popular PHP frameworks and is a good choice for PHP developers.

In this article, I want to share my approaches and practices to discovering Laravel framework testing potential. This approach has proven its efficiency on large projects that have grown over the years.

I will describe a few testing paradigms that might be mind-changing to you, but this is my experience based on running large Laravel projects.

It does not matter much if you start a green field project or join a team on a new project.

These are some ideas I want you to care about when building your test coverage.

The examples are in PHP and with the Laravel framework in mind, but you can translate those concepts into your preferred language. This approach is what works for me in PHP, Node.js, and TypeScript development.

Future-proof tests

First is — “I want myself 6 months in the future to be able to exactly understand the logic behind test cases I write today”.

When we’re fully immersed in the task, we think everything we write is obvious, but in most cases, it is not.

Second — “I want my tests to serve as documentation to my controllers, services, and overall business logic behind it”.

This means I will use the service under test in a most verbose way.

Say we’re testing controllers — I want to immediately show off the available request options for that.

If I test a business logic layer, I want to show exactly the expected input format for my code.

This helps a lot in weakly typed languages like PHP or JavaScript.

Finally, I want my colleagues to onboard with my code faster, I want them to be going with their changes sooner than later. And understandable test cases help me achieve that.

So here are the topics for this article.

• Test Suite Folder Structure — this is how I recommend organizing your test suite folders.
• Test Case Naming — my recommendations and a pattern for understandable test names.
• Test Case Flow — will describe how is best to structure individual test cases.
• Clear assertions — then I want to talk about assertions and use cases.
• Use Case Coverage vs. Statement Coverage — next, we’ll discuss the divergence between use case coverage and statement coverage.

Test Case Folder Structure

Laravel proposes a fixed folder structure for all projects, for example, you will most likely have all your controllers under

\App\Http\Controllers folder with all your custom code under that folder.

Some projects may do something different, for example, if they follow a modular approach and their folder structure can look like this.

With either approach, you are required by PSR-4 standard (https://www.php-fig.org/psr/psr-4/) to have a class namespace replicate a folder structure in the file system.

This is also how the composer will traverse your source directory and build a class map, if you do not follow PSR-4 you’ll be in trouble anyways.

When creating the test suite you want to follow the same pattern.

• The root namespace for your test would be either Unit, Feature, or Integration.
• Followed by a fully replicated folder structure of a class under tests.
  - \App\Unit\Http\Controllers
  - \App\Feature\Http\Controllers
  - \App\Integration\Http\Controller
• Then you name the test case file the same as your class with the “Test” suffix. This is a default suffix for PHPUnit to pick up your tests and run them.
  - UserControllerTest

If your IDE allows — you can automate the creation of your test case files.

If you make a mistake in creating namespaces you’ll get a hint and the possibility to fix it immediately.

Why do I propose this structure?

This way your test files have the expected folder structure, anyone looking over the code can locate the test files by following the same path in the tests folder.

Another benefit is when you browse your files via global search you can easily tell which test file is responsible for Unit and Feature test cases by reading its namespace in the search dialog.

Test Case Naming

Choosing a good test case name is hard if you don’t follow a pattern. Reading poorly named tests is also hard, so help yourself and your colleagues to create readable and understandable test names.

Once you’re familiar with the common patterns it becomes easy. In this section, I will describe my recommended approach to test case naming

Points:

1. Select a case pattern and stick with it — snake case or camel caps case.
   - I prefer the snake case because it differs from the camel case I use in regular code, so I can quickly tell the difference.
2. Have descriptive names
   - don’t be afraid to be too verbose, it’s great to be so for the test suite.
   - have inputs and expected output in the test’s name.
3. Select a naming pattern and keep it consistent
   - some approaches are to use keywords like “it”, “test”, and “when*”.

Now let’s go over some patterns for naming. And will review it with an example.

We have a Math class with an add method. It accepts 2 arguments and returns the sum.

My favorite test case naming pattern is this:

<ACTION> when <CONDITION> then <RESULT>

This can be written using snake case in the PHPUnit file

/* @test */
add_when_input_is_2_and_1_then_result_is_3(): void {}

and it translates to the following:

• ACTION — is usually our method for test
• CONDITION is where we describe test inputs
• and RESULT is where we describe expected outputs

Between those points, we have 2 keywords — WHEN and THEN

Or if you work with JavaScript, Node.js, or Pest for PHP then it can read something like this:

describe(‘add’) { …
test(‘when 2 and 1 then result is 3’) {}

Another popular pattern for writing test names is like this:

it <RESULT> when <ACTION><CONDITION>

This is most commonly seen in JavaScript tutorials, Node.js tutorials, or when using Pest for PHP projects (smaller ones).

I prefer the first option for PHP and use the test() helper if I work with JS/Node.js.

/* @test */
add_when_input_is_2_and_1_then_result_is_3(): void {}

test('when 2 and 1 then result is 3') {}

Test Case Flow

Having a structured pattern for all of your tests is a benefit too. To create a common structure for each of my test cases, I usually split the test code into stages. Each stage is responsible for 1 aspect of the test case — arrange, act, or assert.

THE ARRANGE stage is where you prepare your environment to execute the test, create models, set variables, and so on.

THE ACT stage is where your class or method under test will be called.

This will usually include any related objects that are important for the context — like request body, data transfer object instantiation, and so on.

THE ASSERT stage is where you check if your case was a success or not by writing up the assertions for the test to pass or fail.

3 flow patterns will cover almost 100% of writing test cases.

Straightforward with arrange/act/assert.

/**
 * We're testing the run() method of the OfferTimeoutService class.
 * When the offer is updated more than 10 minutes ago, it should become inactive.
 * @test
 */
public function run_when_offers_is_not_updated_for_10_minutes_then_it_will_be_deactivated(): void
{
    // arrange
    $config = ['dataserver.ads.ad_active_timeout_seconds' => 600];
    $offer = new Offer(isActive: true, updatedAt: new DateTime('-11 minutes'));

    // act
    $service = new OfferTimeoutService($offer, $config);
    $result = $service->run();

    // assert
    $this->assertFalse($result->isActive);
}

Arrange first, assert with mock, and act.

/**
 * @test
 */
public function run_when_config_is_empty_then_throws_an_exception(): void
{
    // arrange
    $config = [];
    $offer = new Offer(isActive: true, updatedAt: new DateTime('-11 minutes'));

    // assert
    $this->expectException(\RuntimeException::class);

    // act
    $service = new OfferTimeoutService($offer, $config);
    $service->run();
}

Just an assert and act (typically for exception testing).

/**
 * @test
 */
public function run_when_offer_is_null_then_throws_an_exception(): void
{
    // assert
    $this->expectExceptionMessage('Offer is not set');

    // act
    $service = new OfferTimeoutService(offer: null, config: null);
    $service->run();
}

We can also remove an ARRANGE stage comment if it’s going first.

/**
 * @test
 */
public function run_when_config_is_empty_then_throws_an_exception(): void
{
    $config = [];
    $offer = new Offer(isActive: true, updatedAt: new DateTime('-11 minutes'));

    // assert
    $this->expectException(\RuntimeException::class);

    // act
    $service = new OfferTimeoutService($offer, $config);
    $service->run();
}

Another point here is you don’t want to overdo it. If your test case is 2–3 lines long just having a blank line separation is good enough. Keeping in mind that you still have ARRANGE ACT and ASSERT stages.

/** @test */
public function run_when_offer_is_null_then_throws_an_exception(): void
{
    $this->expectExceptionMessage('Offer is not set');

    $service = new OfferTimeoutService(offer: null, config: null);
    $service->run();
}

Here are the building blocks for your test cases. You have 3 workflows that will cover most of your use cases.

Clear Assertions

When something breaks you want yourself 6 months from now to know exactly what the problem is and not spend much time understanding old code.

We already discussed the test case naming pattern and test case structure. The final argument in this equation is creating as clear assertions as possible and keeping them focused on 1 thing at a time.

I prefer my test cases to assert only 1 thing at a time. This correlates to a software engineering principle known as Single Responsibility.

This does not mean you only ever have 1 assertion line in your test, but rather your assertions are focused on demonstrating only 1 use case.

An example of this approach would be this test case.

/** @test */
public function api_offers_data(): void
{
    (new Offer(isActive: true, updatedAt: new DateTime()))->count(3)
        ->create();

    // act
    $this->actingAs('admin');
    $response = $this->getJson('/api/offers');

    // assert
    $response->assertStatus(200);
    $response->assertJsonStructure([
        'data' => [
            [
                'count',
                'price',
                'isActive',
                'updatedAt',
            ],
        ],
    ]);
    $data = $response->decodeResponseJson()->json();
    $this->assertSame(3, $data['count']);
}

It has a really bad name for a test, is not helpful at all, and tests too many things at once

• the HTTP response code
• the response structure
• and the actual data

In your application, you can have a bug on different levels of abstraction and you want only a specific test, dedicated to this level, to break.

• Response code validation usually refers to access control validation, for roles, permissions, and so on.
• Response structure validation is an integration test for having valid and expected fields returned within your API.
• and finally, when testing the actual data, is when we validate our business logic and the results are the same as expected.

We can refactor this into 3 different test cases.

First, we separate the response code test.

/**
 * This test only validates that ADMIN role can access the API.
 * @test
 */
public function api_offers_when_with_admin_role_then_response_code_is_200(): void
{
    (new Offer(isActive: true, updatedAt: new DateTime()))->count(3)
        ->create();

    // act
    $this->actingAs('admin');
    $response = $this->getJson('/api/offers');

    // assert
    $response->assertStatus(200);
}

Then a separate test for structure.

/**
 * This test only validates API resource expected structure for ADMIN role.
 * @test
 */
public function api_offers_when_with_admin_role_then_response_structure_same_as_expected(): void
{
    (new Offer(isActive: true, updatedAt: new DateTime()))->count(3)
        ->create();

    // act
    $this->actingAs('admin');
    $response = $this->getJson('/api/offers');

    // assert
    $response->assertJsonStructure([
        'data' => [
            [
                'count',
                'price',
                'isActive',
                'updatedAt',
            ],
        ],
    ]);
}

And finally, a test for the business logic.

/**
 * This test only validates API has correct data for ADMIN role.
 * @test
 */
public function api_offers_when_with_admin_role_then_response_has_expected_offer_count(): void
{
    (new Offer(isActive: true, updatedAt: new DateTime()))->count(3)
        ->create();

    // act
    $this->actingAs('admin');
    $response = $this->getJson('/api/offers');

    // assert
    $data = $response->decodeResponseJson()->json();
    $this->assertSame(3, $data['count']);
}

In an application, you would also have all those tests under different files and namespaces, that represent their use cases.

Use Case Coverage vs. Statement Coverage

There are different forms of test coverage and as software engineers, we aim to reach high coverage in:

• Statement coverage
• Branch coverage
• Code coverage

Those are all related to lines of code directly and are helpful. You can easily have 100% coverage at the start of the project, but eventually, it’ll degrade. You most likely will need more time or resources to keep up with a growing code base.

Don’t be upset tho. I suggest not aiming for 100% statement, branch, or code coverage at all.

Try focusing on the USE CASE coverage instead.

To show you how this concept is different from just statement coverage — let’s go over a quick example here.

I have a DataService that will accept the user’s role as input and will provide a response, success or failure.

class DataService
{
    public function getWithRole(Role $role): array
    {
        if ($role->value === Role::Admin->value) {
            return [
                'status' => 'success',
            ];
        }

        return [
            'status' => 'fail',
        ];
    }
}

I made some test coverage based on user roles.

/** @test */
public function getWithRole_when_admin_role_then_status_is_success(): void
{
    $service = new DataService();
    $data = $service->getWithRole(Role::Admin);

    // assert
    $this->assertSame('success', $data['status']);
}

/** @test */
public function getWithRole_when_user_role_then_status_is_fail(): void
{
    $service = new DataService();
    $data = $service->getWithRole(Role::User);

    // assert
    $this->assertSame('fail', $data['status']);
}

If the user is an admin, I expect a “success” response. If just a user role, then the “fail” response. If I run PHPUnit with a coverage report I will get 100% coverage on all metrics.

Now let me show you the Role enum, and you can see here we have 1 role that was not used in our scenarios. And PHPUnit can easily miss that.

enum Role: string
{
    case Admin = 'admin';
    case User = 'user';
    case Guest = 'guest'; // TODO: this role USE CASE is not covered
}

This is a simplified example, the amount of files in my demo project is small, and so on, but in a large project, it would be even easier to miss such things.

We can see that we have a 100% coverage report, but I only used 2 roles out of 3. I’m not confident in that code anymore, since I don’t see how it is expected to behave with a guest role.

Let’s fix that by forming data provider arrays for each of our tests and focusing on use case coverage.

public static function allowedRoleProvider(): array
{
    return [
        [Role::Admin],
    ];
}

public static function forbiddenRoleProvider(): array
{
    return [
        [Role::User],
        [Role::Guest],
    ];
}

Now I can write my test for allowed roles:

/**
 * @test
 * @dataProvider allowedRoleProvider
 */
public function getWithRole_when_allowed_role_then_status_is_success(Role $role): void
{
    $service = new DataService();
    $data = $service->getWithRole($role);

    // assert
    $this->assertSame('success', $data['status']);
}

And forbidden roles:

/**
 * @test
 * @dataProvider forbiddenRoleProvider
 */
public function getWithRole_when_forbidden_role_then_status_is_fail(Role $role): void
{
    $service = new DataService();
    $data = $service->getWithRole($role);

    // assert
    $this->assertSame('fail', $data['status']);
}

We still have 100% coverage but we also achieved 100% use case coverage for that feature.

I suggest always aiming to implement USE CASE coverage. Here are some guidelines on how you can come up with good use cases:

• First to test the happy paths.
• Then test — bad inputs.
• Then any other limitations by task requirements.
• And finally, think of possible edge cases.

This last step is what will separate great engineers from just the good ones.

Bonus point — “setUp()” method

This one is specific to Laravel and PHP.

You MUST NOT create models, mocks, or faking Events, Notifications, etc. inside the setUp(): void method.

Consider other developers adding tests to files you created, they would have to deal with the overhead of created models they do not want to use (.i.e. to make a count() assert against the same model).

Good:

public function my_test(): void
{
  $user = factory(User::class)->create();
  $restroom = factory(Restroom::class)->create();
  $secret = str_random(40);
  config()->set('app.api_secret', $secret);
  
  // your test case...
}

Bad:

public function setUp(): void
{
  parent::setUp();
  $this->user = factory(User::class)->create();
  $this->restroom = factory(Restroom::class)->create();
  $this->secret = str_random(40);
  config()->set('app.api_secret', $this->secret);
}

public function my_test(): void
{
  // your test case...
}

Also, making setUp() as minimal as possible makes all dependencies explicitly visible in each test.

Conclusion

I reviewed the following points for creating a great test suite that can stand the test of time.

• Test Suite Folder Structure — adhere to PSR-4 standard and make paths obvious to other devs, possibly fully replicating the App folder structure.
• Test Case Naming — have a pattern for naming and stick with it, your test name should give an idea of what it does exactly.
• Test Case Flow — there are only a few options for structuring test cases and you can follow them and simplify your day-to-day work even more.
• Clear assertions — keep SRP in mind when writing your assertions.
• Use Case Coverage vs. Statement Coverage — aim for use case coverage.

I hope this was helpful. Good luck, and happy engineering!

If you are a visual learner, check out my free Udemy course that covers Laravel Testing topics.

Laravel Test Suite — Best Practices was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I want to chat about elements of scalable event-driven applications available to developers with the Nest.js framework. I will demonstrate how easy it is to get going with a modern framework for building backend Node.js applications.

Agenda

What is Nest.js?

How Does Nest.js Help Build Highly-Scalable Apps?

Demo App and Tools

Demo App in Action

I want to briefly write about what is Nest.js and how does it help build scalable applications? I have a demo ready for you. We will describe the overall architecture and the tools used, then run and see our demo in action.

What is Nest.js?

It’s a framework for building Node.js applications.

It was inspired by Angular and relies heavily on TypeScript.

So it provides a somewhat type-safe development experience. It’s still JavaScript after transpiling, so you should care when dealing with common security risks.

It is a rather popular framework already, and you have probably heard about it.

Why use another framework?

• Dependency injection
• Abstracted integration with databases
• Abstracted common use cases: caching, config, API versioning and documentation, task scheduling, queues, logging, cookies, events, and sessions, request validation, HTTP server (Express or Fastify), auth.
• TypeScript (and decorators)
• Other design elements for great applications: Middleware, Exception filters, Guards, Pipes, and so on.
• And some more, which I will talk about later

Let’s quickly recap what the framework offers us.

One of the main advantages of using a framework is having a dependency injection. It removes the overhead of creating and supporting a class dependency tree.

It has abstract integration with most databases, so you don’t have to think about it. Some of the most developed and popular packages supported are mongoose, TypeORM, MikroORM, and Prisma.

It has abstracted common use cases for web development like caching, configuration, API versioning and documentation, queues, etc.

For the HTTP server, you can choose between Express or Fastify.

It uses TypeScript and decorators. It simplifies reading code, especially in bigger projects, and allows the developers’ team to be on the same page when reasoning about components.

Also, as with any framework, it provides other application design elements like middleware, exception filters, guards, pipes, and so on.

And finally, we’ll talk later about some other features that are specific to scalability.

How Does Nest.js Help Build Highly-Scalable Apps?

Let’s first recap the main strategies for building highly scalable applications.

Here are the options:

• Monolith (modular)
• Microservices
• Event-driven
• Mixed

Software development is all about trade-offs.

The first approach I want to talk about is using monolith.

It’s a single application that has components tightly coupled.

They are deployed together, supported together, and usually, they can’t live without one another.

If you write your application that way, it’s best to use a modular approach, which Nest.js is very good at.

When using the modular approach, you can effectively have one codebase, but components of your system act as somewhat independent entities and can be worked on by different teams. This becomes harder as your team and project grow. That’s why we have other models for architecture development.

Microservices

Microservices are when you have separate deploys for each service. Usually, each service is only responsible for a small unit of work and will have its store.

The event-driven approach is similar to microservices.

Now, you don’t have direct communication between services. Instead, each service will emit an event, and then it doesn’t care.

There can be listeners to this event, but there can be no listeners. If someone consumes the event, it can again produce another event that another service can consume, and so on.

Eventually, someone will produce a response for the client waiting. It could be a WebSocket response or webhook or whatever.

Services will communicate with other services via HTTP requests or messaging.

Mixed architecture

Usually, our larger projects are a mix of all designs — some components are tightly coupled and deployed together, some components are deployed separately, and some are communicating exclusively via event messaging.

Nest.js = Easy Event-Driven Application Development

Let’s think about why this framework simplifies event-driven development.

• Integrates with Redis/Bull for queue management (github.com/OptimalBits/bull)
• Integrates with most messaging brokers
• Promotes modular development
• Great documentation and examples
• Unit and integration testing is bootstrapped (DI, Jest)

First, it allows fast and simple integration of the popular Bull package for queues.

For microservices development and communication, it has integrations with the most popular messaging brokers like Redis, Kafka, RabbitMQ, MQTT, NATS, and others.

Third, it promotes modular development, so it’s naturally easy for you to extract single units of work later in the project’s life cycle.

My next point is that it has great documentation and examples, which is always nice. You can be running your first distributed app in minutes.

And another thing I want to note is unit and integration testing is bootstrapped for you. It has DI for testing and all other powerful features of the Jest testing framework.

Queues (npm/bull)

Now, let’s see how a simple queue can be created in NestJS.

Queues: adding the connection

First, you install the required dependencies with the following command:

npm install --save @nestjs/bull bull
npm install --save-dev @types/bull

Then you create a connection to Redis.

An example of Nest.js connection to Redis with Bull.

BullModule.forRootAsync({
  imports: [ConfigModule],
  useFactory: async (configService: ConfigService) => ({
    redis: {
      host: configService.get('REDIS_HOST') || '127.0.0.1',
      port: +configService.get('REDIS_PORT') || 6379,
      password: configService.get('REDIS_PASSWORD') || undefined,
    },
  }),
  inject: [ConfigService],
}),

And finally, register a queue.

An example of Nest.js queue registering with Bull.

BullModule.registerQueue({
  name: TRADES,
}),

Queues: event producer injects a queue

An example of Nest.js emitting events with Bull.

export class TradeService {
  constructor(@InjectQueue(TRADES) private queue: Queue) {}

  async add() {
    const uuid = randomUUID();

    await this.queue.add({ uuid });
  }
}

Next, somewhere else in a service constructor, you type-hint your queue, and it gets injected by the Dependency Injection container — you now have full access to the queue and can start emitting events.

Queues: event consumer processes the queue

An example of Nest.js consuming events with Bull.

@Processor(TRADES)
export class TradeService {
  @Process()
  async process(job: Job<TradeCreatedDto>) {
    // ...
  }
}

Somewhere in another module, you decorate your processor class with Processor() and Process() a minimal setup to have a queue system working.

You can have producers and consumers exist in one application or separately. They will be communicating via your message broker of choice.

Messaging Integration — Connection

Message provider connection starts with adding a client module connection. In this example, we have Redis transport and should provide Redis-specific connection options.

An example of Nest.js registering messaging client module with Redis.

@Module({
  imports: [
    ClientsModule.register([
      {
        name: 'MATH_SERVICE',
        transport: Transport.REDIS,
        options: {
          host: 'localhost',
          port: 6379
        }
      },
    ]),
  ]
  ...
})

Messaging Integration — Producer

The next step is to inject the client proxy interface into our producer service.

An example of Nest.js injecting messaging client modules into a service class.

constructor(
  @Inject('MATH_SERVICE') private client: ClientProxy,
) {}

Our options further are either SEND method or EMIT.

SEND is usually a synchronous action, similar to an HTTP request, but is abstracted by the framework to act via selected transport.

In the example below the accumulate() method response will not be sent to the client until the message is processed by the listener application.

An example of Nest.js sending messages to remote service via a messaging broker.

accumulate(): Observable<number> {
  const pattern = { cmd: 'sum' };
  const payload = [1, 2, 3];
  return this.client.send<number>(pattern, payload);
}

EMIT command is an asynchronous workflow start, it will act as fire and forget OR in some transports, this will act as a durable queue event. This will depend on the transport chosen and its configuration.

An example of Nest.js emitting messages to remote service via a messaging broker.

async publish() {
  this.client.emit<number>('user_created', new UserCreatedEvent());
}

SEND and EMIT patterns have slightly different use cases on the CONSUMER side. Let’s see.

Messaging Integration — Consumer

MessagePattern decorator is only for sync-alike methods (produced with the SEND command) and can only be used inside a controller-decorated class.

So we expect some response to the request received via our messaging protocol.

An example of Nest.js responding to remote service via a messaging broker.

@Controller()
export class MathController {
  @MessagePattern({ cmd: 'sum' })
  accumulate(data: number[]): number {
    return (data || []).reduce((a, b) => a + b);
  }
}

On the other hand, EventPattern decorator can be used in any custom class of your application and will listen to events produced on the same queue OR event bus, and it does not expect our application to return something.

An example of Nest.js processing a message from a remote service via a messaging broker.

@EventPattern('user_created')
async handleUserCreated(data: Record<string, unknown>) {
  // business logic
}

This setup is similar to other messaging brokers. And if it’s something custom, you can still use a DI container and create a custom event subsystem provider with Nest.js interfaces.

MQTT and NATS examples of consumers for Nest.js.

// MQTT
@MessagePattern('notifications')
getNotifications(@Payload() data: number[], @Ctx() context: MqttContext) {
  console.log(`Topic: ${context.getTopic()}`);
}

// NATS
@MessagePattern('notifications')
getNotifications(@Payload() data: number[], @Ctx() context: NatsContext) {
  console.log(`Subject: ${context.getSubject()}`);
}

RabbitMQ and Kafka examples of consumers for Nest.js.

// RabbitMQ
@MessagePattern('notifications')
getNotifications(@Payload() data: number[], @Ctx() context: RmqContext) {
  console.log(`Pattern: ${context.getPattern()}`);
}

// Kafka
@MessagePattern('hero.kill.dragon')
killDragon(@Payload() message: KillDragonMessage, @Ctx() context: KafkaContext) {
  console.log(`Topic: ${context.getTopic()}`);
}

This is how easy it is to integrate with most common messaging brokers using Nest.js abstractions.

Demo App and Tools

Available at the following link github.com/dkhorev/conf42-event-driven-nestjs-demo.

In this section, I will review a part of a real application (simplified, of course). You can get the source code at my GitHub page to follow along or try it out later. I will demonstrate how properly designed EDA can face challenges and how we can quickly resolve them with the framework's tools.

Demo app overview

Let’s first do a quick overview. Our expected workflow is like this:

We have an action that has happened in our API gateway, and it touches the trade service, which emits an event.

This event goes to the queue or event bus. And then, we have four other services listening to it and processing it.

To observe how this application performs, I use a side application which is my “channel monitor.” This is a powerful pattern to improve observability and can help automate scaling up and down based on channel metrics.

I’ll show you how it works in a bit.

Demo App in Action — Normal Conditions

I prepared a Makefile so you can follow along.

First, run a make start command that will start docker with all required services. Next, run a make monitor command to peek into application metrics.

The monitor shows me the queue name, the count of waiting jobs, the count of processed jobs, and the number of worker instances online.

As you can see, under normal conditions, the jobs_waiting count is zero, the event flow is slow, and we don’t have any jobs piling up.

This application works fine with a low event count. But what happens if traffic suddenly increases?

Demo App in Action — Traffic Spike

You can start this demo by running the make start-issue1 command and restarting the monitor with the make monitor command. Our event flow is increased by three times.

You will notice eventually in the monitor app that the jobs_waiting count will start to increase, and while we still are processing jobs with one worker, the queue has already slowed down compared to the increased traffic.

Now we can see that this throttles our mission-critical trade service confirmation.

The worker would process all events without priority, so each new trade confirmation must first wait for some over events to complete.

You can imagine this creating slower response times on our front-end client applications for trade processing.

Solutions?

Let’s explore the options we have to fix this:

• Scale the worker instance so it will process the queue faster
• Increase the worker instance count
• Application optimizations
• Separate the queues
• Prioritize events

The first and most obvious is to scale the worker instance so it will go faster. In the Node.js world, this is rarely a good solution unless you are processing high CPU-intense tasks such as video, audio, or cryptography.

The second is to increase the worker instance count. This is a valid option but sometimes not very cost-effective.

Next, we can think about application optimizations, including profiling, investigating database queries, and similar activities. This can be time-consuming and render no result or very limited improvements.

Our last two options are where Nest.js can help us with. It’s to separate the queues and prioritize some events.

Step 1 — Separate the Queues

I will start by applying a queue separation method.

The trade queue will only be responsible for processing trade confirmation events.

My code for this will look like this:

this.queue.add(JOB_ANALYTICS, { uuid });
this.queue.add(JOB_NOTIFICATION, { uuid });
this.queue.add(JOB_STORE, { uuid });
// this.queue.add(JOB_TRADE_CONFIRM, { uuid });
this.queueTrades.add(JOB_TRADE_CONFIRM, { uuid });

The first step is to ask our PRODUCER to emit a TRADE CONFIRM event to a new queue - TRADES.

On the consumer side, I extracted a new class called TradesService and assigned it as a listener to the TRADES queue.

@Processor(QUEUE_TRADES)
export class TradesService {
  protected readonly logger = new Logger(this.constructor.name);

  @Process({ name: '*' })
  async process(job: Job<TradeCreatedDto>) {
    // ...
  }
}

The QUEUE DEFAULT listener service stays the same. I don’t have to make any changes here.

@Processor(QUEUE_DEFAULT)
export class DefaultService {
  protected readonly logger = new Logger(this.constructor.name);

  @Process({ name: '*' })
  async process(job: Job<TradeCreatedDto>) {
    // ...
  }
}

Now, whatever happens, whatever spike we have — the trades will never stop processing (they’ll slow down but will not wait for unimportant events).

You can run this example with the start-step1 command and restart the monitor.

You will notice that the trades queue has a jobs_waiting count of zero, but the default queue is still experiencing problems.

And now, I will apply our second step for scaling based on the information I have, I increase the worker instance count to 3 for the DEFAULT QUEUE only.

Step 2 — Scale Workers

You can start this demo by running the start-step2 command and restarting the monitor. Over time, this application goes to zero jobs_waiting on both queues, so good job!

As you can understand, my example is a bit contrived and is mostly for demo purposes. You can easily see tho how we can leverage channel monitor patterns to programmatically react to our app performance changes by scaling up or down separate queue workers.

Solutions — Recap

Let’s recap. I applied the following solutions here from my list:

• Scale the worker instance so it will process the queue faster
• Increase the worker instance count
• Application optimizations
• Separate queues
• Prioritize events

Created a separate TRADES queue that also automatically prioritized those events over others.

Next, I increased the worker instance count for the DEFAULT QUEUE to 3.

All of this was majorly done for me by Docker and the Nest.js framework.

The next step you can implement by just using the framework's tools is prioritizing some other events over others. For example, anything related to logging or internal metrics can be delayed in favor of more mission-critical events like DB interactions, notifications, etc.

The repository with the test code is here: github.com/dkhorev/conf42-event-driven-nestjs-demo.

For containers and modular development, I use a Container Role Pattern described at this link.

I hope this was helpful. Good luck, and happy engineering!

More interesting Nest.js reads:

• Validating Complex Requests With Nest.js
• Improve Response Time by 10x by Introducing an Interceptor In Nest.js

Build Scalable Event-Driven Applications With Nest.js was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

A practical example

In this article, I want to make a deep dive and explore ways to perform complex validation for incoming requests with NestJS.

NestJS provides a great way to integrate request validation into your app with some good defaults. Its advice is to use a class-validator package that is powerful and has nice documentation and examples.

Why Is Request Validation Important?

Validation is an important step in online service security and data integrity.

It ensures you only receive data in a format that your service expects. Possibility to discard any additional data that you don’t expect.

It provides a layer of protection against malicious actors, remember you should not trust any user input, ever. Employ a zero-trust policy as much as possible.

Don’t store invalid data in the database, protect services down the pipeline from invalid data input.

What Is a “Class-Validator” Package?

GitHub - typestack/class-validator: Decorator-based property validation for classes.

It is a set of decorators that you can use with your JavaScript class properties to add validation. There are basic validation rules like @IsString() — validated field should be a string, and the ability to write fully custom validation classes and decorators.

Another good thing this package allows is the usage of the Dependency Injection container from the parent app. This is very useful for validating with external sources, for example, a User database. There’s one small trick to make it work, and save you some time googling. Check out this main.ts file:

The most important line here is:

useContainer(app.select(AppModule), { fallbackOnErrors: true });

This is not mentioned in the official NestJS documentation at the moment of writing this.

What Is a Complex Request?

I will define it as something that will have at least 1 array or 1 object, that will in turn include nested objects and/or arrays. Another common use case is checking validity against an external resource (DB, cache, S3, etc.).

For my example I will use an imaginary SaaS multi-tenant e-commerce API, that will allow me to:

• register a user globally
• place an order for a specific shop

Validating a User Create Request

To register the user, we’ll require the fields listed in the class below:

Our constraints are as follows:

• name — required, is a string, should be at least three characters long.
• email— required, should be a valid email string, should not be already registered in our database.
• password — required, is a string, should be at least 8 characters long.

This is what my UserCreateDto will look like after adding class-validator decorators.

Let’s first review standard validation rules from the class-validator package used here:

• @IsString() —value should be a string
• @MinLength(N) —value should have a min length of N
• @IsEmail() — value should be a valid email (syntax check only)

Now the interesting part is the @EmailNotRegistered() validation. This one I created to deny registering users if their email already exists in our app.

This is my custom validation decorator, the process of creating one is described in the docs. However most of this code is boilerplate, let’s check the most interesting lines.

Line 11 — injects a custom provider private readonly userRepository: UserRepository.

Lines 14–15 — provide a validation function by searching the email in the UserRepository.

My UserRepository is just an in-memory store, that emulates some form of async network I/O. This is to replicate the real DB request/response lifecycle.

The user register API endpoint looks like this:

This is all you have to do to make NestJS validate incoming requests:

• type-hint a DTO class in your route’s signature
• add validation decorators to your DTO class
• turn on validation usage within main.ts (example shown above)

Nicely done. Let’s move on to the order request and validation!

Validating a Create Order Request

Okay, we’ve started with something rather simple, now let’s try to validate an order request.

Our requirements for the OrderCreateDto are:

• should have common order properties, like a shop ID (we’re SaaS multi-tenant app), and the date when created.
• should have customer information (customer email).
• should have an order products list (an array), with a common structure — product ID, and quantity.
• should have an order shipment description, which is a variable object: either Delivery or Pickup type, with various required fields.
• finally, it should have a contact person list, with some details for each contact person.

The first, non-validated DTO that meets such requirements may look like this:

Let’s go over each block of this request, describe it, and add validations.

OrderCreateDto

Here are the constraints:

• shop_id — should be in UUID format and exist in ShopRepository.
• created_at — should be a date object or date castable.

Solution

@IsUUID() — is a decorator for checking a string to be a valid UUID.

@Validate(ShopIdExistsRule) — validates the field with a custom rule (similar to writing your decorators, but a bit simpler).

@Type(() => Date) & @IsDate() — will try and cast provided input to Date and validate it’s a Date object.

OrderCustomerDto

Here are the constraints:

• email — should exist in the user repository, and should be a valid email string.
• validate a nested object of OrderCustomerDto inside parent OrderCreateDto.

Solution

New things here:

@CustomerExists() — this is the opposite of the @EmailNotRegistered() rule I have used before. Logic is similar and we take advance of injected UserRepository.

@Type(() => OrderCustomerDto) — this is a utility line, that transforms the nested object into a class, so it can be validated by following @ValidateNested(). If you don’t transform — validation will not run.

If you get an error when starting NestJS:

ReferenceError: Cannot access ‘OrderCustomerDto’ before initialization

You need to move the OrderCustomerDto declaration before OrderCreateDto, as shown in my code example above.

OrderProductDto

Here are the constraints:

• products — should be an array, should not be empty.
• id — should exist in the ProductRepository, and should be an integer value.
• quantity — should be enough of this product available and should be an integer.

Solution

Here's some new things:

@IsInt() — check the value to be an integer, 100.5 will fail validation.

@ArrayNotEmpty() — validates that the products array is not empty.

@ValidateNested({ each: true }) — triggers an array nested validation, so we can effectively validate from 1 to N products.

ProductIdExists and ProductIsAvailable — are custom rules that check if the product exists and if there’s enough quantity to place an order.

OrderShipmentDto

Here are the constraints:

• type — should be a part of the enum (Delivery | Pickup), should be defined.
• if the Delivery type is selected — city and address fields are required strings, not empty.
• if the Pickup type is selected — the point_id field is required, should be an integer, not empty.

Solution

Here’s some new things:

@Equals(DeliveryTypes.DELIVERY) and @Equals(DeliveryTypes.PICKUP) — will do a strict (===) check of provided value.

Then, based on the delivery type we validate the nested object. For that, we need a bit more advanced @Type() use case.

Since the shipment object is of variable type, we include variable type cast for validation and shipment now looks as this: shipment: DeliveryShipmentDto | PickupShipmentDto;

This allows our validation system to drop fields that are not required by specific delivery objects, i.e., you request Pickup shipment and provide city — this will now be dropped by the class-transformer package.

OrderContactDto

Here are the constraints:

• name — should be a string, should be defined.
• phone — should be a valid mobile number.
• email — optional, if defined should be a valid email syntax.

New validations are here:

@IsMobilePhone(‘en-US’) — will check the phone string to have valid syntax, amount of numbers, etc.

@IsOptional() — will only validate the email if it was provided.

Final Solution

OK, it’s been a long path. Now, let’s see a full request object with all the validation decorators:

Bonus: More Common Use Cases for Validation

It’s hard to come up with an example that covers all features of request validation. So, here I will list some interesting use cases from my practice:

Payment confirmation

Use case: webhook call from a third-party card processor (PayPal, Stripe).

You usually have some form of secret signing key stored in the config and need to validate the request’s signature.

Here’s an example of a validator that uses injected NestJS config service.

Request

We will combine order id + amount + secret and compare it with the received signature.

Conditional property validation

Use case: only validate property if another property is set to a specific value.

Task: only validate the email if subscribe is true.

Duplicate constraint validation without Database query

Use case: you have a DB constraint UNIQUE(field1 + field2), but you want to validate this before reaching DB level (and getting the store exception). Your request accepts multiple entities to store at once and it can contain duplicates.

Here’s an example DTO:

And with validation:

Date range constraints relative to the request

Use case: a filter with start and end dates. You expect the end date to be later than the start date.

With validation constraints:

Conclusion

NestJS and class-validator together play well for request validation. It can cover everything from the simplest to complex validation scenarios.

Another good point is that you get a standard error response structure in case of failed validation that you don’t have to code yourself — all handled by NestJS.

The repository with the test code is here: https://github.com/dkhorev/validating-complex-requests-with-nestjs

I hope this was helpful. Good luck, and happy engineering!

Validating Complex Requests With Nest.js was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.