DEV Community: Alexandra

What do you build when you can build anything?

Alexandra — Wed, 02 Sep 2026 16:38:09 +0000

My hot take is: Telling people that they have to build endlessly is very, very, very bad advice. If you have been remotely on LinkedIn over the last six months, you will have seen two different camps. The AI haters, the ones who don’t want to lay their eyes on your AI-generated code, article or post, and the AI defenders, the ones who say all day long that if we dont build with AI we will be left behind. But which camp is right? Both and neither, all together.

The Cost of Building Everything

I said building everything is a waste. A waste of resources (...poor water), a waste of money, a waste of time and a waste of bytes in a data centre, all for a dead product that maybe only one person will ever discover. The best skill we probably need to develop nowdays is knowing what not to build. In a world of endless possibilities, how do you choose what is a good idea? It is almost an impossible task.

It all started with a random idea I had for an app. I like photography, and i often go for photo walks in my cities. My idea involved creating an app that helps you create/attend/do a photo walk. Sometimes I am already out with my camera and want to find the next place to take photos, but I don't know exactly where to go. Or maybe I want to find a well-known photospot and try to recreate a particular photo. What sounds like a simple feature quickly becomes a set of different user needs. I started sketching the idea, using AI to explore the flows and turn the word vomit in my head into something tangible. But I had to stop and ask myself: is this actually worth building? When I go for my little photowalks, I actually like to getting lost, and find unexpected things. Is this even a good idea?

One would argue "why not" or even not think to question the idea at all. I could open my IDE, ask an agent to build the first version and have something running in a few hours. I could spend a weekend on it. I could launch it. I could even convince myself that I am doing something productive. But none of that answers the question. It only answers whether I can build it.

Welcome to Agency Hell

Engineers love to create their own personal versions of hell. First we had the tutorial hell, then we upgraded to the side-hustle culture hell. And now, apparently, we are in the 7th ring of founder and agency hell.

For a long time, there was a constraint between having an idea and building it. You needed to know how to code, find a designer, learn a new framework, figure out deployment, pay for infrastructure, convince someone to use it and somehow find the time to do all of that while having a job. So, most ideas died somewhere along the way, and that was probably a good thing.

AI removed a lot of those problems. You can have an idea in the morning and have a prototype by the evening. You can generate an app, the accompanying landing page, write the backend, create the db schema, produce the copy (with the compalsory em dashes) and deploy the thing without needing much more than some free time and a few API tokens (it could many $$, but that's an other discussion).

To some people that sounds like a freedom. But freedom without direction can become its own kind of trap.

When everything is possible, every idea starts to feel like an obligation. You see someone building an AI wrapper, so you build one. Someone launches a micro-SaaS, so you launch one. Someone makes €10,000 from a weekend project, so you start wondering why you haven’t done the same. This is what I mean by agency hell. Not the inability to build, but the constant feeling that you should be building.

What Do You Actually Care About?

When you can build anything, what do you build, though? That question is very personal for each of us. We can rephrase it: what do you care about? That is a much more difficult question to answer. But (in my humble opinion) that will break or make your relationship with AI.

I don't know anyone that grew up with aspirations on making the best accounting software, these kind of software comes from a need of understanding a complex domain. AI can help you build this kind of software, but it cannot give you a reason to care about the problem.

Most people care about their families, their hobbies, their friends and the things that make their lives meaningful. Those are the places where interesting problems hide. You might build something because your mother struggles with a particular task, because your dance studio has an annoying process, because your photographer friend struggles with their workflow, or because something in your own life keeps bothering you.

Not every hobby needs an app. Quite the opposite. The point is that caring about something gives you a reason to notice problems that other people don't see.

Possibility Isn’t Purpose

In a world of possibilities, we probably have to become more selective about what we build. AI has changed the economics of software creation, yes, but there are still only so many hours in a day, only so many people who will use your product and only so many problems worth solving.

Most people think AI unlocks some secret chest of money. The truth is that it doesn’t. It makes execution cheaper. It makes experimentation faster. It gives more people the ability to turn an idea into something real.

But it cannot tell you which idea deserves your time.

Because if you don't care about what you are building, congratulations, you just unlocked a whole new world of endless misery.

I would really love to hear about your thoughts about this topic. Yesterday I saw at least 2 posts of identical ideas being implemented by different people. Do we squeeze ideas to fit in the market in non-existing problems (create our own new kind of hell), or we solve problems people (or ourselves) have? I know that not all software are build for usefulness, sometimes being fun is enough, but i seem to struggle to recognize if my ideas are actually good and worthy to bring into life. So what is your take?

This post was written by human (me!) and passed through an AI grammar revision.

From Figma to the browser: building a shared mental model

Alexandra — Sun, 30 Aug 2026 10:58:03 +0000

Throughout my career as an engineer, I have been given a countless amount of specs, design documents and Figma files to bring ideas to life. I have attended handoffs, kickoffs, design critiques, you name it. Something I noticed out through the years is more often than not, it feels like designers and developers are talking about the same thing while actually having fundamentally different mental models. And here is where the friction between these two disciplines comes into play.

The canvas vs. the browser

A designer has a canvas, and moves around stuff in this space. They can put an element wherever they want, move it around, resize it. This is quick, easy, fun and provides them with the creativity that a designer needs.

But, the browser doesn’t work like that. A browser organizes the elements in stacks. These elements have relationships, they take up space, and their position can change depending on the items around them.

A design to an engineer is a snapshot in a particular size screen, and our job usually is to find the correct rules that produce this result and interpolate this to different sizes.

The interesting part is that the gap between these two mental models isn't actually as big as it might seem. Design tools have started to give designers many of the same or similar concepts that developers use to build layouts. Figma has an "Auto Layout" option, for example, which is very close to the way we think about CSS Flexbox. This helps the designers and developers to find a common vocabulary and collaborate more.

Auto Layout → Flexbox

If you have worked with CSS for a while, you probably know about Flexbox. It has already been available to developers for the last decade.

The basic idea is simple: you have a container with a number of children, and you want to describe how those children should be laid out and how they should use their available space. Instead of telling the browser where each element should go, you describe the relationship between them.

Imagine having multiple buttons inside a container. The moment you instruct that this container is a flex container, I can say that these buttons should sit next to each other, have a gap between them and be aligned to the center. If the container gets wider, the layout can adapt. If one button becomes larger because its label changes, the others can respond accordingly.

Figma has something very similar: Auto Layout! If you have used Auto Layout in the past, you already understand many of the concepts behind Flexbox. You have a container and you decide whether its children are arranged horizontally or vertically. You define spacing and alignment. You decide how the container should behave when its contents change, and how the children should use the available space.

And just like Figma allows you to nest Auto Layout frames, CSS allows you to nest flex containers.

Each of those containers can have its own layout rules. One can arrange its children vertically, another horizontally, and another might allow one child to take up all the remaining space.

The closer the mental model in Figma is to the mental model in the browser, the less translation is required between the two.

When one dimension isn't enough → CSS Grid

CSS Flexbox solves many problems for frontend development, but it still is 1-dimensional layout. What that means is that it handles the items in a single main axis (something like a single row or column).

In many problems we solve one dimension is not enough. So we have a CSS Grid, which is a container in 2 dimensions. Think about a dashboard, a photo gallery, or a page with multiple sections that need to line up across both rows and columns. Now we're not only just asking “how should these things sit next to each other?”, but also “how should these things relate to the structure of the entire layout?”

The easiest way to picture this, it is a grid of cells, something like a table, but unlike a table, these cells aren't tied to the content in a particular row or column. We can define the structure of the layout and decide how elements should span across it.

A designer might look at a Figma canvas and see a beautiful asymmetric layout: one large image spanning two columns, a group of cards underneath, and a section that stretches across the entire page. A developer doesn't need to reproduce that with a collection of arbitrary pixel positions, but they can describe the underlying structure.

This gives designers something useful to think about when creating layouts. That doesn’t mean that grid is the answer to all the problems, we can mix and match those tools to achieve the result.

The important thing is for the designer and developer to work closely with each other. One can help each other, by strong communication and understanding of each others language. It’s not about just handing off designs anymore, but more about thinking these systems and the interaction needed to achieve useful results.

Designing for change → responsive layouts

A design might look as a static snapshot to a developer. It works in a very defined size. A Figma file might give us a desktop design and a mobile design, but the browser has to deal with everything in between.

A breakpoint is essentially the point where the current layout stops making sense. In CSS we use media or container queries that help us to determine the perfect layout for each screen size and all the steps in between.

Flexbox and Grid already give us layouts that can respond to changes in available space. A container can grow and shrink, items can wrap, and columns can adapt without us defining what should happen at every screen width.

Instead of designing only “desktop” and “mobile”, think about the hierarchy of the interface and how that hierarchy should respond when space becomes constrained. Typography is a good example. A heading doesn't necessarily need one font size on desktop and another completely different font size on mobile. CSS gives us tools like clamp() that allow a value to scale within a defined range.

The goal isn't to create a collection of screenshots that the developer has to somehow connect together. It's to define enough rules and constraints that the interface can behave sensibly in the space between those screenshots.

The container matters → container queries

The responsive design can be elevated even more with container queries.

We're probably more familiar with media queries in development, we use it for ages to create responsive designs. A media query looks at the viewport and asks how much space does the browser window have? Based on that, we can change the layout.

But CSS gives us cool tools these days, and we can be more explicit on our responsive designs. Container queries ask a different question: How much space does this component actually have?

Imagine we have a card component. On a large screen, the card might have enough space to show an image next to its content. But the same card could be placed inside a narrow sidebar, where that layout no longer makes sense.

With a media query, the component would respond to the size of the screen. With a container query, it can respond to the space that is available to the component itself.

Beyond the handoff

The goal isn't for the designers to become developers, or vice versa. A designer doesn't need to know how to write grid-template-columns, and a developer doesn't need to know how to create a perfect Figma component.

The goal is to understand enough of each other's world to share a mental model of what's being built. A good handoff isn't just a Figma link with a list of measurements, colors, and font sizes. Yes, all of these are useful, but they merely describe the result.

What matters more is understanding the intention behind the design. The bridge between design and development isn't the handoff, but a shared mental model.

What two months of interviewing taught me about the 2026 tech job market

Alexandra — Fri, 28 Aug 2026 11:40:20 +0000

July wasn’t a particularly pleasant month for me.
I was affected by the restructuring of the company I was working for, which meant going back into a job market I would politely describe as insane.

Over the past two months, I’ve interviewed mostly for frontend, SWE and full-stack engineering roles, and I’ve noticed quite a few things that feel very different from the last time I was interviewing, around two years ago.

I should preface this by saying that I’m not the best interviewee. My job is to be an engineer, not a professional interviewee or leetcode solver. I’m an introvert, and the job market increasingly requires a lot of soft skills: having a "brand", marketing yourself, selling your experience, being charismatic, thinking on-the-fly ideas and presenting yourself as the perfect candidate.

None of that necessarily reflects how good you are at your actual job, and when the interview itself is stressful, that gap becomes even bigger.

1. The expectation is to be the perfect fit

In older interviews I had, there seemed to be more room for learning or better said "potential". You didn’t have to possess all the skills but to be eager to learn. Now, I’m seeing much more of: “You don't have exactly the experience we're looking for? Rejected.”

If you don't match a large part of the job description already, there doesn't seem to be much appetite to invest in someone who could grow into the role.

Maybe this is simply the market correcting itself after years of aggressive hiring, but I do wonder whether we’re losing some of the willingness to hire for potential.

2. Interviewing well seems to matter more than engineering well

To me this is one of the biggest frustrations on the job market right now. Interviews are artificial environments. You are asked to produce your best answer, code, idea, product, under pressure, with very little time to think.

And yet we seem comfortable treating performance in that environment as a proxy for engineering ability.

In one interview, I received feedback that I had frozen because interviewing is stressful for me, and that saying “I don't know” when nothing immediately came to mind wasn't a good signal.

But isn't being able to say “I don't know” actually an important engineering skill?

I would much rather work with someone who says:
“I don't know yet. Let me investigate.”
than someone who confidently makes something up because they think that's what the interview expects.

3. Companies want you to be everything and salaries don't necessarily reflect it

The scope of some of the roles I've seen has become… ambitious. Frontend. Backend. Product. Design. Talking to customers. Making technical decisions. Owning the roadmap. Using AI. Moving independently.

Basically: be the engineer, product manager, designer and mini-CEO of your area. Don't get me wrong that's not necessarily a bad thing, I actually like having ownership.B

ut when a company expects one person to cover what used to be several different roles, I think it's fair to ask whether compensation and expectations have kept up with that change. Instead i see the salaries and budgets have..decreased?

Especially in expensive cities like Amsterdam.
You can live somewhere cheaper, that's true, but then you often trade money for commuting time, which is another cost.

4. Some job advertisements don't feel real

Many of the job descriptions are not real (or better said don’t feel real). Or if they are real, I’ve seen them sitting open for months.

I've seen job descriptions asking for extremely specific combinations of experience. And I've seen companies seemingly looking for a unicorn while complaining that they can't find people.

Maybe they really can’t find talent? Or there is so much talent in the market that they don’t know what to do? Or do they ask for the impossible? Or are some of these roles not really intended to be filled in the first place?

Because right now, we somehow have a situation where companies say they can't hire, while qualified people say they can't get hired.

5. Job applications have become unnecessarily enormous

We've all joked about uploading your CV and then being asked to manually enter every single thing that's already in your CV. Tbh, that's not even a big problem anymore.

Most roles have open-ended questions. With the dreaded “What excites you about this role?” being on the top of the list, which "paying my rent and bills" is not necessirily an answer to.

And then, my personal favourite (approaching the word pet-peeve):
Record a 2-4 minute video answering X question.

Have you ever spoken to an engineer before? Some of us are already fighting for our lives in a live coding interview. Now you want a casting audition too? I didn’t know i was getting hired to be an actor.

6. Job descriptions are generally bad

An other trend i see is an abundance of startups got their first founding engineers, followed by job descriptions that are obviously AI-generated. Five paragraphs of corporate language that nobody understands following 37 technologies in must-haves. You should of course move fast, own end-to-end, thrive in ambiguity, be 20x engineer and 45x productive.

My brain has already left the building.

And then companies complain about receiving hundreds of generic, AI-generated applications. But if you put little thought into the job description, why should candidates put significantly more thought into their application?

You get as much effort as you put into it.

These are simply observations from my own experience over the last two months, and I'm genuinely curious whether other engineers are seeing the same thing.

Maybe it's the AI transition/psychosis. Maybe it's a correction after the hiring frenzy of the 2020 mass hiring. Or maybe I'm just particularly unlucky with interviews. 😅

What have you noticed in the 2026 tech job market that feels different from a few years ago?

HTML is getting cool again: Meet the Invoker Commands API

Alexandra — Sat, 22 Aug 2026 10:55:26 +0000

For years, frontend development has had a slightly embarrassing relationship with HTML. We all read about semantic HTML, we talk about using the right landmarks, the right attributes, accessible forms, and meaningful elements. And then we go back to writing React.

While the whole industry is obsessed with AI, browsers are shipping features that make the platform even more capable. Features that let us remove JS, reduce state, and express UI behaviour in HTML. But since AI is trained in the past, these are ignored or not recommended enough through old patterns.

State boilerplate to open a dialog

Historically, in order to open a dialog or a popover, we need a chunk of custom boilerplate code.

<button id="open-dialog">Open dialog</button>
<dialog id="my-dialog">
  <p>Dialog content</p>
  <button id="close-dialog">Close</button>
</dialog>

<script>
  const dialog = document.getElementById("my-dialog");
  document.getElementById("open-dialog").addEventListener("click", () => {
    dialog.showModal();
  });
  document.getElementById("close-dialog").addEventListener("click", () => {
    dialog.close();
  });
</script>

We need a button to open our dialog, the dialog itself, and then we write JS to explain the interaction to the browser: "When the user clicks the button, open the dialog".

If you're using React or Vue, this can get even more elaborate: You need some custom state, potentially pass it to your component, wire up an event handler, and then make sure everything stays in sync.

Whether vanilla or framework, the code above is completely reasonable on its own, every frontend developer has written something similar a hundred times. But after writing it for the thousandth time, it made me wonder: do we really need application state to represent that a dialog is open? The answer is: it depends. Sometimes state is needed. But sometimes we're just rebuilding behaviour that HTML and the browser can already provide for us out of the box in 2026.

Enters the chat: the Invoker Commands API

The Invoker Commands API provides us a way to declaratively assign behaviours to buttons, which then allows us to control these interactive elements. Instead of adding an event listener we can describe the relationship directly in HTML.

The attributes that help us are commandFor and command:

commandFor: turns our button into a "command invoker". It takes the ID of the element to control as its value.
command: Specifies the action to be performed on that element.

<button commandfor="mycoolpopover" command="toggle-popover">
  Toggle the popover
</button>
<section id="mycoolpopover" popover>
  <button commandfor="mycoolpopover" command="hide-popover">Close</button>
  Awesome Popover content
</section>

How to do it in React?

All of these are transferable to your framework of choice:

export function DeleteButton() {
  return (
    <>
      <button command="show-modal" commandFor="delete-dialog">
        Delete account
      </button>
      <dialog id="delete-dialog">
        <h2>Delete account?</h2>
        <p>This cannot be undone.</p>
        <button command="close" commandFor="delete-dialog">
          Cancel
        </button>
      </dialog>
    </>
  );
}

The important detail here is that React's JSX property is commandFor, while the resulting HTML attribute is commandfor

Is that a really big deal?

At a first glance this looks like saving, maybe 10 lines of code. That's nice. But the most interesting is the shift of the responsibilities from us, back to the browsers.

The browser isn't becoming less capable because we're writing less JavaScript, but rather the opposite. We finally need less JS.

Browser support

Now, before everyone starts deleting their dialogs, there is a small catch: The Invoker Commands API is new. MDN currently lists it as Baseline 2025, with cross-browser availability in the latest browser versions since December 2025. Older browsers may not support it.

References

How Many Introductions Away Are You From Pedro Pascal? A Practical Introduction to Graph Search

Alexandra — Tue, 11 Aug 2026 14:05:24 +0000

I was watching The Mandalorian the other day when it struck me that I don't know Pedro Pascal, which is, by itself, very tragic.

But maybe I know someone, who knows someone, who knows someone, ..., who knows Pedro Pascal. Somewhere out there, there is a finite chain of introductions that connects me to him. So the important computer science question we try to solve today is: How many introductions would it take to reach him?

We accidentally have invented a graph problem!

Turn your social life into a graph

Imagine that each person on this earth is a node and any relationship or acquaintance between two people is an edge:

Alexandra ── Maria ── Sofia ── Pedro
    │
    └── John ── Elena ── Carlos

This is an unweighted and undirected graph.

Unweighted means that every connection counts the same. We don't care whether Maria is Sofia's best friend or someone she met once at a cafe.
Undirected means the relationship is both ways: if Alexandra knows Maria, Maria knows Alexandra.

If we strip the fluff of the original question, it kinda changes from "How do I meet Pedro Pascal?" to "Given an unweighted graph, what is the shortest path between node A and node B?", which if you are familiar with trees or graphs it sounds like a BFS (Breadth-First Search).

In code, the simplest way to represent this kind of data is an adjacency list

const graph = {
  Alexandra: ["Maria", "John"],
  Maria: ["Alexandra", "Sofia"],
  Sofia: ["Maria", "Pedro"],
  Pedro: ["Sofia"],
  John: ["Alexandra", "Elena"],
  Elena: ["John", "Carlos"],
  Carlos: ["Elena"],
};

Make our delusions an algorithm

Unfortunately, screaming “DOES ANYONE KNOW PEDRO PASCAL?” into the void isn't an algorithm. It has no order, no memory, and no stopping condition. If you just wander from person to person picking whoever seems interesting, you can easily do this:

Alexandra → Maria → Sofia → Maria → Sofia → Maria → ...

Because the graph is undirected, Maria connects back to Sofia and Sofia connects back to Maria. Without remembering who we met already, nothing stops us from revisiting the same people forever.

So we basically need two things:

A rule for what order to explore people in.
A way to remember who we already visited.

That's where a queue and a visited set come in.

Breadth-first search explained

The key observation for finding the shortest path is this: check everyone one connection away before checking anyone two connections away. This is breadth-first search, and it organizes the graph into levels:

Level 0        Alexandra
                  │
           ┌──────┴──────┐
Level 1   Maria          John
            │              │
Level 2   Sofia          Elena
            │
Level 3   PEDRO 🎉

BFS will check all my direct friends (level 1), if Pedro isn't there (🥲) will check the direct friends of my direct friends (level 2) and so on. The moment Pedro is found, you know that this is the shortest possible path, because every shorter one has already been checked.

Put everything together


function introductionsAway(graph, start, target) {
  if (start === target) return { degrees: 0, path: [start] };

  const visited = new Set([start]);
  const queue = [[start, [start]]]; 

  while (queue.length > 0) {
    const [person, path] = queue.shift();

    for (const friend of graph[person] || []) {
      if (visited.has(friend)) continue;
      if (friend === target) {
        return { degrees: path.length, path: [...path, friend] };
      }

      visited.add(friend);
      queue.push([friend, [...path, friend]]);
    }
  }

  return { degrees: -1, path: [] };
}

The twist: real relationships aren't equal

So far in our problem knowing someone is binary. But you and I both know that's a lie. There's a biiiig difference between:

Maria once stood next to Pedro at an event, and
Pedro? Yeah, we're having dinner every Thursday.

Technically, both are relationships but practically, one of them is significantly more useful to my mission.

Alexandra --2-- Maria --5-- Sofia --4-- Tessa --1-- Pedro

So let's assign every relationship an introduction cost. A close relationship has a low cost because asking for an introduction is easy. A weak acquaintance has a high cost because... well, good luck with that.

The BFS algorithm doesn't know how to handle weights. For weighted graphs, we need to move our attention to Dijkstra's algorithm.

Dijkstra's algorithm, briefly

Dijkstra's algorithm asks a slightly different question:

"What is the cheapest path from A to B?"

Instead of exploring nodes in the order we discover them, we prioritize the node who currently has the lowest accumulated cost from our starting point.

That usually means replacing BFS's regular queue with a priority queue.

Same graph, different nouns

The Pedro Pascal situation is ridiculous, i know, but the underlying problem isn't. Change what the nodes and edges represent, and suddenly the same ideas appear everywhere.

Domain	Nodes	Edges	What "shortest path" answers
Social graph	People	Relationships	"How many introductions to Pedro Pascal?"
Maps / GPS	Intersections	Roads (weighted by time/distance)	"Fastest route from A to B"
Web crawling	Web pages	Hyperlinks	"How many clicks from this page to that one?"
Codebases	Modules/files	Imports/dependencies	"What breaks if I change this file?"
Recommendations	Users or items	Similarity/interaction strength	"What's most relevant to this user?"

Graphs are one of those computer science concepts that you initially hate and mostly dont understand. Nodes. Edges. Traversals. Queues. But they are everywhere.. The internet itself is basically one very big graph.

And if by any chance anyone knows someone who knows someone... You know where to find me.

Frontend system design interviews are weird. Here’s how I now approach functional requirements.

Alexandra — Sat, 08 Aug 2026 16:40:25 +0000

One of the worst types of interviews for me is the system design. It feels overwhelming, even though i studied computer science, i took all the network and operating systems and DBMS courses. I have an idea on how to explain what a distributed system is. Put me in an interview, though, and sometimes my brain just goes blank.

So usually in these interviews you either get a screenshot or you're given a broad prompt like:

Design a notification system.
Design a URL shortener
Design netflix

On one hand, you're thinking that these systems took entire teams years to design. On the other, your brain is already jumping to WebSockets, caching, React state, API endpoints, databases, pagination, and whether you're somehow expected to know how many servers Instagram has.

Let's take a step back. Before deciding how we are going to build something, we need to know what we are building. So let me introduce you to.. functional requirements.

What are functional requirements?

Functional requirements describe what a system should allow its users to do. You have to clarify what the capabilities of the product is and how it should behave without knowing or specifying how these will be implemented.

Design a notification system for a web application

This is very broad, and give this prompt to 10 people and you'll get 10 different sets of requirements. So what a 'notification system' means? Are these notification real-time? Can users interact with them? Do we need to keep a history? Can users mark them as read? Do they disappear?

Before drawing a single architecture box, we need to establish the scope of the problem we are talking about.

A first set of functional requirements could be:

Users can receive notifications.
Users can view their notifications.
Users can mark a notification as read.
Users can mark all notifications as read.
Users can navigate from a notification to a details page.
Users can see how many unread notifications they have.
Users can receive new notifications without manually refreshing the page.

Functional vs non-functional requirements

This distinction becomes particularly important in system design interviews.

Functional requirements describe what the system does.
Non-functional requirements describe how well the system needs to do it or the constraints under which it operates.

For our notification system, these could include:

Functional requirement	Related non-functional concern
Receive new notifications	Updates should appear with low latency
View notification history	Large histories should load efficiently
Mark notifications as read	UI updates should feel immediate
See unread count	Count should remain consistent across the application
Open related content	Navigation should be reliable and accessible

Accessibility, performance, reliability, scalability, browser support, and latency are usually concerns that influence our architecture without defining the product feature itself. Usually all of these are non-functional requirements.

Don't accept the prompt as the specification

One of the most important things to remember in a system design interview is that the interview prompt is usually intentionally incomplete. You don't get a specification, you have to deduct it with your interviewer. The most important thing in these type of interviews is to ask questions.

For example good questions in our example could be:

What kinds of notifications are we supporting?
Do notifications need to arrive in real time?
Do users need access to their notification history?
Can notifications be deleted?
Do we need read/unread state?
Should notifications synchronize across multiple tabs or devices?
How many notifications might a user receive?
Are we designing only the web experience, or mobile too?

If the interviewer tells you that notifications only need to update when the page reloads, your architecture will look very different from a system expected to deliver millions of real-time updates.

Make assumptions explicit

Sometimes the interviewer won't give you every answer, and leave it up to you. So at this point inevitable you will make an assumption. Make an assumption and say it out loud.

For example:

I'll assume we're designing the web notification center, notifications should arrive while the application is open, users can mark them as read, and we're not covering email or push notifications.

That single sentence dramatically reduces the problem scope.

Now instead of designing Every Notification System Known to Humanity, we're designing something concrete. This is one of the reasons functional requirements are so useful: they establish the boundaries of the system.

Requirements drive architecture

Once we understand the requirements, technical decisions start having a reason to exist.

Suppose one requirement says:

Users should receive new notifications while using the application without refreshing the page.

Now we have a technical problem to solve.

How our system can solve this concrete problem? We could consider:

polling
Server-Sent Events
WebSockets

So, we didn't jump immediately to a conclusion to use Websockets? We derived it from a user requirement and the architecture followed.

Users can view older notifications.

Now we need to think about pagination and data fetching.

Users can mark notifications as read.

Now we need to think about mutations, optimistic updates, error handling, and synchronization.

Users can see their unread count throughout the application.

Now we need to think about where that state lives and how different parts of the UI stay consistent.

From requirements to frontend architecture

A useful way to think about the process is:

Functional requirements
        ↓
User flows
        ↓
Data model
        ↓
API contracts
        ↓
Client architecture
        ↓
State management
        ↓
Rendering & performance
        ↓
Accessibility

These aren't perfectly isolated steps. Real systems are messy, requirements change, and decisions influence each other. But we move from a non defined problem to an architectural decision.

Going back to our notification example: the user flow "click the bell, see 5 unread, mark one, count drops to 4" already forces a data model decision about where read/unread state lives, which in turn shapes the API contract and how the client keeps that count in sync. Each arrow in the pipeline above is really a question you're answering, not just a step you're passing through.

Functional requirements also protect your scope

System design prompts can become enormous very quickly.

For example:

Design Instagram.

What does that even mean? The feed? Posting photos? Stories? Profiles?

It's impossible trying to design all of Instagram in a 45-minute interview, despite what all the vibe coders tell you.

Perhaps we can agree with the interviewer that we are designing the home feed and narrow down the problem to:

Users can view posts from accounts they follow.
Users can continuously load older posts.
Users can like a post.
Users can open a post.
Users can see new content when it becomes available.

And booom...now we have something we can actually design.

Start with "what", then design "how"

System design interviews aren't a competition to mention the largest number of technologies before the clock runs out. They're about making engineering decisions under incomplete information.

Functional requirements give those decisions context.

Suddenly, you're not designing Netflix anymore but a specific set of behaviours with specific problems to solve.

And once you know what you're building, reasoning about how to build it becomes a lot less scary.

At least that's what I'm trying to teach my brain before my next system design interview. 😅

The 10 JS Topics Every Frontend Engineer Should Know

Alexandra — Wed, 05 Aug 2026 08:20:52 +0000

Maybe AI is THE "hot" topic, but interviews are as old as ever. As i am studying for that said interviews, I compiled a list of 10 JS topics I think that are very crucial to prove the understanding of. These are topics I have been asked or ask during my 10 years in tech🤗.

1. Execution Context & Hoisting

Level: Very common. I have been asked about hoisting so much during all my years of experience.

Before JS runs your code, it creates an execution context. A new context is created when a program starts or when a new function is executed. During this phase it allocates memory for variables and functions. var variables are hoisted and initialised as undefined, while let and const are hoisted but remain in the Temporal Dead Zone until their declaration.

Example

console.log(a); // undefined
var a = 5;

Resources

2. Closures

Level: Common. Mostly asked to mid FE.

A closure happens when a function remembers variables from the scope where it was created, even after that outer function has finished executing.

Example

function counter() {
  let count = 0;

  return function () {
    count++;
    return count;
  };
}

const increment = counter();

increment(); // 1
increment(); // 2

Classic interview example :

let result = [];
for (var i=0; i<10; i++) {
    result[i] = function() {
      console.log(i,);
    }
}
result[0](); // 10
result[1](); // 10

let result = [];
for (let i=0; i<10; i++) {
    result[i] = function() {
      console.log(i,);
    }
}
result[0](); // 0
result[1](); // 1

Resources

3. The Event Loop

Level: Very common. Asked at every level. Usually as questions "predict the output" like the one below.

JS is single threaded, meaning it runs one line of code at a time. The Event Loop decides when callbacks (macrotasks, think timers) or promises (microtasks) are allowed to run after the current code (executed in the call stack) has finished.

Example

console.log(1);
setTimeout(() => console.log(2), 0);
Promise.resolve().then(() => console.log(3));
console.log(4);

// Output:
// 1
// 4
// 3
// 2

Resources

4. Promises & Async/Await

Level: Very common. Understandably, there is no way to not have async behaviour in an app in 2026.

Promises represent work that will finish later. async and await is syntactic sugar for promises that let you write asynchronous code that looks like synchronous code.

Example

async function getUser() {
  const response = await fetch("/api/user");
  return response.json();
}

Resources

5. `this` Keyword

Level: Common. Mostly junior to mid FE.

this refers to the object that is calling the function. Its value
depends on how the function is invoked.

Example

const user = {
  name: "Alex",
  greet() {
    console.log(this.name);
  }
};

user.greet(); // Alex

Resources

6. Objects & Recursion

Level: Less common as trivia, but shows up in live coding (deep clone, tree traversal, flattening nested objects).

Recursion is when a function calls itself. It's useful for traversing
nested objects or tree-like structures.

Example

function countDown(n) {
  if (n === 0) return;
  console.log(n);
  countDown(n - 1);
}

Resources

7. Arrays & Data Manipulation

Level: Very common. You need to know how to manipulate data.

Frontend applications constantly read and manipulate API data. Methods like map, filter, and reduce make this easier.

Example

const users = [
  { name: "Alice", active: true },
  { name: "Bob", active: false }
];

const activeUsers = users.filter(user => user.active);

Resources

8. Browser Rendering & Performance

Level: Less common. Mostly senior or performance-focused roles.

The browser converts HTML, CSS, and JavaScript into pixels on the
screen. Efficient updates reduce unnecessary layout and painting work.

Example

requestAnimationFrame(() => {
  element.style.transform = "translateX(100px)";
});

Resources

9. Event Propagation

Level: Common. Mid FE and up.

Events travel through the DOM. They first capture down the tree, then
bubble back up. Event delegation uses bubbling to handle many events with one listener.

Example

document.body.addEventListener("click", (event) => {
  console.log(event.target);
});

Resources

10. Memory Management

Level: Less common as a direct question, but senior interviews may have a "why is this leaking?" scenario.

JavaScript automatically frees unused memory, but objects can stay alive if something still references them, such as an event listener or timer.

Example

button.addEventListener("click", handleClick);

// Later when no longer needed
button.removeEventListener("click", handleClick);

Resources

MDN — Memory management
Chrome DevTools — Fix memory problems (hands-on: heap snapshots, detached DOM nodes)
web.dev — Memory leaks in web apps

Repaint vs Reflow: A Simple Explanation

Alexandra — Mon, 03 Aug 2026 13:34:46 +0000

What's happening when a website loads?

When you visit a website, your browser reads the code, it creates the DOM, it reads the CSS, it builds the CSSOM, figures out where everything should go, and then draws it on your screen. This process includes two main concepts: repaint and reflow.

What is a repaint?

A repaint happens when you change the appearance of an element, but NOT the sizes or positions. Think it as changing a text or background color, opacity, borders or box shadows.

element.style.color = "blue";
element.style.backgroundColor = "yellow";

When this happens, the browser just needs to redraw the pixels on screen. In general, this is somewhat fast.

What is a reflow?

A reflow (or "layout") happens when you change the size or position of an element. Think about it as a result of changing width, height, padding or margins, adding or removing elements from the page, showing/hiding elements with display property, or changing the font size.

newElement.style.width = "500px";
newElement.style.padding = "20px";
document.body.appendChild(newElement);

When this happens, the browser has to:

Recalculate where everything should be
Figure out the new size of elements
Update all the affected elements
THEN repaint everything

That's why reflows are a bit expensive.

Why Should We Care?

Both repaints and reflows make the browser do work, which can make your website feel slow, especially when you trigger them often.

Imagine you're building a feature that updates a user's score:

for (let i = 0; i < 100; i++) {
  element.style.width = (100 + i) + "px";  // Reflow!
  element.textContent = i;                  // Reflow!
}

Every loop iteration triggers a reflow because we're changing the width and content. That's 100+ potential reflows! Modern browsers do batch some of these automatically, but you still want to minimize layout recalculations.

element.textContent = 99;
element.style.width = "199px";

Prefer to do all the changes at once. The browser will likely batch these into a single reflow cycle instead of triggering multiple sequential ones.

Tips to Avoid Performance Problems

Batch your changes

   // Good
   element.style.cssText = "width: 100px; height: 100px; color: red;";

   // Not as good
   element.style.width = "100px";
   element.style.height = "100px";
   element.style.color = "red";

Avoid reading layout properties in loops

  // Bad — alternating reads and writes force recalculation
for (let i = 0; i < elements.length; i++) {
  const currentWidth = elements[i].offsetWidth;  // READ — forces layout recalculation
  elements[i].style.width = (currentWidth + 10) + "px";  // WRITE — invalidates layout
}

// Good — batch all reads first, then writes
const widths = Array.from(elements).map(el => el.offsetWidth);
widths.forEach((width, i) => {
  elements[i].style.width = (width + 10) + "px";
});

Use classes instead of inline styles (similar with 1)

   // Good — batches all CSS changes together and is more maintainable
element.classList.add("highlighted");

// Not as good — multiple individual property assignments can trigger separate reflows
element.style.color = "blue";
element.style.backgroundColor = "yellow";
element.style.fontWeight = "bold";

CSS classes batch multiple properties into a single reflow cycle, and keep your styling logic separate from your JavaScript.

Use transforms for animations

   // Good for animations
   element.style.transform = "translateX(100px)";

   // Causes reflow
   element.style.left = "100px";

Transforms are cheaper because they skip the Layout and Paint phases of the rendering pipeline and only trigger Composite (which happens on the GPU). Position changes like left, top, width, and height require the browser to recalculate the entire layout.

Use requestAnimationFrame for Coordinated Updates

When you need to perform multiple DOM reads and writes in animations, use requestAnimationFrame to ensure they're batched together in the browser's rendering cycle:

// Good — batches all changes into one frame
requestAnimationFrame(() => {
  elements.forEach(el => {
    el.style.transform = "translateX(100px)";
  });
});

// Less efficient — each update happens immediately, may cause multiple recalculations
elements.forEach(el => {
  el.style.transform = "translateX(100px)";
});

Modern Browser Considerations

Browsers have become smarter about batching DOM operations. Modern engines like V8 (Chrome) and SpiderMonkey (Firefox) automatically defer and batch layout recalculations to some degree. However, this doesn't mean poor practices are harmless, you can still force synchronous reflows by reading layout properties like offsetWidth, clientHeight, or getBoundingClientRect() immediately after writing styles. Avoiding these patterns ensures your code stays performant across all browsers and circumstances.

The Bottom Line

☑️ Repaint = Change colors/appearance → relatively fast
☑️ Reflow = Change size/position/layout → slower, more expensive
☑️ Both slow down your site if you do too many
☑️ Group changes together when possible
☑️ Use CSS transforms for animations

Next time a website feels slow, there's a good chance it's because the browser is constantly doing reflows and repaints.

[Boost]

Alexandra — Mon, 03 Aug 2026 11:48:39 +0000

Alexandra

Jul 20

Does the web feel slower these days?

4 min read

The Comfort Atlas: What Does Home Taste Like?

Alexandra — Sat, 01 Aug 2026 21:19:16 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

The Comfort Atlas is a spinning 3D globe of comfort food from ~100 countries.

Virtually travel the globe and have a taste of the comfort foods from 100~ countries. Moussaka in Greece, Jollof Rice in Nigeria, Pho in Vietnam. There is also a "featured dish of the day" that rotates deterministically so it's the same for everyone visiting that day. And the fun feature: visitors can type in their own comfort dish and generate a downloadable, passport-stamp-style card in one of three color styles.

Demo

https://comfort-atlas.netlify.app/

Journey

I started with a flat SVG world map, clickable countries, keyboard support, a hover tooltip on the map, all built on real elements so accessibility came for free. It worked fine, but it looked very meh.

So i decided to try something i have never done before. Make a globe! I used cobe which promised a 3D globe out of the box. First attempt rendered absolutely nothing but floating dots. 😂 With a lot of the help of my friend claude, we found out that their docs are outdated, and there is a createGlobe() that draws exactly one synchronous frame and expects you to drive a requestAnimationFrame loop calling .update() yourself.

Two things on the globe I'm proud of, because neither had any library support: a hover tooltip that tracks a marker in 3D space, and a fading "trail" of great-circle arcs between the countries you've visited. Both came down to translating the projection math out of a minified bundle into something readable.

What I would do next: dark mode, enrich the content, comfort food battles per country.

What I learned: a lot about accessibility in 3D/canvas, which is so much more difficult than the 2d one, one check for a11y is never enough. Maps are hard, and getting something to track a moving 3D object from regular DOM is even harder.

Licensed under MIT

Fun fact: I don't like Moussaka, even though i am greek, my comfort food is Pizza or Giouvetsi. xD

Collaborative Filtering: How Computers Find Your Next Favourite Thing

Alexandra — Fri, 31 Jul 2026 18:01:28 +0000

🎯 Finding Your Taste Twin

Imagine walking into a party where you don't know anyone.

Someone notices your t-shirt and starts a conversation: "You like Arctic Monkeys? Me too."

"You also watched Severance?"
And your favorite game is Baldur's Gate 3?"

After five minutes, you realize you share almost identical tastes.

Then they say: "You HAVE to watch Silo."

Chances are you'll trust them. Not because you know anything about Silo. But because this stranger has repeatedly proven they like the same things you do.

That my friends, is collaborative filtering.

⚙️ The Mystery: How Does Netflix Know?

It's tempting to think Netflix stores detailed notes on every film ever made. Somehow the algorithm always recommends something you end up liking. Maybe it relates actors? or genres?or cinematography?

While some recommendation systems definitely can use that information, collaborative filtering doesn't need any of it. Instead, to the algorithm every movie is just a column in a giant spreadsheet and it asks a much simpler question: Who else behaves like you?

User	Iron Man	Barbie	Titanic	Matrix
Alice	⭐⭐⭐⭐⭐	⭐	⭐	⭐⭐⭐⭐⭐
Bob	⭐⭐⭐⭐	⭐	⭐	⭐⭐⭐⭐
Carol	⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐

A Quick History

Collaborative filtering dates back to the early 1990s. Researchers working on a project called GroupLens realised something:

People who agreed in the past often agree again in the future.

Amazon, Netflix, and Spotify later applied similar ideas to recommendations. Today, almost every major platform uses collaborative filtering as part of a larger system.

How the Algorithm Finds Your Taste Twin

Collaborative filtering doesn't understand products. It doesn't know anything about movies or music. It's based on the idea that people with similar past behavior often make similar choices.

You and another person watched these movies:

The recommendation engine gives a high similarity score between you and Kelly because your ratings are consistently alike.

If Kelly watches Dune and rates it with 5 stars, there's a good chance you will love Dune too.

Under the hood, these systems often compare users using mathematical similarity measures like cosine similarity or Pearson correlation. You don't need to understand the formulas to understand the idea: the system compares the users history with millions of other users. The more often two people agree, the more similar they become.

Measuring Similarity

So far, we've treated "similarity" as a vague concept, but recommendation systems need a number.

There are several ways to calculate how similar two users are:

Cosine Similarity

Imagine each user's ratings are represented as a vector.

You: [5, 4, 1, 5]
Kelly: [5, 4, 1, 4]

Cosine similarity measures the angle between those vectors.

A score close to 1 means the users have very similar preferences.
A score close to 0 means they're largely unrelated.

The actual formula looks intimidating:

cos(θ) = (A · B) / (||A|| ||B||)

Fortunately, the intuition is much simpler than the equation:

users whose rating vectors point in roughly the same direction tend to enjoy the same things.

A different approach

Everything we've seen so far is called User-Based Collaborative Filtering. Another approach is Item-Based Collaborative Filtering. In our previous movie example, imagine targeting similar movies instead of users. If thousands of viewers liked Interstellar AND Arrival AND Blade Runner, there is a good chance they will love Dune too.

This algorithm groups movies that frequently appear together, so when you watch 2-3 k-dramas, now your feed is full of them. Not because the system understands the genre, but because lots of people who loved the choice A loved the choice B too.

You Don't Even Need Ratings

I don't know who even remembers this, but in the early days of Netflix you could rate movies with stars. You don't actually need them. Modern recommendation systems often learn from your behaviour. Instead of asking if you like something or you, they watch things like "did she finish the movie?", "what did you rewatch", "what do you have in your wishlist", "what you stop after two minutes".

This is called implicit feedback, and it is often more reliable than ratings because it reflects what people actually do.

Where It Breaks Down

Collaborative filtering is powerful but it has some problems:

1. The New User Problem

If you are a new user in Netflix, you haven't watched anything. So nobody is at this point similar to you. This is called the Cold Start Problem.

Solution: Ask new users to rate a few movies first, or show them the most popular content until you have enough data.

2. The New Movie Problem

A new movie released today, but this means that nobody has watched it yet, and thus nobody has rated it. So the collaborative filtering cannot recommend it.

Solution: Use content-based filtering (analyzing genre, cast, plot) until the movie has enough ratings.

3. Taste Changes

A very human behaviour we have is that our taste changes over time. Maybe in 2018 you mostly watched cheesy hallmark movies and then in 2026 you watch only animes. The problem is that your old ratings still exist.

Solution: Recommendation systems weight recent behaviour more heavily than old behaviour, so your old tastes and choices doesn't haunt you forever.

4. Niche Content

The thing with recommendation systems is that they need data. A lot of them. So popular movies which have millions of ratings are more likely to get endorsed.

Independent films might have only a few hundred, which makes niche content harder to recommend. The algorithm works best with volume. Blockbusters get pushed. Hidden gems stay hidden.

5. The Filter Bubble

Recommendation systems can accidentally reinforce your existing preferences. If Netflix keeps recommending crime dramas, you're more likely to watch them. The system then becomes even more confident that crime dramas are what you like, creating a feedback loop. Over time this can reduce diversity in recommendations and make it harder to discover completely new kinds of content.

Key Takeaways

✅ Collaborative filtering doesn't need to understand movies or products but instead looks for people with similar behaviour.
✅ Similar people often make similar future choices.
✅ More data usually means better recommendations. The algorithm gets smarter as more people use it.
✅ Modern recommendation systems combine collaborative filtering with many other techniques. Content-based filtering, deep learning, and hybrid approaches all work together to overcome individual weaknesses.

Resources

Google Developers — Recommendation Systems
https://developers.google.com/machine-learning/recommendation
Google Developers — Collaborative Filtering
https://developers.google.com/machine-learning/recommendation/collaborative/basics
Using Collaborative Filtering to Weave an Information Tapestry - Goldberg, Nichols, Oki & Terry (1992)
https://dl.acm.org/doi/10.1145/138859.138867
GroupLens: An Open Architecture for Collaborative Filtering of Netnews - Resnick et al. (1994)
https://dl.acm.org/doi/10.1145/192844.192905
Item-Based Collaborative Filtering Recommendation Algorithms - Sarwar et al. (2001)
https://dl.acm.org/doi/10.1145/371920.372071
Recommender Systems: The Textbook - Charu C. Aggarwal
https://link.springer.com/book/10.1007/978-3-319-29659-3

Understanding JavaScript Execution Context: The Foundation of Interactivity

Alexandra — Mon, 27 Jul 2026 10:47:33 +0000

The most difficult thing in JavaScript is understanding how things are collaborating in order to provide interactivity.

The execution context is equivalent to a workspace. Whenever JS runs some code, it creates a workspace to contain everything it needs to do it successfully. That workspace has the variables, the functions, the this and information on where to continue working.

Creating contexts

There are two ways to create this workspace:

When a program starts (Global execution context)
Every time a function is called (Function execution context)

const name = "Alex";
function greet() {
    const message = "Hello";
    console.log(message);
}
greet();

when this program starts JS creates the global context with the name and greet.Then the greet function is called, which creates a new execution context that includes the variable message. When the function greet() finishes its execution, this context is removed. When the program finishes the global context is also removed. A fair question here is: "removed from where"? The answer is: from the infamous call stack.

The call stack

These execution workspaces are stored in a stack. If you don't know what a stack is: it is a data structure with some specific properties. New elements are added at the top of the stack, elements are removed also from the top of the stack. The most famous comparison is to think of a stack as a stack of plate. You wouldn't remove a plate from the bottom of the stack. This property is called LIFO: Last in First out.

┌─────────────┐
│   greet()   │  ← Top (will be removed first)
├─────────────┤
│   Global    │  ← Bottom (removed last)
└─────────────┘

When greet() finishes, it's "pop'ed" from the stack and only the global context remains (until the end of this program)

function first() {
    second();
}

function second() {
    third();
}

function third() {}

Before any call:        During execution:       After all finish:
┌──────────────┐        ┌──────────────┐       ┌──────────────┐
│   Global     │        │   third()    │       │   Global     │
└──────────────┘        ├──────────────┤       └──────────────┘
                        │  second()    │
                        ├──────────────┤
                        │   first()    │
                        ├──────────────┤
                        │   Global     │
                        └──────────────┘

As every functions finishes their executions, it's get popped from the stack. First the third finishes and it is removed, then the second, etc.

The two phases of the context

Every execution context has two phases. The 1st phase is the Creation: JS scans the code and prepares the memory, it identifies variables and functions.

Variables declared with var are initialised with undefined.
Functions defined with the function keyword are saved as a whole.
let and const variables are registered in an other place called Temporal Dead Zone.

The next phase is the execution: JS runs the code line-by-line. It assign values to variables and executes statements.

Why hoisting happens?

There is a word that scares every web developer: hoisting. This happens due to the creation phase. As JS scans the code it already knows about variables and functions before execution even begins. That process is called hoisting.

console.log(a); // Prints undefined, because JS initialized the a with undefined in the creation phase
var a = 5;

Function declarations are fully hoisted, so you can call them even before they are written.

greet(); // This works! Prints "Hello"

function greet() {
    console.log("Hello");
}

Note: function expressions are NOT hoisted. Function expressions are functions that are stored in a variable.

`let` and `const` against hoisting

In ES6 the keywords let and const were introduced. When you run the same code as before but using let this time..you get a reference error. what is happening?

console.log(a); // throws ReferenceError
let a = 5;

Javascript still knows that a exists, but the difference is that now is not saved in the context. Instead, it's stored in an another place called Temporal dead zone (TDZ).

Understanding TDZ

The TDZ is a region in a block where a variable exists but cannot accessed (yet). TDZ starts from the beginning of the block until the variable is declared and initialized.

if (true) {
    // TDZ for 'a' starts here
    console.log(a); // ReferenceError - 'a' is in TDZ, not accessible

    let a = 5;      // TDZ ends here, 'a' is now initialized and accessible

    console.log(a); // 5 - now it works
}

The Scope Chain: Looking Beyond the Current Context

When you reference a variable inside a function, JS doesnt only look in the current execution context. If the variable is not found in the current, it start looking on the parent, and then it's parent until it reaches the global context. This is called scope chain.

const global = "I'm a global var";

function outer() {
    const outerVar = "I'm in outer scope";

    function inner() {
        const innerVar = "I'm in inner scope";

        console.log(innerVar);  // ✅ Found in inner's context
        console.log(outerVar);  // ✅ Found in outer's context (via scope chain)
        console.log(global);    // ✅ Found in global context (via scope chain)
    }

    inner();
}

outer();

summary

✅ JS creates an execution context before running code
✅ Every function call creates an execution context
✅ These contexts are managed using the call stack
✅ Each execution context has a creation and an execution phase.
✅ Hoisting happens in the creation phase due to the scan of the code.
✅ const and let solved the initialization issues in JS by storing variables in TDZ
✅ The scope chain allows functions to access variables from their parent contexts (lexical scoping)

DEV Community: Alexandra

What do you build when you can build anything?

The Cost of Building Everything

Welcome to Agency Hell

What Do You Actually Care About?

Possibility Isn’t Purpose

From Figma to the browser: building a shared mental model

The canvas vs. the browser

Auto Layout → Flexbox

When one dimension isn't enough → CSS Grid

Designing for change → responsive layouts

The container matters → container queries

Beyond the handoff

What two months of interviewing taught me about the 2026 tech job market

1. The expectation is to be the perfect fit

2. Interviewing well seems to matter more than engineering well

3. Companies want you to be everything and salaries don't necessarily reflect it

4. Some job advertisements don't feel real

5. Job applications have become unnecessarily enormous

6. Job descriptions are generally bad

HTML is getting cool again: Meet the Invoker Commands API

State boilerplate to open a dialog

Enters the chat: the Invoker Commands API

How to do it in React?

Is that a really big deal?

Browser support

References

How Many Introductions Away Are You From Pedro Pascal? A Practical Introduction to Graph Search

Turn your social life into a graph

Make our delusions an algorithm

Breadth-first search explained

Put everything together

The twist: real relationships aren't equal

Dijkstra's algorithm, briefly

Same graph, different nouns

Frontend system design interviews are weird. Here’s how I now approach functional requirements.

What are functional requirements?

Functional vs non-functional requirements

Don't accept the prompt as the specification

Make assumptions explicit

Requirements drive architecture

From requirements to frontend architecture

Functional requirements also protect your scope

Start with "what", then design "how"

The 10 JS Topics Every Frontend Engineer Should Know

1. Execution Context & Hoisting

2. Closures

3. The Event Loop

4. Promises & Async/Await

5. this Keyword

6. Objects & Recursion

7. Arrays & Data Manipulation

8. Browser Rendering & Performance

9. Event Propagation

10. Memory Management

Repaint vs Reflow: A Simple Explanation

What's happening when a website loads?

What is a repaint?

What is a reflow?

Why Should We Care?

Tips to Avoid Performance Problems

Modern Browser Considerations

The Bottom Line

Further Reading

[Boost]

Does the web feel slower these days?

The Comfort Atlas: What Does Home Taste Like?

What I Built

Demo

Journey

Collaborative Filtering: How Computers Find Your Next Favourite Thing

🎯 Finding Your Taste Twin

⚙️ The Mystery: How Does Netflix Know?

A Quick History

How the Algorithm Finds Your Taste Twin

Measuring Similarity

Cosine Similarity

A different approach

You Don't Even Need Ratings

Where It Breaks Down

5. `this` Keyword

`let` and `const` against hoisting