Apéndice J — J. Preguntas de entrevista: AI en el trabajo y conductual
Las que más crecieron en entrevistas fullstack — y las que este libro entrena sin que lo notes
Repaso activo: responde en voz alta antes de desplegar. Las preguntas de AI no son trivia aparte — cada “Prompt listo para tu AI” del libro fue una lección de prompt engineering. Aquí se convierte en respuesta de entrevista.
J.1 AI y prompt engineering
R: “Diseñar la entrada que guía al modelo a salidas confiables: contexto, objetivo, restricciones, formato, criterios de aceptación. Importa porque el dev de hoy dirige código más que lo escribe de memoria — la diferencia entre ‘hazme un endpoint’ y un prompt con stack, archivos, edge cases y buenas prácticas es la diferencia entre código que hay que rehacer y código que hay que revisar.” → todos los “Prompt listo” del libro
R: “Zero-shot: la instrucción sola — alcanza para tareas comunes. Few-shot: instrucción + ejemplos de entrada/salida — cuando el formato importa (quiero que devuelvas este JSON). Chain-of-thought: ‘piensa paso a paso’ — mejora razonamiento multi-paso, y en la práctica lo pides implícito al pedir ‘explícame tu razonamiento antes del código’.”
R: “Retrieval-Augmented Generation: antes de responder, se buscan los documentos relevantes y se inyectan al prompt como contexto. Mejor que meterlo todo cuando el conocimiento es grande, cambia, o es privado — el modelo responde anclado en datos reales en vez de alucinar. En términos de este libro: es ‘SELECT relevante + prompt’, no ’SELECT *’ en cada request.”
R: “Prompt primero, siempre: es barato, iterativo y resuelve el 80% — formato, tono, restricciones, ejemplos. Fine-tuning cuando el prompt no basta a escala: comportamiento consistente que necesitas en millones de llamadas, o un dominio tan específico que los ejemplos no caben en contexto. La pregunta de control: ¿puedo resolverlo con un mejor prompt? Si sí, no entreno nada.”
R: “Las fronteras que no dependen del modelo: validar la salida (schema — el mismo concepto del cap. 4), filtrar lo que no debe decir, límites de acción (el agente propone, tú apruebas — como los AI CLIs del cap. 0.5), y fallback cuando falla. Un LLM sin guardrails en prod es un handler sin validación: funciona en el demo, falla en el mundo.”
R: “Respuesta honesta: los CLIs de AI son herramientas de la terminal — les doy contexto (archivos, stack, contrato), pido con requisitos y criterios de aceptación (los prompts de cada capítulo son mi plantilla), reviso el diff como si fuera un PR de un junior, y nunca les paso secretos. Lo que me hace útil no es tener la AI — es saber verificar lo que produce. Por eso aprendí los fundamentos.” → cap-terminal
R: “Igual que código de cualquier fuente: ¿compila/pasa tests? ¿la query está parametrizada? ¿el endpoint valida entrada? ¿los errores van al mapper? ¿el índice existe? La AI produce borradores rápidos; mi checklist de seguridad/errores/performance del libro es el filtro. La señal de junior es aceptar sin revisar; la señal de senior es saber exactamente qué revisar.”
R: “Definir el problema y el contrato de salida → elegir modelo (costo/latencia/calidad) → estrategia de prompting (system prompt + few-shot) → guardrails y validación de salida → evaluación con casos reales → despliegue con los mismos problemas de siempre: costos, latencia, observabilidad, rate limits del proveedor. Un LLM en prod es una integración externa más — con timeouts, retries y presupuesto.” → cap-19
J.2 Conductual y proyecto
R: “Tu respuesta es Nexus — practícala con STAR corto: Situación: workspace colaborativo tipo Figma-lite. Tarea: backend completo solo. Acción: diseñé el ER, contrato OpenAPI primero, capas, versionado tipo git interno con snapshot+puntero, auth híbrida con rotación, WebSockets para presencia, auditoría completa antes de publicar. Resultado: API deployada con X endpoints, tests, migraciones, docs. Y lo clave: puedo defender CADA decisión — por qué Postgres, por qué LWW, por qué híbrido de sesiones.” → caps. 36–39
R: “STAR con uno real del libro: ‘Un endpoint devolvía datos de otros usuarios’ — S: lista de tareas filtraba mal. T: encontrar la fuga. A: el test del endpoint pasaba porque devolvía 200 — el bug era de autorización, no de status; el WHERE no incluía user_id. R: fix en la query (no en el if), test nuevo que verifica de quién son los datos, y auditoría de los demás endpoints — el patrón se repite.” → cap-17
R: “Honesta y concreta: ‘Construyo — leer changelogs no pega como implementar. Cuando algo nuevo aparece lo comparo con lo que ya sé (Fastify vs Express fue un sub-tab, no un mundo nuevo). Uso las herramientas de AI para explorar rápido pero verifico con la doc oficial. Y mantengo este libro vivo: cada concepto nuevo intenta ganarse un lugar en una sección.’”
R: “La respuesta que más impresiona es honesta: ‘Eso no lo he hecho en prod, pero te digo cómo lo atacaría’ + el razonamiento en voz alta. El entrevistador evalúa cómo piensas, no tu memoria — ‘no sé’ seguido de ‘pero por analogía con X haría Y’ vale más que inventar. Memorizar no es el objetivo de este libro; reconocer patrones sí — y eso se defiende solo en la entrevista.”
- Repaso espaciado: una sección por día, voz alta, antes de desplegar. Si no la respondes, la marcas y vuelves mañana.
- Las preguntas cambian, los fundamentos no: cada respuesta modelo apunta a un capítulo — si una te cuesta, ahí está tu lectura.
- Tu AI CLI es tu entrevistador de práctica: pégale cualquier pregunta de arriba y pídele que te evalúe.
J.3 Vocabulario técnico del capítulo
Un array es una colección ordenada de elementos accedidos por posición: ["a","b","c"][0] es "a" (se cuenta desde 0). Python las llama listas, Go slices — misma idea, distinto acento.
Un bucle repite una acción por cada elemento o hasta cumplir una condición: for task in tasks hace algo con cada tarea. map y filter son bucles disfrazados de funciones — transforman/filtran colecciones sin for explícito.
Una sesión es la conversación continuada entre tú y el servidor: HTTP no recuerda nada entre requests, así que la sesión (vía cookie o token) es el “pulso de mano” que te identifica en cada llamada.
Un secreto es un dato que no puede publicarse: contraseñas de BD, llaves de API, el secreto que firma los JWT. Viven en .env (fuera de git) o en un secret manager — nunca en el código ni en el repo.
Un deploy es poner tu código a correr en el servidor: copiar la imagen, iniciar el proceso, verificar que responde. El objetivo es que sea aburrido — automático, repetible, con rollback.
Un dominio es el nombre que compras (midominio.com) y apuntas a tu servidor por DNS. Sin él, tus usuarios tendrían que memorizar una IP. El HTTPS serio requiere dominio.
WebSocket es una conexión que queda viva: en vez de preguntar- responder-cerrar como HTTP, ambos pueden hablar cuando quieran. Es como el servidor puede empujar — por eso sirve para chat y colaboración en vivo.
Latencia = cuánto tarda UNA operación (ms). Throughput = cuántas haces por segundo. Se pelean: bajar latencia no siempre sube throughput. La latencia la siente el usuario; el throughput lo paga tu factura.
Vertical: máquina más gorda (más CPU/RAM) — fácil, tiene techo. Horizontal: más máquinas — el camino de internet, pero requiere que la app no guarde estado local (por eso todo va a BD/Redis).
Producción (prod) es el entorno real: donde están los usuarios, los datos que importan y las consecuencias. Todo lo demás — local, staging — existe para que los errores ocurran antes de llegar ahí.
Un compilador traduce código a otra forma: TypeScript → JavaScript (transpila), Go → binario (compila). Atrapa errores antes de ejecutar. tsc, esbuild, go build son compiladores.
La terminal (consola, línea de comandos) es la interfaz de texto con el sistema operativo: escribes comandos, lees resultados. Es como hablarle a la computadora por cartas en vez de señalar con el mouse.
Un CLI (Command Line Interface) es un programa que se usa escribiendo comandos en la terminal: git, npm, docker son CLIs. Lo contrario es una GUI (interfaz gráfica con botones).
La memoria RAM es el escritorio de trabajo del programa: rápida, pero se borra al apagar. Los datos que deben sobrevivir van a disco o a la base de datos. Por eso let tasks = [] pierde todo al reiniciar.
Una query es la pregunta que le haces a la base de datos en SQL: SELECT * FROM tasks WHERE done = false. La BD traduce la pregunta a un plan de búsqueda — por eso los índices importan.
El esquema es el plano de la base de datos: qué tablas hay, qué columnas tiene cada una y de qué tipo. Es contrato: una fila que no cumple el esquema no entra. Se cambia con migraciones, no a mano.
Un índice es la tabla de contenido de una tabla: sin él, buscar un usuario es leer las 10 millones de filas (seq scan); con él, es ir directo a la página. Se crea según cómo se consulta, y cada uno cuesta escrituras.
Una migración es un cambio versionado del esquema: un archivo que dice “crea esta columna” (up) y “bórrala” (down). Son el historial Git de la estructura de la BD — se aplican en orden y no se editan una vez aplicadas.
La autenticación responde “¿quién eres?” — login, contraseña, token. Se confunde con autorización (“¿qué puedes hacer?”), que es la pregunta siguiente. Primero te identificas, luego te dejan o no pasar.
La autorización responde “¿qué puedes hacer?”: eres usuario válido (autenticado), pero ¿puedes borrar esta tarea? Se decide por rol o por ownership — y se verifica en cada request, no se recuerda.
EXTRA Más allá del código, las guías externas coinciden en lo no-técnico —
- Resolver problemas y comunicación: el trabajo no termina en código correcto; hay que explicar soluciones al equipo y a otros departamentos
- Portafolio: perfil de GitHub activo + proyectos de código abierto
- Networking: LinkedIn, meetups, conferencias — “la conexión correcta puede ser la diferencia entre quedarte y conseguir el trabajo soñado”
- Voluntariado/open source: experiencia real visible para empleadores mientras no tienes empleo
- Recursos de aprendizaje: freeCodeCamp (introducción gratuita), Khan Academy (fundamentos), MDN Web Docs (tutoriales por nivel), libros como JavaScript Professional (Zakas) y cursos prácticos de Node.js (Andrew Mead)
El hilo que los une: aprendizaje basado en proyectos — construir cosas reales retiene más que la teoría sola. Es literalmente el diseño de este libro.