“How do you document your work?”
Responde con dos niveles y artefactos concretos. Día a día: la descripción del PR lleva el porqué — qué problema resuelve y qué descartaste — porque es lo que alguien leerá seis meses después. Para lo grande: un design doc corto antes de empezar, actualizado cuando la realidad no coincide. Y una regla honesta: no escribir documentación que nadie lee.
Two levels. Day to day, the PR description carries the why — what problem it solves and what I ruled out — because that's what someone reads six months later. For anything bigger, I write a short design doc before I start and update it when reality disagrees with it. I try not to write docs nobody reads: if a README goes stale twice, that's a sign it should've been a test or a script.
Nivel B1-B2: pensada para que la adaptes a tu experiencia, no para memorizarla palabra por palabra. Cambia el stack, los años y el contexto por los tuyos.
En un equipo distribuido, tu documentación es tu presencia cuando no estás conectado. Esta pregunta no va de ser ordenado: va de si el equipo puede avanzar sin ti a las tres de la mañana de su huso horario. El filtro oculto es el inglés escrito en su versión más exigente, que es dejar clara una decisión técnica en tu segundo idioma. Alguien que resuelve cualquier cosa pero deja PRs con “fix bug” genera trabajo para los demás, y en remoto eso se paga caro y se detecta rápido.
En resumen: Documentar en remoto es parte del trabajo, no un extra. Nombra artefactos concretos: PR description, design doc, ADR, runbook. Y “documentación” es “documentation”, incontable — “documentations” no existe.
Esta pregunta se responde en voz alta y bajo presión. En DevLingo la ensayas con un tutor IA que hace de entrevistador y te corrige la frase concreta que dijiste mal, no un listado genérico de errores.
Ensayar esta pregunta gratisTodas las preguntas de entrevista·Glosario de inglés técnico