DEV Community: Alexandra

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)

What Are Embeddings?: How AI Knows a Cat and a Kitten Are Related ⭐

Alexandra — Sat, 25 Jul 2026 11:02:11 +0000

This is a very simplified version of what an embedding is and is meant for beginners. Felt that I had to put a disclaimer here for the ai bros.

The question `embeddings` answer

How does a computer "know" that a cat and a kitten are related, that a dog is closer to a cat than to a car, and that a car is closer to a truck than to either a cat or a dog?? Computers don't understand meaning, they only understand numbers. So the trick is turning the meaning of text into numbers that math can work with.

An embedding is simply a long list of numbers that represents the meaning of a piece of text. Modern embeddings often contain hundreds or even thousands of numbers, but you don't need to understand each number individually. Pieces of text with similar meaning end up close together in this mathematical space.

A map of meaning

Imagine every word or phrase being placed on a giant map. Similar meanings end up close together, while unrelated end up far away. A model places words near each other based on how they are used in huge amounts of text, so "cat" and "kitten" end up near each other, "dog" and "puppy" are also close together and nearby to cats too, and something unrelated like a "car" sits in a completely different region.

In reality, embeddings live in far more bigger structure than a map, meaning in multiple dimensions, usually hundreds or thousands, which is impossible to actually draw (or even understand with my small 3d brain). But the two-dimensional version captures the core idea: distance yields relationships.

Where the numbers actually come from

An embedding isn't assigned by a person deciding "cat should be at this coordinate". During the training phase a model gradually learns how to convert text into embeddings based on the contexts it sees across enormous amounts of data. Words used in similar contexts end up near each other, because that's all the model ever sees: patterns in language.

This is also why embeddings capture relationships that go beyond simple synonyms. Classic examples show that the relationship between "king" and "queen" is mathematically similar to the relationship between "man" and "woman".

Why this matters for search and recommendations

Traditional keyword search matches exact words. Searching for an "affordable laptop" in a keyword-based system might miss a product like a "budget-friendly notebook" because the words don't literally match, even we (the humans) know that the meaning is identical.

Embedding-based search fixes this problem. Instead of matching words, it converts your search query into a point in the giant map and finds the nearest neighbors/points. This is why modern search and recommendation systems can surface something relevant even when you didn't use the "right" word.

Words aren't the only thing that can be embedded

Despite using words like "cat" as examples, embeddings aren't limited to single words. Entire sentences, paragraphs, documents, images, and even audio can all be represented as embeddings. The idea stays exactly the same: similar meaning ends up close together in the giant map.

In previous articles we talk about RAG and how this has a retrieval step. A simplified description of the retrieval step by adding the embeddings to the calculation will be: Your question is converted into an embedding, the documents have been embedded already, and the system simply retrieves the ones that are closest in that embedding map.

Where this shows up if you're building products

If you're building search, recommendations, finding duplicate content, or anything that needs to group or match content by meaning rather than exact text, embeddings are usually the tool for it, not string matching anymore.

A few practical things worth knowing:

Documents are usually embedded once and stored. When a user searches, only the new query needs to be embedded, making retrieval much faster.
Similarity isn't the same as correctness. Two pieces of text can be very similar while still answering the wrong question. That's why many systems rank, filter, or validate results after the similarity search.
The embedding model matters. Different embedding models place things differently, and a model tuned for one domain may not embed specialised or technical content as usefully as one tuned for that domain.

Resources

If you'd like to dive deeper into embeddings and how they're used in modern AI systems, these are excellent starting points:

Anthropic – Embeddings Documentation

https://platform.claude.com/docs/en/build-with-claude/embeddings

A practical guide explaining what embeddings are, how they work, and how they're used for semantic search, recommendations, and retrieval.
OpenAI – Embeddings Guide & FAQ

https://help.openai.com/en/articles/6824809-embeddings-faq

Covers OpenAI's embedding models, common questions, distance metrics, and best practices.
Word2Vec: Efficient Estimation of Word Representations in Vector Space (2013)

https://arxiv.org/abs/1301.3781

The classic paper by Tomas Mikolov and colleagues that popularised learned word embeddings.
Pinecone – Dense Vector Embeddings Explained

https://www.pinecone.io/learn/series/nlp/dense-vector-embeddings-nlp/

A visual, beginner-friendly explanation of dense vectors, embeddings, and semantic search, with examples beyond Word2Vec.
Jay Alammar – The Illustrated Word2vec
https://jalammar.github.io/illustrated-word2vec/
A visual, intuitive explainer on word embeddings, in the same style as his famous "Illustrated Transformer."
Embeddings & Vector Search in 2026: The Engineer's Complete Guide
https://jobsbyculture.com/blog/embeddings-vector-search-guide-2026
Covers embedding models, ANN algorithms (HNSW, IVF), and building production RAG pipelines.
How to Generate Better Embeddings for Vector Search
https://pr-peri.github.io/llm/2026/02/12/generate-embeddings-vector-search.html
Practical guide to improving retrieval quality via chunking, cleaning, metadata, hybrid search, and proper evaluation (Recall@K, MRR).
Best Embedding Models 2026: Tested on 50K Documents
https://pecollective.com/tools/best-embedding-models/
Compares OpenAI, Cohere, Voyage AI, and Jina embedding models on real retrieval benchmarks, not just MTEB scores.

[Boost]

Alexandra — Fri, 24 Jul 2026 15:04:00 +0000

Alexandra

Jul 19

Tokens aren't words: what actually happens when you send a prompt

#eli5 #ai #webdev #beginners

3 min read

Stop Hiring a Rocket Scientist to Check If a Box Is Empty

Alexandra — Thu, 23 Jul 2026 17:26:44 +0000

One thing I've been thinking about lately is what trade-offs companies are willing to make in order to market their products as "AI-powered."

A tale as old as 2023

A team needs to validate an email address. Someone asks, "What if we used AI?" Five minutes later there's a model call, an API key, a loading spinner, a monthly bill & somehow Kubernetes got involved. Congratulations, you've successfully turned O(1) into "please wait while we contact the cloud."

This is not an argument against AI. Large language models are highly effective for many categories of problems. The issue is not the technology itself, but its application to tasks that never needed it in the first place, because it's new and shiny and everyone is doing it.

The actual differences

Here's an unglamorous truth: an if statement & an LLM call are not doing the same job. They're built for different kinds of problems, and their differences are greater than people give it credit for.

An if statement runs in a millisecond, costs nothing per call, and gives you the exact same answer every single time for the same input (deterministic). An LLM call, takes real time, costs real money, and can give you a slightly different answer to the exact same question depending on the day, the model version, or the wind direction.

if-statement or AI?

Reach for an if statement (or a regex, or .. or ..) when:

The rule is simple and well-defined. "Is this a valid email format?" "Is the cart total over $50?" "Is the field empty?"
You need the same input to produce the same output. Billing logic, permission checks, form validation. No your users don't want their invoice total to vary by mood.
Performance is important and there is no ambiguity requiring interpretation.

Reach for AI when:

The task requires judgement. Summarise an article, classifying open-ended free text into fuzzy categories.
The input space is too large or unpredictable. You can't write an if statement for "understand what this customer is actually frustrated about" from a paragraph of free text.
Some variability in output is fine, or even desirable. A creative writing assistant that gives the exact same suggestion every time isn't actually that useful.

More examples than you asked for, because this pattern is everywhere

Password strength meter. "At least 8 characters, one number, one symbol" is a rule. Come on. We've been solving this since MySpace was a thing. No model needed, no matter how tempting "AI-powered password feedback" sounds on a feature list.

Flagging a support ticket as urgent. If "urgent" just means "contains the word 'urgent' or 'broken'," that's a keyword check. If "urgent" means understanding the tone, the context, and the severity from a paragraph of a frustrated customer wrote at 2am, that's no longer a keyword problem. That's a language understanding problem.

Discount code validation. "Is this code in our database and not expired?" is a lookup, full stop. Please don't ask a model to check a database for you; that's what the database is for.

Sorting a list by price. Please don't spend $0.002 to rediscover ascending order.

Summarizing 200 pages of meeting notes into three takeaways. A hard to write a rule for. This is a real, appropriate use of a model's judgement.

Writing a product description from a spec sheet. Turning structured facts into natural, readable list is a language task. This is AI doing what it's actually good at.

The cost of choosing the wrong tool

This isn't just a complaint about over-engineering. Reaching for AI on an if-statement problem has real costs:

Latency you didn't need to add. A local computation becomes a network request with inference time.
Money you didn't need to spend. Each inference incurs a monetary cost that accumulates with usage. We've somehow managed to invent a subscription for if.
Unpredictability you didn't ask for. If your business logic can quietly behave differently for the exact same input, you've turned a deterministic system into a probabilistic one. Now you get to debug "why did this work yesterday and not today" for a rule that used to just... work.
A dependency you didn't need. Functionality becomes dependent on the availability, performance, and pricing of third-party AI services.

Reflect on our choices

Before reaching for AI, ask: could I write this rule down in a sentence, and would that sentence still be true tomorrow? If yes, you probably want an if statement, not a model call. If the honest answer is "well, it depends, there's a lot of nuance, it's hard to actually pin down," that's usually the signal that you've found a problem AI is actually good at.

AI earning its place in a product should feel like reaching for a tool that's uniquely suited to a hard problem, not like a reflex applied to everything because it's the exciting new thing to reach for.

Sometimes the most sophisticated piece of technology in the room is the engineer who knew not to call the model.

Resources

Google's guidance on when to use ML — from Google's own People + AI Guidebook, on evaluating whether a problem needs machine learning: https://developers.google.com/machine-learning/guides/rules-of-ml
Martin Fowler on YAGNI ("You Aren't Gonna Need It") — https://lawsofsoftwareengineering.com/laws/yagni/
Anthropic's guide to when (and when not) to use agents/LLMs — practical framing for deciding where a model call is actually justified: https://www.google.com/search?client=firefox-b-d&q=Anthropic%27s+guide+to+when+%28and+when+not%29+to+use+agents

What is a context window, actually?

Alexandra — Wed, 22 Jul 2026 09:30:02 +0000

AI is moving fast, and it feels like there's a new concept to learn every week. In an effort to actually understand this whole new world instead of just skimming past it, I've been writing ELI5 articles breaking down concepts that show up constantly in AI conversations but rarely get explained simply. This time, a term that gets thrown around a lot without much explanation: the context window.

AI 101 Recap

The context window is the total number of input and output tokens an LLM can consider while generating a response. Your prompt, the conversation history, and even the model's response all share that same "budget" of tokens. As a conversation with an LLM grows longer, more tokens live in this window.

So far so good. Every AI model has a limit on how many tokens it can hold in its "working memory" at once. So the interesting part with the context window is what happens when you reach these limits.

Why are there limits?

There are several reasons models have context window limits. Processing more tokens requires more memory and computation, making every request slower and more expensive. On top of that, today's models struggle to use very long contexts effectively. They naturally pay more attention to the beginning and end of a conversation than the middle ("lost in the middle" problem).

The Amnesia Problem

An AI model has no persistent memory between conversations. Within a long conversation, it only sees whatever still fits inside its context window. Think of it as a sliding window: as new messages come in, older ones eventually slide out and are no longer visible to the model.

This is why a long conversation can feel like the model has "forgotten" something you told it early on. It doesn't actually forget, it just no longer has access to that part of the conversation, unless the product you're using has built something extra on top to handle it.

How RAG helps

RAG (retrieval-augmented generation) sounds technical, but the idea is simple: look it up before you answer, instead of guessing from memory.

Think of the model as a smart intern who read a huge pile of general knowledge, but has never seen your company's internal docs. If you ask that intern a question about your product, you wouldn't expect them to know the answer off the top of their head.

The flow looks more or less like this:

That's RAG. Before generating a response, the system retrieves the most relevant pieces of information and adds only those to the prompt. Instead of searching through thousands of documents itself, the model receives just the information it needs.

This fixes two problems at once:

It solves the "too much to fit" problem. You don't need to cram an entire wiki into the context window — just the relevant slice.
It solves the "the model doesn't know that" problem. Training data has a cutoff and doesn't include your private docs. Retrieval hands the model current, specific facts instead of asking it to make something up.

It's not magic, though. If the search step grabs the wrong page the model's answer will be wrong too. A RAG system is only as good as its retrieval step, not just the model doing the writing at the end.

Why longer context isn't automatically better

Newer models advertise huge context windows, sometimes hundreds of thousands of tokens. It's tempting to think the fix for all of this is simple: just make the window bigger, and pile everything in.

Turns out that doesn't hold up as well as it sounds.

It costs more and takes longer. Every extra token in the prompt means more processing on every single request.
Models don't "read" a huge context evenly. They tend to pay attention to the start and the end of a long conversation, and quietly lose track of things in the middle.
More text means more noise. A huge pile of context gives the model more chances to get distracted by something irrelevant, outdated, or conflicting.

A bigger context window isn't automatically better. It gives the model more information to work with, but also more opportunities to be distracted. That's why RAG matters: retrieving a small set of relevant information is usually more effective than hoping the model can make sense of everything at once.

Resources

Context windows

Anthropic's context window documentation — official, model-specific limits and behavior
"Lost in the Middle: How Language Models Use Long Contexts" (Liu et al., 2023) — the research paper behind the finding that models underuse the middle of long contexts
OpenAI's models documentation — useful for comparing how another provider frames the same constraint

RAG

"Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (Lewis et al., 2020) — the original RAG paper from Meta AI
Pinecone's guide to RAG — practical, vendor-neutral explanation
LangChain RAG documentation — hands-on look at how RAG pipelines are built
AWS: "What is RAG?" — plain-language explainer
IBM: "What is retrieval-augmented generation?" — another accessible, non-technical framing

DEV Community: Alexandra

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

1. The New User Problem

2. The New Movie Problem

3. Taste Changes

4. Niche Content

5. The Filter Bubble

Key Takeaways

Resources

Understanding JavaScript Execution Context: The Foundation of Interactivity

Creating contexts

The call stack

The two phases of the context

Why hoisting happens?

let and const against hoisting

Understanding TDZ

The Scope Chain: Looking Beyond the Current Context

summary

What Are Embeddings?: How AI Knows a Cat and a Kitten Are Related ⭐

The question embeddings answer

A map of meaning

Where the numbers actually come from

Why this matters for search and recommendations

Words aren't the only thing that can be embedded

Where this shows up if you're building products

Resources

[Boost]

Tokens aren't words: what actually happens when you send a prompt

5. `this` Keyword

`let` and `const` against hoisting

The question `embeddings` answer