Presentamos Codeflow: nuestro entorno de entrevista de código abierto

Codeflow, el entorno de desarrollo local que utilizamos para las entrevistas de ingeniería en Webflow, ya está disponible en Github. Sustituye las plataformas de programación basadas en navegador por algo más parecido a cómo trabajan realmente los ingenieros: tu máquina, tu IDE, tus herramientas.

Por qué lo creamos

Los editores de entrevistas basados en navegador introducen ruido que no tiene nada que ver con la capacidad de ingeniería. Atajos de teclado desconocidos, latencia, sin acceso a tu terminal o extensiones. Los candidatos gastan energía mental luchando contra la herramienta en lugar de resolver el problema. Queríamos eliminar esa variable por completo.

También queríamos entrevistas donde el uso de la IA fuera visible y evaluable. Cuando los candidatos trabajan localmente compartiendo pantalla, vemos el flujo de trabajo completo: cómo cambian de contexto entre el código, la terminal y una IA, cómo formulan las instrucciones, cómo integran o descartan los resultados. Eso es una señal mucho más rica que un simple "¿dieron con la respuesta correcta?" y hace que nuestras entrevistas se ajusten a la forma en que nuestros ingenieros pasan sus días realmente.

Cómo funciona

Codeflow es un shell de React. Clona el repositorio, instala las dependencias y ejecuta el servidor de desarrollo.

git clone https://github.com/webflow/codeflow.git
cd codeflow
npm install
npm start

Codeflow en sí no contiene código fuente específico de la entrevista. Al comenzar, el candidato recibe un archivo zip, lo coloca en src/interviews/ y el ejercicio se carga en la aplicación en ejecución.

A partir de ahí, el candidato trabaja en una base de código real. Múltiples archivos. Funcionalidades existentes. Jerarquías de componentes, gestión de estado y asperezas intencionadas. El tipo de cosas con las que te encontrarías en tu primera semana en cualquier empresa de producto que trabaje a gran escala.

Diseñar ejercicios que reflejen el trabajo real

El shell es intencionalmente genérico. Los ejercicios de entrevista que conectas a él son donde reside el pensamiento de diseño, y creemos que la estructura de un ejercicio importa más que el problema específico que se plantea.

Las preguntas de entrevista tradicionales tienden a aislar habilidades: implementar una estructura de datos, resolver un algoritmo restringido. Estas pueden ser útiles en contextos limitados, pero no reflejan cómo se presenta realmente el trabajo de ingeniería, especialmente en un entorno donde la IA puede encargarse de gran parte de la ejecución mecánica.

Algunos principios guían nuestra forma de pensar sobre el diseño de ejercicios:

Empieza con un sistema existente, no con una hoja en blanco

La mayor parte del trabajo de ingeniería no es desde cero. Implica entender código que ya existe, averiguar dónde falla y hacer cambios sin introducir nuevos problemas. Los ejercicios deberían reflejar eso: múltiples archivos, patrones establecidos y algunas asperezas intencionadas.

Superpon problemas en lugar de aislarlos

El trabajo se acumula. Arreglar un problema a menudo revela otro. Añadir una funcionalidad puede introducir complejidad en el rendimiento o en el estado. Los ejercicios que se construyen por capas, entendiendo, extendiendo y refinando, hacen que sea más fácil ver cómo las decisiones de un candidato tienen repercusiones.

Evalúa a través de diferentes dimensiones de la ingeniería

Una buena ingeniería no es solo corrección. Implica equilibrar compensaciones, pensar en el usuario y anticipar casos extremos. Diseñamos ejercicios que ponen de manifiesto:

• Fundamentos básicos (¿funciona y por qué?)
• Pensamiento de producto y UX (¿se comporta bien bajo un uso real?)
• Instinto de diseño de sistemas (¿cómo escala o se rompe esto?)

Haz visible el uso de herramientas

En la práctica, los ingenieros trabajan con herramientas, incluida la IA. En lugar de restringirlo, los ejercicios pueden estructurarse para que el uso sea observable. Trabajar en un entorno local con pantalla compartida nos permite ver cómo se crean los prompts, cómo se evalúan los resultados y cómo se integran o descartan las sugerencias. Esa interacción suele revelar más que el resultado en sí.

Elimina la fricción innecesaria

Los editores desconocidos, la falta de herramientas o las restricciones artificiales generan ruido. Si algo no nos dice nada sobre cómo piensa un candidato, no debería estar en la entrevista. Permitir que los candidatos usen su propia configuración produce un trabajo más representativo.

Los ejercicios específicos que realizamos en Webflow siguen estos patrones (tareas por capas, restricciones del mundo real y caminos abiertos), pero la estructura subyacente es lo que más importa. Independientemente de los problemas que diseñes para tu equipo, estos principios deberían mantenerse.

La IA es parte del flujo de trabajo

No restringimos las herramientas. Copilot, Claude, ChatGPT, grep a través de la documentación o lo que sea que usarías en el trabajo. La entrevista es con pantalla compartida, así que vemos todo en tiempo real. De eso se trata.

Lo que evaluamos es la brecha entre lo que te da el modelo y lo que tú entregas.

Un candidato que depura un componente que se vuelve a renderizar en cada actualización de estado del padre no pega el archivo en una ventana de chat para pedirle que lo "optimice". Aísla el problema y luego hace una pregunta específica: comparar el uso de useMemo en el valor derivado frente a elevar el estado a un contexto compartido, dadas las actualizaciones frecuentes del padre y el flujo de datos existente de la aplicación. Lee la respuesta de forma crítica, toma una parte, descarta otra y la combina con lo que ya sabe sobre el código base. Cuando preguntamos por qué eligió ese camino, puede explicarlo sin mirar el historial del chat.

Prompts vagos, pegar sugerencias sin leerlas, incapacidad para explicar qué cambió. Ahí es donde la IA se convierte en una muleta en lugar de un multiplicador, y es evidente casi de inmediato.

Lo que estamos evaluando

Los problemas clásicos de entrevista tuvieron su momento, pero se han convertido en una prueba de preparación más que de ingeniería. Y con la IA de por medio, prueban aún menos. Necesitábamos entrevistas que seleccionaran el trabajo real: navegar por un código base a gran escala, depurar problemas de rendimiento en capas de renderizado, refactorizar sistemas bajo restricciones reales y equilibrar la velocidad con la sostenibilidad.

Con la antigüedad, el listón cambia. En niveles más senior, esperamos que los candidatos hagan preguntas aclaratorias antes de escribir código, identifiquen riesgos que el ejercicio no detalla y tomen decisiones arquitectónicas que tengan en cuenta restricciones más allá de la tarea inmediata.

Por qué lo hacemos de código abierto

Todos los equipos de ingeniería con los que hablamos están trabajando en una pregunta similar: ¿cómo haces una entrevista para un puesto donde la IA es parte del kit de herramientas? La mayoría todavía lo está resolviendo. Hemos estado usando Codeflow en entrevistas reales durante un tiempo y ha cambiado la señal que podemos obtener de los candidatos. Queríamos compartir lo que funciona.

Codeflow está en GitHub. Úsalo, haz un fork, toma las partes que te sean útiles. El shell es deliberadamente minimalista para que puedas conectar los ejercicios que tengan sentido para tu stack y tu equipo. Si estás usando Codeflow o construyendo algo similar, nos encantaría saber cómo has diseñado tu proceso. Cuantos más equipos compartan lo que funciona, más rápido llegaremos todos a entrevistas que realmente midan lo que importa.

Y si eres un ingeniero que ya trabaja de esta manera, estamos contratando.‍ → Codeflow en GitHub → Puestos abiertos en Webflow

‍