DEV Community: Karen Molina

Prepárate para tu entrevista frontend: 10 ejercicios de hoisting y scope (con respuestas)

Karen Molina — Mon, 09 Nov 2026 20:42:40 +0000

En el post de variables, tipos de dato, scope y hoisting vimos los conceptos. Ahora vamos a practicar como de verdad lo evalúan en las entrevistas: "¿Qué imprime este código?"

Cómo usar este post: lee cada ejercicio, anota tu respuesta y después abre la solución. Si quieres comprobarlo, córrelos en la consola de tu navegador. Todas las respuestas están probadas en Node.js.

Repaso rápido

Declaración	¿Hace hoisting?	Antes de su línea
`var`	Sí	`undefined`
`let` / `const`	Sí, pero sin inicializar	`ReferenceError` (temporal dead zone)
Declaración de `function`	Sí, completa	Se puede llamar
Expresión de función / arrow	Solo la variable	Depende de si es `var`, `let` o `const`
`class`	Sí, pero sin inicializar	`ReferenceError`

Y recuerda: el código no se mueve. Antes de ejecutar un scope, el motor registra sus declaraciones. Lo que cambia es si se inicializan o no.

Ejercicio 1: para calentar

console.log(saludo);
var saludo = "Hola";
console.log(saludo);

Solución
undefined y luego "Hola".

saludo se registra antes de que corra el código y se inicializa como undefined. La asignación = "Hola" pasa en la línea 2, así que el primer log ve undefined.

Ejercicio 2: let y const

console.log(primera);
console.log(segunda);

let primera = "Soy un let";
const segunda = "Soy un const";

Solución
Un solo error: ReferenceError: Cannot access 'primera' before initialization.

La segunda línea nunca se ejecuta, porque el primer error detiene la ejecución.

Y lo más importante: primera y segunda sí hacen hoisting. Si no lo hicieran, el error sería "primera is not defined". "Cannot access before initialization" significa que el motor sabe que la variable existe, pero todavía está en la temporal dead zone.

Ejercicio 3: tres tipos de funciones

console.log(suma(2, 3));
function suma(a, b) {
  return a + b;
}

console.log(suma2(2, 3));
const suma2 = function (a, b) {
  return a + b;
};

Solución
5 y luego ReferenceError: Cannot access 'suma2' before initialization.

Las declaraciones de función hacen hoisting con todo y su cuerpo, así que se pueden llamar antes. suma2 es solo una variable const que guarda una función, así que sigue las reglas de const. Lo mismo pasa con las arrow functions.

Ejercicio 4: la misma función, pero con var

despedir();
var despedir = function () {
  console.log("Adiós");
};

Solución
TypeError: despedir is not a function.

Esta vez no es un ReferenceError. Con var, despedir existe y vale undefined, y llamar a undefined() es un TypeError. A los entrevistadores les encanta esta diferencia.

Ejercicio 5: el bloque que se escapa

if (true) {
  var escapa = "var";
  let seQueda = "let";
}

console.log(escapa);
console.log(seQueda);

Solución
"var" y luego ReferenceError: seQueda is not defined.

var ignora el scope de bloque; pertenece a la función que lo contiene (o al scope global). let solo existe dentro de las { }.

Ejercicio 6: shadowing con var

var x = 1;

function prueba() {
  console.log(x);
  var x = 2;
}

prueba();

Solución
undefined.

¡No 1! Dentro de prueba hay un var x local, que se registra al inicio de la función y se inicializa como undefined. Esa variable tapa (shadowing) a la x global, así que el log ve la local antes de su asignación.

Ejercicio 7: shadowing con let

let x = 1;

{
  console.log(x);
  let x = 2;
}

Solución
ReferenceError: Cannot access 'x' before initialization.

Podrías esperar 1, del scope de afuera. Pero el bloque interno tiene su propio let x, que hace hoisting al inicio del bloque y queda atorado en la temporal dead zone. La x interna tapa a la externa desde la primera línea del bloque.

Esta es la mejor prueba de que let sí hace hoisting.

Ejercicio 8: sin declaración adentro

var a = 1;

function externa() {
  console.log(a);
  a = 2;
}

externa();
console.log(a);

Solución
1 y luego 2.

Dentro de externa no hay var, let ni const, así que a se refiere a la variable de afuera por la scope chain. La función la lee y luego la reasigna.

Ejercicio 9: el mismo nombre, dos declaraciones

console.log(typeof foo);

var foo = 1;
function foo() {}

console.log(typeof foo);

Solución
"function" y luego "number".

Las dos declaraciones se registran, y en el hoisting gana la declaración de función. Después corre la línea foo = 1 y la reemplaza por un número. (Por favor, nunca escribas esto en código real.)

Ejercicio 10: typeof y la TDZ

console.log(typeof noDeclarada);
console.log(typeof enTDZ);
let enTDZ = "hola";

Solución
"undefined" y luego ReferenceError: Cannot access 'enTDZ' before initialization.

Normalmente typeof es "seguro": con una variable que no existe para nada, regresa "undefined" en lugar de lanzar un error. Pero una variable en la temporal dead zone es diferente. Sí existe, solo que no está inicializada, y typeof no te salva.

Ronda extra

Dos rápidos que salen en entrevistas más avanzadas:

new Usuario();
class Usuario {}

function saludar(a = b, b = "hola") {
  return a;
}
saludar();

Soluciones
Los dos lanzan un ReferenceError.

Las clases hacen hoisting como let: están en la temporal dead zone hasta su declaración.
Los parámetros por defecto se evalúan de izquierda a derecha. Cuando a intenta leer b, b todavía no se ha inicializado.

¿Cómo te fue?

De 10 a 12: estás lista o listo para esta parte de la entrevista.
De 6 a 9: repasa la temporal dead zone y el shadowing (ejercicios 6, 7 y 10).
Menos de 6: regresa al post de conceptos y vuelve a intentarlo en un par de días.

¿Cuál te hizo caer? Cuéntame en los comentarios 👇

Prepárate para tu entrevista frontend: JavaScript asíncrono, event loop, promesas y async/await

Karen Molina — Mon, 09 Nov 2026 20:40:44 +0000

El JavaScript asíncrono es donde las entrevistas dejan de ser de definiciones y empiezan a ser de cómo corre el lenguaje de verdad. Vamos a construirlo desde el principio.

Por qué JavaScript necesita código asíncrono

JavaScript corre en un solo hilo: ejecuta una cosa a la vez, en una sola pila de llamadas (call stack).

Eso es un problema cuando algo tarda, como una petición a una API, un temporizador o leer un archivo. Si JavaScript simplemente esperara, toda la página se congelaría: ni clics, ni scroll, ni animaciones.

Entonces, en lugar de esperar, JavaScript le pasa el trabajo lento al entorno (el navegador o Node.js), sigue ejecutando otro código y regresa por el resultado después. Eso es la programación asíncrona.

El event loop

Esta es la parte que hace que todo lo demás tenga sentido.

Hay cuatro piezas:

Call stack: donde corre tu código, una función a la vez.
Web APIs (o APIs de Node): donde esperan los temporizadores, las peticiones de red y los eventos, fuera de la pila.
Cola de tareas (macrotasks): callbacks de setTimeout, setInterval y eventos del DOM.
Cola de microtareas (microtasks): callbacks de promesas (.then, await) y queueMicrotask.

El event loop sigue una sola regla: cuando la pila está vacía, ejecuta todas las microtareas, luego una tarea, y repite.

La pregunta clásica de entrevista

¿Qué imprime esto?

console.log("1");

setTimeout(() => console.log("2"), 0);

Promise.resolve().then(() => console.log("3"));

console.log("4");

Respuesta: 1, 4, 3, 2.

1 y 4 son síncronos, así que van primero.
El callback de la promesa se va a la cola de microtareas.
El callback de setTimeout se va a la cola de tareas, aunque el tiempo sea 0.
Cuando la pila queda vacía, primero corren las microtareas (3) y luego la siguiente tarea (2).

Si puedes explicar esto paso a paso, ya respondiste la mitad de las preguntas de asincronía que te van a hacer.

Callbacks

Un callback es una función que se pasa a otra función para que la llame después.

function saludar(nombre, callback) {
  const mensaje = `Hola ${nombre}`;
  callback(mensaje);
}

saludar("Karen", (mensaje) => console.log(mensaje)); // "Hola Karen"

Un error muy común al aprender es pasar el resultado de una función en lugar de la función: saludar(obtenerNombre()) en vez de saludar(obtenerNombre). Lo primero ya no es un callback.

Y uno asíncrono de verdad:

console.log("Antes");

setTimeout(() => {
  console.log("Dentro del callback");
}, 1000);

console.log("Después");
// Antes, Después, Dentro del callback

El problema: el callback hell

Cuando los pasos asíncronos dependen unos de otros, los callbacks se anidan:

obtenerUsuario(id, (usuario) => {
  obtenerPedidos(usuario.id, (pedidos) => {
    obtenerFactura(pedidos[0].id, (factura) => {
      enviarCorreo(factura, (resultado) => {
        // ...y manejo de errores en cada nivel
      });
    });
  });
});

Difícil de leer, de manejar errores y de cambiar. Las promesas se crearon para resolver eso.

Promesas

Una promesa es un objeto que representa un valor que va a estar disponible en el futuro, o un error que explica por qué no.

Tiene un estado:

Estado	Qué significa
`pending`	Todavía esperando
`fulfilled`	Terminó bien, tiene un valor
`rejected`	Falló, tiene una razón (normalmente un `Error`)

Cuando una promesa se cumple o se rechaza, queda resuelta (settled) y ya nunca cambia. Por eso en este ejemplo el reject se ignora:

const promesa = new Promise((resolve, reject) => {
  resolve("listo");
  reject(new Error("ignorado")); // la promesa ya estaba resuelta
});

Crear una promesa

function esperar(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

Consumir una promesa

fetch("/api/usuario")
  .then((respuesta) => respuesta.json())
  .then((usuario) => console.log(usuario.nombre))
  .catch((error) => console.error("Algo falló:", error))
  .finally(() => console.log("Terminó, haya salido bien o no"));

Cada .then regresa una promesa nueva, así que puedes encadenar pasos en lugar de anidarlos. Un solo .catch al final maneja los errores de cualquier paso.

Correr varias promesas juntas

Aquí es donde suelen seguir las preguntas:

Método	Se cumple cuando	Se rechaza cuando
`Promise.all`	Todas salen bien	Cualquiera falla
`Promise.allSettled`	Todas terminan, bien o mal	Nunca
`Promise.race`	La primera termina	La primera termina con error
`Promise.any`	La primera sale bien	Todas fallan

async/await

async/await es sintaxis sobre las promesas que permite que el código asíncrono se lea como si fuera síncrono.

async hace que una función siempre regrese una promesa.
await pausa esa función hasta que una promesa se resuelve, sin bloquear el hilo principal.

async function mostrarUsuario(id) {
  try {
    const respuesta = await fetch(`/api/usuarios/${id}`);
    if (!respuesta.ok) throw new Error(`HTTP ${respuesta.status}`);
    const usuario = await respuesta.json();
    console.log(`Hola ${usuario.nombre}`);
  } catch (error) {
    console.error("No se pudo cargar el usuario:", error);
  }
}

Los errores se manejan con un try/catch normal.

El detalle que demuestra seniority: secuencial vs. paralelo

// Secuencial: la segunda petición espera a la primera. Lento.
const usuario = await obtenerUsuario(id);
const ajustes = await obtenerAjustes(id);

// Paralelo: las dos arrancan al mismo tiempo. Más rápido si no dependen una de otra.
const [usuario, ajustes] = await Promise.all([obtenerUsuario(id), obtenerAjustes(id)]);

Señalar esto en una entrevista, o en un code review, demuestra que piensas en el rendimiento y no solo en que funcione.

Respuestas para la entrevista

"¿Qué es el event loop?"
"JavaScript corre en un solo hilo con una sola pila de llamadas. El trabajo asíncrono, como temporizadores y peticiones de red, lo maneja el entorno, y sus callbacks se forman en colas. Cuando la pila está vacía, el event loop ejecuta todas las microtareas pendientes, como los callbacks de promesas, y luego la siguiente tarea, como un callback de setTimeout. Por eso una promesa resuelta corre antes que un setTimeout con tiempo cero."

"¿Callbacks, promesas o async/await?"
"Los callbacks son funciones que se pasan para ejecutarse después; se vuelven difíciles de manejar cuando se anidan. Las promesas representan un valor futuro con un estado, se pueden encadenar y centralizan el manejo de errores. async/await es sintaxis sobre las promesas que hace que el código asíncrono se lea de arriba a abajo, con try/catch para los errores."

Checklist rápida

[ ] ¿Puedes explicar por qué JavaScript necesita código asíncrono si corre en un solo hilo?
[ ] ¿Puedes dibujar la pila de llamadas, la cola de tareas y la de microtareas?
[ ] ¿Puedes predecir la salida de console.log, setTimeout y Promise.then juntos?
[ ] ¿Puedes nombrar los tres estados de una promesa?
[ ] ¿Sabes la diferencia entre Promise.all y Promise.allSettled?
[ ] ¿Puedes convertir dos await secuenciales en paralelos?

Anterior en la serie: funciones y closures.

¿Qué bug asíncrono te ha costado más horas? Cuéntame en los comentarios 👇

Prepárate para tu entrevista frontend: funciones y closures en JavaScript

Karen Molina — Mon, 09 Nov 2026 20:38:37 +0000

Si hay un tema de JavaScript que aparece en casi todas las entrevistas de frontend, son los closures. Y no se pueden entender bien sin entender primero las funciones. Así que empecemos por ahí.

Las funciones son valores

Una función es un bloque de código reutilizable que hace una tarea. En JavaScript, las funciones también son objetos de primera clase (first-class objects): las puedes guardar en variables, pasarlas como argumentos, regresarlas desde otras funciones y hasta agregarles propiedades.

Esa sola idea es la que hace posibles los callbacks, los event handlers, los componentes de React y los closures.

Hay varias formas de crear una función, y en una entrevista las diferencias importan.

Declaración de función

La forma clásica: la palabra function, un nombre, parámetros y un cuerpo.

function suma(a, b) {
  return a + b;
}

suma(2, 4); // 6

Las declaraciones de función hacen hoisting completo, así que las puedes llamar antes de la línea donde están escritas.

Expresión de función

Una función creada como parte de una expresión, normalmente asignada a una variable.

const suma = function (a, b) {
  return a + b;
};

suma(2, 4); // 6

Se ve casi igual, pero hay una diferencia clave: solo la variable hace hoisting, no la función. Si la llamas antes de esa línea, falla.

saludar();    // ✅ funciona: es una declaración
despedir();   // ❌ ReferenceError (con const) o TypeError (con var)

function saludar() { console.log("hola"); }
const despedir = function () { console.log("adiós"); };

Arrow functions

Llegaron con ES6 (2015). Tienen una sintaxis más corta, y si el cuerpo es una sola expresión, la regresan automáticamente.

const suma = (a, b) => a + b;

suma(2, 4); // 6

// Para regresar un objeto literal, envuélvelo en paréntesis
const crearUsuario = (nombre) => ({ nombre });

Pero las arrow functions no son solo una forma más corta de escribir. Se comportan distinto:

No tienen su propio this. Usan el this del código que las rodea. Son geniales para callbacks y malas para métodos de objetos.
No tienen el objeto arguments. En su lugar se usan rest parameters (...args).
No se pueden usar con new. new (() => {}) lanza TypeError: ... is not a constructor.

const temporizador = {
  segundos: 0,
  iniciar() {
    setInterval(() => {
      this.segundos++; // `this` sigue siendo `temporizador`, gracias a la arrow function
    }, 1000);
  },
};

Con una function normal dentro de setInterval, this ya no apuntaría a temporizador. Es una pregunta de seguimiento muy común.

IIFE (Immediately Invoked Function Expression)

Una función que se ejecuta en cuanto se define.

(function () {
  const secreto = "solo visible aquí dentro";
  console.log("Hola mundo");
})();

Antes de los módulos de ES y de let/const, las IIFE eran la forma principal de crear un scope privado y no ensuciar el global. Todavía las vas a ver en código viejo y en preguntas de entrevista.

Funciones constructoras y clases

Una función constructora crea objetos cuando la llamas con new.

function Usuario(nombre, apellido) {
  this.nombre = nombre;
  this.apellido = apellido;
}

const usuario = new Usuario("Jon", "Snow");
// { nombre: "Jon", apellido: "Snow" }

Cuando usas new, JavaScript:

crea un objeto vacío,
lo enlaza con el prototype del constructor,
ejecuta la función con this apuntando a ese objeto,
regresa el objeto (a menos que la función regrese explícitamente otro objeto).

Hoy normalmente escribirías lo mismo con class, que en el fondo es sintaxis sobre el mismo mecanismo:

class Usuario {
  constructor(nombre, apellido) {
    this.nombre = nombre;
    this.apellido = apellido;
  }
}

Respuesta para la entrevista: "En JavaScript las funciones son objetos de primera clase. Las declaraciones de función hacen hoisting completo; las expresiones no. Las arrow functions son más cortas, no tienen su propio this ni arguments, y no se pueden usar como constructoras. Las funciones constructoras y las clases crean objetos con new, que asigna this a un objeto nuevo enlazado al prototype."

Closures

La definición

Un closure es una función que recuerda las variables del scope donde se creó, incluso después de que ese scope terminó de ejecutarse.

Toda función en JavaScript forma un closure. No es una sintaxis especial; es una consecuencia de que las funciones sean valores y de la scope chain.

El ejemplo

En la primera versión de este post, mi ejemplo tenía un bug: llamaba a la función de afuera y esperaba que imprimiera. Esta es la versión corregida:

function decirHola() {
  const saludo = "Hola";

  function interna() {
    console.log(saludo);
  }

  return interna;
}

const hola = decirHola(); // decirHola ya terminó...
hola();                   // ...pero interna todavía recuerda `saludo`: "Hola"

decirHola ya regresó, así que en teoría saludo debería haber desaparecido. Pero interna guarda una referencia al scope donde se creó, así que saludo sigue vivo mientras exista interna.

Para qué sirve: estado privado

Los closures te permiten crear datos a los que no se puede acceder desde afuera.

function crearContador() {
  let cuenta = 0;

  return {
    incrementar() {
      cuenta++;
      return cuenta;
    },
    obtener() {
      return cuenta;
    },
  };
}

const contador = crearContador();
contador.incrementar();
contador.incrementar();

contador.obtener(); // 2
contador.cuenta;    // undefined: no hay forma de tocar `cuenta` directamente

La pregunta clásica de entrevista

Seguramente te va a tocar esta:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}
// 3, 3, 3

¿Por qué 3, 3, 3 y no 0, 1, 2? Porque var tiene scope de función, así que hay una sola i. Los tres callbacks hacen closure sobre la misma variable, y cuando por fin se ejecutan, el loop ya terminó e i vale 3.

La solución es let, que crea una variable nueva en cada iteración:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}
// 0, 1, 2

Closures en la vida real: React

Si usas React, usas closures todos los días. Cada render crea funciones nuevas que hacen closure sobre las props y el estado de ese render. De ahí viene el famoso bug del "stale closure" (closure obsoleto):

function Contador() {
  const [cuenta, setCuenta] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setCuenta(cuenta + 1); // siempre ve la `cuenta` del primer render
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <p>{cuenta}</p>; // se queda atorado en 1
}

El callback del intervalo hizo closure sobre cuenta = 0 y nunca ve las actualizaciones. La solución es la actualización funcional, que no depende del valor guardado en el closure:

setCuenta((c) => c + 1);

Mencionar esto en una entrevista demuestra que entiendes los closures más allá de la definición de libro.

Respuesta para la entrevista: "Un closure es una función que conserva acceso a las variables del scope donde se creó, incluso después de que ese scope terminó. Se usa para estado privado, fábricas de funciones, callbacks y memoización. Un ejemplo clásico es el loop con var y setTimeout que imprime el mismo valor tres veces; let lo resuelve porque crea una variable nueva por iteración. En React, los stale closures en efectos son un bug común causado por el mismo mecanismo."

Checklist rápida

[ ] ¿Puedes explicar por qué las funciones son "objetos de primera clase"?
[ ] ¿Sabes qué formas de función hacen hoisting y cuáles no?
[ ] ¿Puedes nombrar tres diferencias entre arrow functions y funciones normales?
[ ] ¿Puedes explicar qué hace new, paso a paso?
[ ] ¿Puedes definir un closure en una frase y dar un ejemplo?
[ ] ¿Puedes explicar la salida del loop con var y setTimeout?

Anterior en la serie: variables, tipos de dato, scope y hoisting.
Siguiente: JavaScript asíncrono: callbacks, promesas y async/await.

¿Cuál fue tu momento "¡ahhh, ya entendí!" con los closures? Cuéntame en los comentarios 👇

Code review as dialogue: what Paulo Freire taught me about mentoring developers

Karen Molina — Mon, 09 Nov 2026 18:17:16 +0000

Here's a code review comment I've received more than once, and, honestly, written more than once:

Change this to use useMemo.

It's correct. It's fast. The PR gets merged. And the junior who wrote it learns exactly one thing: that a senior person wanted useMemo there.

Next week, they'll ask again. Or worse, they'll start adding useMemo everywhere.

The banking model of code review

In Pedagogy of the Oppressed (1968), the Brazilian educator Paulo Freire described what he called the banking model of education. The teacher knows; the student doesn't. The teacher makes "deposits" of knowledge, and the student's job is to receive, store and repeat them.

Freire's problem with it wasn't only that it's boring. It's that it produces people who can follow instructions but can't think through new problems, and who learn that knowledge always comes from above.

A lot of code review works exactly like a bank:

The reviewer has the answer.
The comment states the fix.
The author applies it.
Nobody talks about why.

It scales badly. Seniors become bottlenecks, juniors stay dependent, and the team's knowledge lives in a few people's heads.

Problem-posing review

Freire's alternative was problem-posing education: instead of handing over answers, the teacher poses real problems, and teacher and student work through them together in dialogue. Both learn something. The student builds the ability to reason, not just a memory of the right answer.

In a code review, that shift can be surprisingly small:

Banking comment	Problem-posing comment
"Change this to use `useMemo`."	"This list re-renders on every keystroke. What do you think is causing it? Happy to pair if you want to dig in."
"Wrong. Handle the error."	"What should the user see if this request fails?"
"Don't put this in the component."	"If we need this same logic in the checkout page next month, where would you want it to live?"
"Use a Map here."	"This lookup runs inside a loop over every order. How does that scale with 10,000 orders?"

The questions aren't a trick to avoid giving answers. If the author is stuck, give the answer, and explain it. The point is that the first move is to invite their reasoning, not to replace it.

Five habits I try to practice

1. Explain the why, every time.
If you do write a direct fix, add one sentence about the reason. "Use useMemo here because this sort runs on every render and the list can be large." That sentence is the part they'll remember.

2. Ask about consequences, not syntax.
Linters handle syntax. Humans are good at asking about users, failures, edge cases and the future. "What happens if…" is the most useful phrase in review.

3. Mark the weight of each comment.
Freire insisted on dialogue between equals, and power makes that hard. Juniors often treat every comment as an order. Labels help: nit:, suggestion:, question:, blocking:. They make clear what's open for discussion.

4. Let the author teach you.
Dialogue goes both ways. Ask why they chose an approach before suggesting another. Sometimes they had a reason you didn't see. Saying "oh, I didn't know that, thanks" in a review is one of the most powerful things a senior can do for a team's culture.

5. Move long threads to a conversation.
After three back-and-forths, a 15-minute pairing session teaches more than ten more comments. Write the conclusion back in the PR so the knowledge stays.

Critical consciousness, in software

Freire had another idea that matters for engineers: conscientização, usually translated as critical consciousness. Education shouldn't only teach skills; it should help people understand the world they act in and question its effects.

In our work, that means mentoring isn't just about clean code. It's also about asking, together:

Who might this feature exclude?
What data are we collecting, and do we need it?
What happens to the people on the other side of this screen if it fails?

A junior who learns to ask those questions is worth more to a team than one who memorized every React hook.

What teaching kids taught me about teaching devs

Before and alongside my engineering work, I've taught STEAM workshops, mixing science, technology, art and math. The biggest lesson from those rooms is the same one Freire wrote about: people learn most when they're working on a problem that's real to them, and when someone asks them a good question at the right moment, instead of telling them the answer.

Developers are no different. The best mentors I've had rarely gave me the fix. They asked one question that made me see the problem differently, then let me find the way.

Seniority is how much others grow around you

There's a version of "senior" that means "the person who knows the answers." And there's a better one: the person whose team keeps getting better at finding answers without them.

Code review is where that happens, a few comments at a time. We can use it to make deposits, or to start a dialogue.

This piece comes from an essay I wrote on STEAM education, complexity and critical pedagogy during my master's. It's part of my series on the human side of building software.

What's the best review comment you ever received? I'd love to collect a few in the comments.

References

Freire, Paulo. Pedagogy of the Oppressed. 1968 (first English edition 1970).
Morin, Edgar. Introducción al pensamiento complejo. Gedisa, 1994.

Your face is not a password: designing biometric flows people can trust

Karen Molina — Mon, 09 Nov 2026 18:14:43 +0000

You can change a leaked password in a minute. You can cancel a stolen card in five.

You can't change your face.

That's the whole dilemma of biometrics in one sentence. Fingerprints, faces, irises and voices make identity checks fast and convenient, and they're becoming the default in banking, payments, travel and government services. But they're also permanent, intimate and, once they leave your device, very hard to take back.

Most of the debate about facial recognition happens at the level of policy and ethics. That matters. But a lot of the real decisions get made somewhere much less glamorous: in the onboarding flow, the consent screen, the error state and the database schema. In other words, by people like us.

Not a neutral tool

Biometric systems are often presented as purely technical: a camera, a model, a match score. But every one of them is designed by people with priorities, trained on data that reflects the world as it is, and deployed in places with very different power relationships.

The Argentine-Mexican anthropologist Néstor García Canclini has written about how, in societies shaped by insecurity, people increasingly accept surveillance and control as the price of feeling safe. Biometrics fit that pattern perfectly: they're sold as protection, and they often are. But the same infrastructure that verifies your identity at a bank can also be used to track, profile or exclude.

This is happening at national scale. In Mexico, for example, 2026 brought a biometric version of the CURP (the national population ID) being rolled out progressively, and a requirement to link every mobile phone line to a person's identity. Whatever you think of those policies, they mean that millions of people will go through identity flows designed by product teams, often on cheap phones and slow networks.

The question for us isn't only "should this exist?" It's also "if we're building it, how do we build it so it respects the person on the other side?"

Four places where design decisions matter

1. Consent that is actually consent

A pre-checked box under a wall of legal text is not consent. Neither is a flow where the only way forward is to accept.

Good biometric consent is:

Specific: say exactly what you capture (a face template, not "your data") and what for.
Separate: not bundled with terms of service or marketing permissions.
Optional when possible: if there's another way to verify identity, offer it on the same screen, with the same visual weight.
Reversible: tell people how to withdraw consent and delete their data, and make that path real.

<fieldset>
  <legend>How do you want to verify your identity?</legend>
  <label><input type="radio" name="verify" value="selfie" /> Take a selfie (we compare it once with your ID photo, then delete it)</label>
  <label><input type="radio" name="verify" value="document" /> Upload your ID and answer a few questions</label>
  <label><input type="radio" name="verify" value="branch" /> Verify in person at a branch</label>
</fieldset>

Notice what's not there: a default.

2. Bias is a product bug, not an edge case

Facial recognition systems don't fail equally for everyone. In 2018, Joy Buolamwini and Timnit Gebru's Gender Shades study found commercial gender classifiers performed far worse on darker-skinned women than on lighter-skinned men. In 2019, NIST's large evaluation of face recognition algorithms found demographic differences in error rates across many of the systems it tested, varying by algorithm.

Fingerprints have their own version: scanners struggle with worn or dry skin, which affects older adults and people who do manual work.

For a product team, that means:

Ask your vendor for error rates broken down by demographic group, not just one global accuracy number.
Monitor your own failure rates by device type, region and age band, if you can do it without collecting more sensitive data than you need.
Never make biometrics the only door. When the model fails, a person should have a dignified alternative, not a dead end.

3. Errors that don't accuse

When a face match fails, the person usually hears something like "We couldn't verify your identity." To them, that can sound like "We think you're lying."

Most failures are about light, angle, camera quality or network, not fraud. Say so:

"We couldn't get a clear photo. Try facing a window or a lamp, and hold the phone at eye level. You can also verify with your ID instead."

Give a reason, a next step and an exit. And never lock someone out after a few failed attempts without a human path.

4. Keep less, for less time

The safest biometric data is the data you never stored.

Match on device when you can. Platform features like Face ID and Android's BiometricPrompt keep templates on the phone; your server never sees them.
Store templates, not images, and only when strictly necessary.
Set a retention period and actually delete. "We might need it later" is not a reason.
Separate biometric data from the rest of the user record, with stricter access and audit logs.
Write it down in plain language in the flow itself, not only in the privacy policy.

Transparency is part of the interface

People trust what they understand. If your verification flow explains what's happening at each step ("Comparing your selfie with your ID photo… done. The selfie has been deleted."), it does more for trust than any badge in the footer.

And accountability starts inside the team. Someone should own the answers to: What do we collect? Where is it? Who can access it? When is it deleted? What happens when it fails? If nobody can answer, that's the first bug to fix.

The dilemma doesn't go away

Biometrics will keep spreading because they're convenient, and often because laws require identity checks. Security and privacy will keep pulling in opposite directions.

We won't resolve that tension from a pull request. But we decide, every day, whether consent is real, whether a failed match humiliates someone, whether there's another way in and how long a face lives in our database.

Your users can't change their faces. The least we can do is design as if that mattered.

This piece builds on an essay on facial recognition and digital human rights I wrote during my master's in Communication and Digital Humanities. It's part of my series on the human side of interfaces.

Have you built or used a biometric flow that got this right, or very wrong? Tell me in the comments.

References

Buolamwini, Joy, and Timnit Gebru. "Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification." Proceedings of Machine Learning Research, 2018.
García Canclini, Néstor. Ciudadanos reemplazados por algoritmos. Bielefeld University Press / CALAS, 2019.
Grother, Patrick, Mei Ngan, and Kayee Hanaoka. Face Recognition Vendor Test (FRVT) Part 3: Demographic Effects. NIST, 2019.

We're already cyborgs: assistive tech is the real transhumanism

Karen Molina — Mon, 09 Nov 2026 18:13:21 +0000

When people talk about transhumanism, they picture the future: brain implants, robotic limbs, uploading your mind to the cloud. Billionaires taking supplements to live to 150.

Meanwhile, right now, someone is reading this article with a screen reader at three times normal speed. Someone else is navigating with their eyes, or with a single switch, or by voice, while their hearing aids stream audio straight from their phone.

The cyborgs are already here. They're our users. And a lot of what we ship doesn't work for them.

Where "cyborg" came from

The word was coined in 1960 by Manfred Clynes and Nathan Kline, in a paper called "Cyborgs and Space." Their idea was practical, not science fiction: instead of building an Earth-like environment around astronauts, why not adapt the human body to survive in space with the help of technology? A cybernetic organism. A body extended by machines.

Twenty-five years later, Donna Haraway's A Cyborg Manifesto (1985) turned the figure into a critique: the line between human and machine, natural and artificial, was never as clean as we pretended. We were already mixed.

Transhumanism kept the dream of enhancement: technology as the next step of human evolution. As an anthropologist, what interests me is less the future body than the present one, and a question transhumanism tends to skip: who gets to be enhanced, and who gets left behind?

Assistive tech is body modification

Glasses, hearing aids and cochlear implants, wheelchairs, prosthetics, screen readers, voice control, eye tracking, switch access, live captions, magnifiers. All of these extend a body so it can do something it otherwise couldn't, or couldn't easily.

The WHO estimates that around 1.3 billion people, about one in six, live with a significant disability. Add aging, temporary injuries and situational limits (a broken arm, a loud room, bright sun), and "augmented user" stops being a niche. It's a large share of your audience at any given moment.

Here's the catch: an extension only works if the world is built to receive it. A screen reader is useless on a page made of unlabeled <div>s. Voice control can't press a button it can't name. The cyborg body is ready; the interface often isn't.

What breaks the extension

Most failures are boring and fixable:

<!-- A screen reader announces: "button." Which one? -->
<div class="btn" onclick="pay()">
  <svg>...</svg>
</div>

<!-- Now the extension can connect -->
<button type="button" onclick="pay()" aria-label="Pay $250">
  <svg aria-hidden="true">...</svg>
</button>

The most common ways we cut the connection:

No semantics. Clickable <div>s and <span>s instead of <button> and <a>. Assistive tech can't see them as controls.
No names. Icon-only buttons without aria-label. Voice control users can't say "click Pay" if nothing is called Pay.
Keyboard traps. Modals you can't leave without a mouse. Focus that disappears.
Timeouts. Sessions that expire while someone is slowly navigating by switch or by eye.
Motion and auto-play. Carousels and animations that ignore prefers-reduced-motion.
Captchas and gestures. "Drag the slider," "pinch to zoom," "tap the traffic lights." Each assumes a specific body.

Who gets to be a cyborg

Transhumanism has an inequality problem, and so does assistive tech. A high-end hearing aid or a modern power wheelchair is expensive. Eye-tracking setups cost a fortune. Many people rely on the free, built-in tools in their phone: VoiceOver, TalkBack, Voice Access, Live Caption, zoom.

That makes our job more important, not less. When the built-in extension is the only one someone can afford, an inaccessible app doesn't just inconvenience them. It shuts them out entirely.

The same thing happens on the hardware side. If your web app needs the latest phone to run smoothly, you've drawn an economic line around who can use it.

Designing for extended bodies

A few practices that treat assistive tech as a first-class user:

Use native elements first. A real <button>, <a>, <label> and <input> give you keyboard, focus and screen reader support for free.
Name everything. Every interactive element needs an accessible name a human would say out loud.
Test with the extensions themselves. Turn on VoiceOver or TalkBack for 15 minutes. Navigate your app with only a keyboard. Try Voice Control. It's humbling, and fast.
Never require one specific body. Every gesture needs a simple alternative: a button for every swipe, a code option for every biometric.
Give time. Warn before timeouts and let people extend them.
Respect user settings. Text size, contrast, reduced motion, captions. They're the body's preferences, sent to your interface.
Budget for low-end devices. Performance is accessibility for people who can't upgrade.

The future is already here

Clynes and Kline imagined cyborgs surviving in space. Haraway said we were cyborgs already. Transhumanists dream of the enhanced human of tomorrow.

I think the more interesting work is today's: making sure the bodies already extended by technology can actually connect to what we build.

The augmented human isn't a future user. It's the person trying to use your checkout right now.

This piece grew out of an essay I wrote during my master's on the body, transhumanism and culture. It's part of my series on the human side of interfaces, and a follow-up to "The body is the first interface."

Do you use any assistive tech yourself, or build with it in mind? I'd love to hear what breaks most often.

References

Clynes, Manfred E., and Nathan S. Kline. "Cyborgs and Space." Astronautics, 1960.
Haraway, Donna. "A Cyborg Manifesto." 1985.
World Health Organization. Global report on health equity for persons with disabilities. 2022.
W3C. Web Content Accessibility Guidelines (WCAG) 2.2.

Every dropdown is a classification system

Karen Molina — Mon, 09 Nov 2026 18:12:55 +0000

In Mexico, most people have two surnames: one from each parent. María Fernanda López Hernández is one person with one full name.

Now give her a form built somewhere else. "First name." "Last name." One field each, 20 characters max, letters only. She types "López Hernández," the accent breaks validation, the space gets trimmed, and somewhere downstream a bank, an airline or a government system now thinks she's a different person from the one on her ID.

Nobody meant to exclude her. Someone just wrote a schema.

Classifying is never just grouping

In 1903, Émile Durkheim and Marcel Mauss published a short study called Primitive Classification. Their argument was simple and uncomfortable: when people classify things, they don't just sort them into boxes. They arrange the boxes into a hierarchy. Some categories become central, others marginal. And that order doesn't come from nature; it comes from society.

Decades later, Mary Douglas took the idea further in Purity and Danger (1966). Every classification system produces leftovers: things that don't fit. She famously described dirt as "matter out of place." The anomaly isn't wrong in itself; it's wrong according to the system.

Now look at a form validation error. A red border, a message that says "Invalid name." The person is the anomaly. The system is the norm.

As engineers, we write classification systems all day. We just call them enum, required, maxLength and regex.

Five places we classify people without noticing

1. Names

The classic. Patrick McKenzie's 2010 post "Falsehoods Programmers Believe About Names" is still the best list, and still mostly ignored.

// Before: a Western, ASCII-only idea of a name
const nameSchema = z.object({
  firstName: z.string().regex(/^[A-Za-z]+$/).max(20),
  lastName: z.string().regex(/^[A-Za-z]+$/).max(20),
});

This rejects accents, ñ, apostrophes (O'Brien), hyphens, spaces, two surnames, non-Latin scripts and people with a single name.

// After: ask for what you need, accept what people are
const nameSchema = z.object({
  fullName: z.string().trim().min(1).max(200),
  preferredName: z.string().trim().max(100).optional(), // "What should we call you?"
});

If a legal process truly needs separate fields (KYC, travel), label them for the people you serve ("Apellido paterno," "Apellido materno") and make the second one optional.

2. Gender

<!-- Before -->
<select name="gender" required>
  <option>Male</option>
  <option>Female</option>
</select>

First question: do you need it at all? Most products don't. If you do, explain why, make it optional, and offer more than two options plus "Prefer not to say." If what you actually need is how to address someone, ask for pronouns or a title instead.

3. Addresses and phone numbers

"State" as a required dropdown of US states. A ZIP code regex with exactly five digits. A phone field that rejects the +52 prefix or spaces. Each one tells part of the world it isn't your user.

Use a free-text address line, a country selector that drives the rest of the form, and a library like libphonenumber instead of a homemade regex.

4. Enums for life

type MaritalStatus = 'single' | 'married' | 'divorced' | 'widowed';

That union type is a theory of which families exist. It leaves out common-law unions, which are widespread in Latin America, among others. If the business doesn't depend on the answer, don't ask. If it does, check the categories against the legal reality of each market you serve, not against the one you know.

5. Validation as a gatekeeper

Every validation rule is a small border. Some are necessary: an email needs an @. Many are just habits: minimum name length of 2 (there are people named "O" and "Ng"), no numbers in names, a birth date that must make you under 100.

A good question for code review: who does this rule reject, and is that on purpose?

What it costs

In payments and fintech, these aren't edge cases. A name that doesn't match an ID can fail identity verification. A rejected address blocks a delivery. People learn to lie to get through a form, and your data gets dirtier than if you had just accepted the truth.

And beyond the metrics, people notice. Being told by a computer that your own name is invalid is a small, repeated humiliation. Users rarely file a bug for it. They just leave.

A checklist for more humane data models

Ask only for what you need, and be able to say why for each field.
Prefer free text over enums when you're not sure the categories are complete.
Validate the minimum that the system truly requires.
Design for the countries you actually serve, starting with your own.
Test with real names: two surnames, accents, apostrophes, single names, non-Latin scripts.
Look at your "Other" bucket. Whoever lands there is who your classification forgot.
Let people correct their data without calling support.

Your schema is a theory of who counts

Durkheim and Mauss studied totems and clans. We write TypeScript. But the mechanism is the same: we draw categories, rank them, and treat whatever doesn't fit as an error.

A data model is a theory about who is a normal user of your product. You're going to write one either way. Better to write it on purpose.

This piece comes from my background in social anthropology and an essay I wrote during my master's on the body, culture and classification. It's part of my series on the human side of interfaces.

What's the strangest field validation that ever rejected you? Share it in the comments.

References

Durkheim, Émile, and Marcel Mauss. Primitive Classification. 1903.
Douglas, Mary. Purity and Danger. Routledge, 1966.
McKenzie, Patrick. "Falsehoods Programmers Believe About Names." 2010.
W3C Internationalization. "Personal names around the world."

The body is the first interface

Karen Molina — Mon, 09 Nov 2026 18:07:02 +0000

Picture someone in their seventies trying to unlock a banking app with their fingerprint. It used to work. Now it fails, again and again.

Nothing is wrong with the app. Nothing is wrong with the phone. Their skin changed. With age, fingerprints get drier and shallower, and the sensor stops recognizing them. So they type a password with one finger, slowly, while the app warns that this is "less secure."

The product was designed for a user. It just wasn't designed for a body.

Our personas don't have bodies

Most product teams I've worked with build personas the same way: a name, an age range, a job, a goal, a frustration, maybe a stock photo. "Laura, 34, marketing manager, wants to pay faster."

Laura has needs and motivations. What Laura doesn't have is hands, eyes, skin, fatigue, a commute, a cracked screen or a baby on one arm.

That's not an accident. Western thought spent centuries separating mind from body and putting the mind in charge, and software inherited the habit. We design for a rational user who perceives a screen, decides and clicks. The body is assumed, invisible and, conveniently, always in perfect condition.

But every interaction goes through the body first. Before anyone understands your UI, they have to see it, reach it, touch it and hold it steady. The body is the first interface. Our screens are the second.

Bodies change, and products don't notice

Philosophers like Merleau-Ponty argued that we don't have a body that perceives the world; we perceive the world through a body, and that body shapes what we can perceive. Marshall McLuhan, from a different angle, described media and interfaces as extensions of the body.

Put those together and you get an uncomfortable idea for product teams: if interfaces extend the body, they inherit its limits. And bodies are not stable.

They age. Fingerprints fade, near vision declines, fine motor control gets less precise.
They get tired. The same person taps less accurately at 11 p.m. than at 10 a.m.
They're situated. Direct sunlight, a bumpy bus, cold hands, gloves, one free hand.
They're temporarily or permanently different. A broken wrist, a tremor, low vision, color blindness.

When I built vehicle interface prototypes, this was impossible to ignore. A driver's finger never lands where you expect, because the car is moving and vibrating. Their eyes can only leave the road for a moment. The "user" is a body in motion before it is a mind making choices.

Interfaces are political, too

Here's the part we don't say out loud: when a product only works for one kind of body, someone chose that. Usually not on purpose. It happens through priorities, deadlines and a test group of colleagues who are all 25 to 40, sitting at a desk, with good eyesight and the latest phone.

Over time, users also adapt to us. They learn to squint, zoom, double-tap and retry, and we read their silence as satisfaction. The people who can't adapt, often older adults and people with disabilities, simply leave, and they rarely show up in the metrics as anything but churn.

Sensory ethnography: research that includes the body

Interviews and usability tests are good at capturing what people say and what they click. They're bad at capturing what their bodies go through.

Sensory ethnography, a method from anthropology (Sarah Pink's work is a good starting point), studies experience through the senses: how something feels in the hand, sounds in a noisy room, looks in the sun. In product terms, that means doing research with users in the places where they actually use your product, paying attention to posture, light, noise, movement and touch.

You don't need a research budget to start. Some things I now do or recommend:

1. Give personas a body and a context.
Add a line for each: "Uses the app with one hand while holding a child," "Reading glasses, often forgets them," "Opens the app on the bus, standing." It changes design discussions immediately.

2. Test in the wild, not at your desk.
Use your own product outside, at noon, at full brightness and at low battery. Use it walking. Use it with a cold hand, or a glove. You'll find bugs no linter will.

3. Always ship a fallback for biometrics.
Fingerprint and face unlock are great until they aren't. Make the fallback fast and respectful, not a punishment labelled "less secure."

4. Treat target size as a floor, not a goal.
WCAG 2.2 asks for at least 24 by 24 CSS pixels for targets at level AA, and 44 by 44 at level AAA. For anything used while moving, go bigger.

5. Respect the body's settings.
Font size, prefers-reduced-motion, prefers-contrast, dark mode: these are the body talking to your interface. Honor them by default.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

6. Watch, don't only ask.
When you do research, look at how people hold the phone, where their thumb rests, when they lean in or squint. The body tells you things users won't think to say.

Design for the body that will use it

Art can ask for effort. A painting can be difficult and still be worth it. Interfaces don't get that privilege: they have to work for people of every age, ability and circumstance, on their worst day, in their worst light.

That person in their seventies didn't get worse at banking. Their body changed, and the interface didn't change with it.

If we start treating the body as the first interface, that's a bug we can actually fix.

This piece grew out of an essay I wrote during my master's in Communication and Digital Humanities, mixing anthropology of the body with UX. It's part of my series on the human side of interfaces.

Where has your own body made a product fail you? Tell me in the comments.

References

Merleau-Ponty, Maurice. Phenomenology of Perception. 1945.
McLuhan, Marshall, and Eric McLuhan. Laws of Media: The New Science. University of Toronto Press, 1988.
Pink, Sarah. Doing Sensory Ethnography. SAGE, 2009.
Scolari, Carlos. Las leyes de la interfaz. Gedisa, 2018.
W3C. Web Content Accessibility Guidelines (WCAG) 2.2, Success Criteria 2.5.5 and 2.5.8.

Interfaces have agency: what an anthropology of art taught me about UI

Karen Molina — Mon, 09 Nov 2026 18:02:00 +0000

We like to say an interface is "just a layer." A thin skin over the real system, there to get out of the way.

I don't think that's true. Before I wrote code, I studied social anthropology, and one idea from that world changed how I look at every screen I build: objects act on people. Not metaphorically. They make us do things, feel things and assume things about whoever made them.

Interfaces are objects. So they act too.

Gell in two minutes

In Art and Agency (1998), the anthropologist Alfred Gell stopped asking "is this beautiful?" and started asking "what does this object do in a web of social relations?"

His answer: objects carry agency. Not because a shield or a carving has a mind, but because people treat it as an extension of someone's intention, and respond accordingly. A carved prow on a canoe was meant to dazzle and unsettle the people on the receiving end. It worked on them before anyone said a word.

Gell described four roles in that relationship:

Artist: whoever made the object
Index: the object itself, the thing you can see and touch
Prototype: what the object represents or refers to
Recipient: whoever encounters it

Any of them can be the agent (the one acting) or the patient (the one acted upon), and the roles keep switching.

The part that matters most for us is what Gell, borrowing from Peirce, called abduction: when people meet an object, they infer the intention behind it. We look at a thing and immediately guess what someone wanted from us.

Now map that onto a product team:

Gell	In software
Artist	Designers, engineers, PMs, the company
Index	The interface: a screen, a button, a dashboard, a car cluster
Prototype	The mental model it imitates: a physical knob, a paper form, a gas pump
Recipient	The user, who also acts back on it

Once I saw it this way, I couldn't unsee it.

Three interfaces, seen as objects with agency

1. The car cluster that competes with the road

For three years I built pre-prototyping tools for vehicle interfaces. A cluster is the clearest case of an interface with agency I know.

A warning light doesn't inform the driver. It demands something: a glance, a decision, sometimes fear. It pulls attention away from the road for a second or two, and that second is a design decision someone made.

The prototype matters too. The low-fuel icon is a gas pump that many younger drivers have never seen as a standalone object. It works because the cultural reference survived, not because it is self-evident. Change the culture, or the reference, and the icon stops acting the way you intended.

And the recipient acts back. Drivers learn which alerts they can ignore. Once they do, the interface has lost its agency, often for good. That's not a user error. That's the relationship working exactly as Gell would predict.

2. The payment button that tells you what it wants

Now I work on a QR payments network, where every screen sits between someone and their money.

Consider two buttons: "Pay now" and "Continue." Same function. Different agency. One is honest about the consequence; the other hides it behind a softer verb. Pre-select the installment option, make the full-payment option smaller, and you've designed a nudge.

This is where abduction bites. Users read intention into these choices immediately. They don't think "the button is blue." They think "this app wants me to take credit." Whatever you meant, the inference they make is the relationship. Trust is built or burned right there, in a label.

3. The activation flow that blames the user, or the brand

Imagine activating a new phone line on a cheap Android device, on a weak network, as someone who rarely fills out forms online. That's the reality for millions of people buying a prepaid SIM at the supermarket.

When a step times out, the screen doesn't say "the network is slow." It says "something went wrong, try again." The user doesn't infer a technical failure. They infer intent: they don't want people like me to make this work. Agency gets attributed to the brand, not to the infrastructure.

Same code, same bug. But the meaning of the bug depends entirely on who is on the other side of the screen.

What changes when you build with this in mind

I don't think you need to read Gell to ship good software. But thinking of interfaces as agents changed four habits for me.

1. I ask what the interface makes people do, not what it shows.
Before a PR, I try to name the action each screen pushes toward. If I can't name it, the screen probably pushes toward several things at once, and users will pick the wrong one.

2. I design for abduction.
People will infer an intention whether you give them one or not. So I make the right inference easy: verbs that say what will happen, honest defaults, error messages that say whose fault it is. "The network is slow, your data is saved" earns more trust than "Something went wrong."

3. I treat workarounds as data.
The recipient is also an agent. When people screenshot a QR instead of scanning it, tape over a warning light or keep a paper note next to an app, they're acting back on the interface. Those workarounds tell you where your object stopped working. I'd rather instrument them than ignore them.

4. I ask who is left out of the relationship.
Agency only works on people who can perceive the object. If the contrast fails in direct sunlight, or the flow assumes a fast phone and a full data plan, some recipients never enter the relationship at all. Accessibility isn't a checklist on top. It decides who the interface is allowed to act on.

The layer isn't thin

An interface is never neutral. It carries the intentions of the people who made it, imitates references from a specific culture, and gets read, bent and judged by the people who use it.

We can pretend it's "just a layer," or we can design the relationship on purpose.

This piece started as an essay on aesthetics and communication I wrote for my master's in Digital Humanities. It took me a while to notice I was describing my day job.

What's an interface you use every day that clearly "wants" something from you? I'd love to read your examples in the comments.

References

Gell, Alfred. Art and Agency: An Anthropological Theory. Oxford: Clarendon Press, 1998.

Frontend interview prep: 10 hoisting and scope exercises (with answers)

Karen Molina — Fri, 03 Dec 2021 00:28:16 +0000

Updated in 2026. The first version of this post, from 2021, said that let and const aren't hoisted. That's a very common misconception, and I believed it too. This rewrite fixes it and turns the post into exercises you can practice with.

In the variables, scope and hoisting post we covered the concepts. Now let's practice the way interviewers actually test them: "What does this code print?"

How to use this post: read each snippet, write down your answer, then open the solution. Run them in your browser console if you want to double-check. Every answer here was tested in Node.js.

Quick refresher

Declaration	Hoisted?	Before its line
`var`	Yes	`undefined`
`let` / `const`	Yes, but uninitialized	`ReferenceError` (temporal dead zone)
`function` declaration	Yes, completely	Callable
Function expression / arrow	Only the variable	Depends on `var`, `let` or `const`
`class`	Yes, but uninitialized	`ReferenceError`

And remember: the code doesn't move. Before running a scope, the engine registers its declarations. What differs is whether they're initialized.

Exercise 1: the warm-up

console.log(greeting);
var greeting = "Hi";
console.log(greeting);

Solution
undefined, then "Hi".

greeting is registered before the code runs and initialized as undefined. The assignment = "Hi" happens on line 2, so the first log sees undefined.

Exercise 2: let and const

console.log(first);
console.log(second);

let first = "I'm a let";
const second = "I'm a const";

Solution
Only one error: ReferenceError: Cannot access 'first' before initialization.

The second line never runs, because the first error stops execution. (In my original post I listed two errors. Only the first one ever appears.)

And the key point: first and second are hoisted. If they weren't, the error would be "first is not defined". "Cannot access before initialization" means the engine knows the variable exists, but it's still in the temporal dead zone.

Exercise 3: three kinds of functions

console.log(sum(2, 3));
function sum(a, b) {
  return a + b;
}

console.log(sum2(2, 3));
const sum2 = function (a, b) {
  return a + b;
};

Solution
5, then ReferenceError: Cannot access 'sum2' before initialization.

Function declarations are hoisted with their body, so you can call them early. sum2 is just a const variable that happens to hold a function, so it follows const rules. The same applies to arrow functions.

Exercise 4: same function, but with var

sayBye();
var sayBye = function () {
  console.log("Bye");
};

Solution
TypeError: sayBye is not a function.

Not a ReferenceError this time. With var, sayBye exists and equals undefined, and calling undefined() is a TypeError. Interviewers love this difference.

Exercise 5: the leaking block

if (true) {
  var leak = "var";
  let stay = "let";
}

console.log(leak);
console.log(stay);

Solution
"var", then ReferenceError: stay is not defined.

var ignores block scope; it belongs to the enclosing function (or the global scope). let only exists inside the { }.

Exercise 6: shadowing with var

var x = 1;

function test() {
  console.log(x);
  var x = 2;
}

test();

Solution
undefined.

Not 1! Inside test, there's a local var x, which is registered at the start of the function and initialized as undefined. It shadows the global x, so the log sees the local one before its assignment.

Exercise 7: shadowing with let

let x = 1;

{
  console.log(x);
  let x = 2;
}

Solution
ReferenceError: Cannot access 'x' before initialization.

You might expect 1 from the outer scope. But the inner block has its own let x, hoisted to the top of the block and stuck in the temporal dead zone. The inner x shadows the outer one from the very first line of the block.

This is the best proof that let is hoisted.

Exercise 8: no declaration inside

var a = 1;

function outer() {
  console.log(a);
  a = 2;
}

outer();
console.log(a);

Solution
1, then 2.

There's no var, let or const inside outer, so a refers to the outer variable through the scope chain. The function reads it and then reassigns it.

Exercise 9: same name, two declarations

console.log(typeof foo);

var foo = 1;
function foo() {}

console.log(typeof foo);

Solution
"function", then "number".

Both declarations are registered, and the function declaration wins during hoisting. Then the line foo = 1 runs and replaces it with a number. (Please never write this in real code.)

Exercise 10: typeof and the TDZ

console.log(typeof notDeclared);
console.log(typeof inTDZ);
let inTDZ = "hello";

Solution
"undefined", then ReferenceError: Cannot access 'inTDZ' before initialization.

typeof is usually "safe": on a variable that doesn't exist at all, it returns "undefined" instead of throwing. But a variable in the temporal dead zone is different. It exists, it's just not initialized, and typeof can't save you.

Bonus round

Two quick ones that show up in more advanced interviews:

new User();
class User {}

function greet(a = b, b = "hi") {
  return a;
}
greet();

Solutions
Both throw a ReferenceError.

Classes are hoisted like let: they're in the temporal dead zone until their declaration.
Default parameters are evaluated left to right, each in its own scope. When a tries to read b, b hasn't been initialized yet.

How did you do?

10 to 12: you're ready for this part of the interview.
6 to 9: review the temporal dead zone and shadowing (exercises 6, 7 and 10).
Under 6: go back to the concepts post and try again in a couple of days.

Which one got you? Mine was exercise 6 for a long time. Tell me yours in the comments 👇

Frontend interview prep: asynchronous JavaScript, the event loop, promises and async/await

Karen Molina — Thu, 28 Oct 2021 02:40:45 +0000

Updated in 2026. I wrote the first version of this post in 2021. I've rewritten it with a corrected callback example, the event loop (the part I was missing back then) and model answers for interviews.

Asynchronous JavaScript is where interviews stop being about definitions and start being about how the language actually runs. Let's build it up from the beginning.

Why JavaScript needs async code

JavaScript runs on a single thread: it executes one piece of code at a time, on one call stack.

That's a problem when something takes time, like a network request, a timer or reading a file. If JavaScript simply waited, the whole page would freeze: no clicks, no scrolling, no animations.

So instead of waiting, JavaScript hands slow work to the environment (the browser or Node.js), keeps running other code, and comes back to the result later. That's asynchronous programming.

The event loop

This is the part that makes everything else make sense, and the part I didn't understand when I first wrote this post.

There are four pieces:

Call stack: where your code runs, one function at a time.
Web APIs (or Node APIs): where timers, network requests and events wait, outside the stack.
Task queue (macrotasks): callbacks from setTimeout, setInterval, DOM events.
Microtask queue: callbacks from promises (.then, await) and queueMicrotask.

The event loop follows one rule: when the call stack is empty, run all microtasks, then one task, and repeat.

The classic interview question

What does this print?

console.log("1");

setTimeout(() => console.log("2"), 0);

Promise.resolve().then(() => console.log("3"));

console.log("4");

Answer: 1, 4, 3, 2.

1 and 4 are synchronous, so they run first.
The promise callback goes to the microtask queue.
The setTimeout callback goes to the task queue, even with a delay of 0.
When the stack is empty, microtasks run first (3), then the next task (2).

If you can explain this step by step, you've answered half of the async questions you'll get.

Callbacks

A callback is a function passed to another function, to be called later.

In my original post, the example was wrong: I passed the result of a function, not the function itself. Here's a real callback:

function greet(name, callback) {
  const message = `Hello ${name}`;
  callback(message);
}

greet("Karen", (message) => console.log(message)); // "Hello Karen"

And a real asynchronous one:

console.log("Before");

setTimeout(() => {
  console.log("Inside the callback");
}, 1000);

console.log("After");
// Before, After, Inside the callback

The problem: callback hell

When async steps depend on each other, callbacks nest:

getUser(id, (user) => {
  getOrders(user.id, (orders) => {
    getInvoice(orders[0].id, (invoice) => {
      sendEmail(invoice, (result) => {
        // ...and error handling at every level
      });
    });
  });
});

Hard to read, hard to handle errors, hard to change. Promises were created to fix that.

Promises

A promise is an object that represents a value that will be available in the future, or an error explaining why it isn't.

It has a state:

State	Meaning
`pending`	Still waiting
`fulfilled`	Finished successfully, has a value
`rejected`	Failed, has a reason (usually an `Error`)

Once a promise is fulfilled or rejected, it's settled, and it never changes again. That's why in this example the reject is ignored:

const promise = new Promise((resolve, reject) => {
  resolve("done");
  reject(new Error("ignored")); // the promise is already settled
});

Creating a promise

function wait(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

Consuming a promise

fetch("/api/user")
  .then((response) => response.json())
  .then((user) => console.log(user.name))
  .catch((error) => console.error("Something failed:", error))
  .finally(() => console.log("Done, success or not"));

Each .then returns a new promise, so you can chain steps instead of nesting them. One .catch at the end handles errors from any step.

Running promises together

This is where interviews often go next:

Method	Resolves when	Rejects when
`Promise.all`	All succeed	Any one fails
`Promise.allSettled`	All finish, success or not	Never
`Promise.race`	The first one settles	The first one settles with an error
`Promise.any`	The first one succeeds	All fail

async/await

async/await is syntax on top of promises that lets async code read like sync code.

async makes a function always return a promise.
await pauses that function until a promise settles, without blocking the main thread.

async function showUser(id) {
  try {
    const response = await fetch(`/api/users/${id}`);
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const user = await response.json();
    console.log(`Hello ${user.name}`);
  } catch (error) {
    console.error("Could not load user:", error);
  }
}

Errors are handled with plain try/catch.

The mistake that shows seniority: sequential vs. parallel

// Sequential: the second request waits for the first. Slow.
const user = await getUser(id);
const settings = await getSettings(id);

// Parallel: both start at once. Faster when they don't depend on each other.
const [user, settings] = await Promise.all([getUser(id), getSettings(id)]);

Pointing this out in an interview, or in code review, shows you think about performance, not just correctness.

Interview answers

"What's the event loop?"
"JavaScript runs on a single thread with one call stack. Async work like timers and network requests is handled by the environment, and their callbacks are queued. When the stack is empty, the event loop runs all pending microtasks, like promise callbacks, and then the next task, like a setTimeout callback. That's why a resolved promise runs before a setTimeout with zero delay."

"Callbacks vs. promises vs. async/await?"
"Callbacks are functions passed to run later; they get hard to manage when nested. Promises represent a future value with a state, can be chained, and centralize error handling. async/await is syntax on top of promises that makes async code read top to bottom, with try/catch for errors."

Quick checklist

[ ] Can you explain why JavaScript needs async code if it's single-threaded?
[ ] Can you draw the call stack, the task queue and the microtask queue?
[ ] Can you predict the output of console.log, setTimeout and Promise.then together?
[ ] Can you name the three states of a promise?
[ ] Do you know the difference between Promise.all and Promise.allSettled?
[ ] Can you turn two sequential awaits into parallel ones?

Previous in the series: functions and closures.

What async bug has cost you the most hours? Tell me in the comments 👇

Frontend interview prep: functions and closures in JavaScript

Karen Molina — Thu, 23 Sep 2021 04:53:02 +0000

Updated in 2026. I wrote the first version of this post in 2021 while preparing for interviews. I've rewritten it with clearer explanations, a fixed closure example (the original one had a bug!) and model answers.

If there's one JavaScript topic that appears in almost every frontend interview, it's closures. And you can't really understand closures without understanding functions first. So let's start there.

Functions are values

A function is a reusable block of code that performs a task. In JavaScript, functions are also first-class objects: you can store them in variables, pass them as arguments, return them from other functions and even add properties to them.

That single idea is what makes callbacks, event handlers, React components and closures possible.

There are several ways to create a function, and the differences matter in interviews.

Function declaration

The classic form: the function keyword, a name, parameters and a body.

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

sum(2, 4); // 6

Function declarations are fully hoisted, so you can call them before the line where they're written.

Function expression

A function created as part of an expression, usually assigned to a variable.

const sum = function (a, b) {
  return a + b;
};

sum(2, 4); // 6

It looks almost the same, but there's a key difference: only the variable is hoisted, not the function. Calling it before that line fails.

greet();      // works: declaration
sayBye();     // ReferenceError (const) or TypeError (var)

function greet() { console.log("hi"); }
const sayBye = function () { console.log("bye"); };

Arrow functions

Introduced in ES6 (2015). Shorter syntax, and if the body is a single expression, it's returned automatically.

const sum = (a, b) => a + b;

sum(2, 4); // 6

// To return an object literal, wrap it in parentheses
const makeUser = (name) => ({ name });

But arrow functions aren't just shorter syntax. They behave differently:

No own this. They use the this of the surrounding code. Great for callbacks, bad for object methods.
No arguments object. Use rest parameters (...args) instead.
Can't be used with new. new (() => {}) throws TypeError: ... is not a constructor.

const timer = {
  seconds: 0,
  start() {
    setInterval(() => {
      this.seconds++; // `this` is still `timer`, thanks to the arrow function
    }, 1000);
  },
};

With a regular function inside setInterval, this would no longer point to timer. That's a very common interview follow-up.

IIFE (Immediately Invoked Function Expression)

A function that runs as soon as it's defined.

(function () {
  const secret = "only visible in here";
  console.log("Hello world");
})();

Before ES modules and let/const, IIFEs were the main way to create a private scope and avoid polluting the global one. You'll still see them in older code and in interview questions.

Constructor functions and classes

A constructor function creates objects when called with new.

function User(first, last) {
  this.firstName = first;
  this.lastName = last;
}

const user = new User("Jon", "Snow");
// { firstName: "Jon", lastName: "Snow" }

When you use new, JavaScript:

creates a new empty object,
links it to the constructor's prototype,
runs the function with this pointing to that object,
returns the object (unless the function explicitly returns another object).

Today you'll usually write the same thing with class, which is mostly syntax on top of the same mechanism:

class User {
  constructor(first, last) {
    this.firstName = first;
    this.lastName = last;
  }
}

Interview answer: "Functions in JavaScript are first-class objects. Function declarations are fully hoisted; function expressions aren't. Arrow functions are shorter and don't have their own this or arguments, and they can't be used as constructors. Constructor functions and classes create objects with new, which sets this to a new object linked to the prototype."

Closures

The definition

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

Every function in JavaScript forms a closure. It's not a special syntax; it's a consequence of functions being values and of the scope chain.

The example

In the first version of this post, my example had a bug: I called the outer function and expected it to print. Here's the corrected version:

function sayHi() {
  const greeting = "Hola";

  function inner() {
    console.log(greeting);
  }

  return inner;
}

const hi = sayHi(); // sayHi has finished running...
hi();               // ...but inner still remembers `greeting`: "Hola"

sayHi has already returned, so in theory greeting should be gone. But inner keeps a reference to the scope where it was created, so greeting stays alive as long as inner exists.

Why it's useful: private state

Closures let you create data that can't be accessed from the outside.

function createCounter() {
  let count = 0;

  return {
    increment() {
      count++;
      return count;
    },
    get() {
      return count;
    },
  };
}

const counter = createCounter();
counter.increment();
counter.increment();

counter.get();  // 2
counter.count;  // undefined: there's no way to touch `count` directly

The classic interview question

You'll probably see this one:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}
// 3, 3, 3

Why 3, 3, 3 and not 0, 1, 2? Because var is function-scoped, there's only one i. All three callbacks close over the same variable, and by the time they run, the loop has finished and i is 3.

The fix is let, which creates a new binding for each iteration:

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i));
}
// 0, 1, 2

Closures in real life: React

If you use React, you're using closures every day. Every render creates new functions that close over that render's props and state. That's the root of the famous "stale closure" bug:

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setCount(count + 1); // always sees the `count` from the first render
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <p>{count}</p>; // gets stuck at 1
}

The interval callback closed over count = 0 and never sees updates. The fix is the functional update, which doesn't depend on the closed-over value:

setCount((c) => c + 1);

Mentioning this in an interview shows you understand closures beyond the textbook definition.

Interview answer: "A closure is a function that keeps access to the variables of the scope where it was created, even after that scope has finished. It's used for private state, factories, callbacks and memoization. A classic example is the var loop with setTimeout printing the same value three times, which let fixes because it creates a new binding per iteration. In React, stale closures in effects are a common bug caused by the same mechanism."

Quick checklist

[ ] Can you explain why functions are "first-class objects"?
[ ] Do you know which function forms are hoisted and which aren't?
[ ] Can you name three differences between arrow functions and regular functions?
[ ] Can you explain what new does, step by step?
[ ] Can you define a closure in one sentence and give an example?
[ ] Can you explain the var + setTimeout loop output?

Previous in the series: variables, data types, scope and hoisting.
Next: asynchronous JavaScript: callbacks, promises and async/await.

What was your "aha" moment with closures? Tell me in the comments 👇