Cómo mejorar entrevistas técnicas siendo junior

Tenés el CV listo, aplicaste a 15 posiciones y finalmente te llaman para una entrevista técnica. El problema es que nunca pasaste por una. No sabés si te van a hacer programar en vivo, si te van a preguntar teoría o si simplemente te van a destrozar con preguntas sobre arquitectura. La buena noticia: una entrevista técnica se prepara como cualquier habilidad. Con un plan de 30 días podés pasar de sudar frío a responder con confianza.

Esto no es sobre memorizar 500 preguntas de LeetCode. Es sobre entender qué buscan en un junior, cómo estructurar tus respuestas y qué anti-patrones te delatan como alguien que estudió pero nunca enfrentó código real.

Semana 1-2: Estructurar respuestas técnicas sin sonar genérico

El error más común de un junior es responder con definiciones de Wikipedia. Te preguntan "¿Qué es una API REST?" y contestás: "Es una interfaz de programación de aplicaciones que usa HTTP y es stateless...". Técnicamente correcto. Completamente olvidable.

Lo que funciona es el formato CAR: Concepto, Aplicación, Resultado.

Ejemplo real:

Pregunta: ¿Qué es una API REST?

Respuesta débil (solo concepto): "Es una arquitectura que usa HTTP para comunicar cliente y servidor, siguiendo los principios de stateless y recursos identificables."

Respuesta fuerte (CAR): "Es una forma de estructurar APIs donde cada recurso tiene una URL única y usás métodos HTTP para operaciones. En mi proyecto de e-commerce armé endpoints como GET /products para listar productos y POST /orders para crear órdenes. Lo que me ayudó fue mantener los endpoints predecibles: si tenía /users/:id, sabía que DELETE /users/:id debía eliminar. Eso hizo que el frontend pudiera integrar sin preguntarme cada detalle."

La diferencia es clara: la segunda respuesta demuestra que usaste el concepto, no que lo leíste.

Checklist de estructura para respuestas técnicas

• Concepto: 1 oración, directo al punto
• Aplicación: Tu experiencia real o un ejemplo hipotético detallado
• Resultado: Qué problema resolvió o qué aprendiste
• Anti-patrón a evitar: Responder solo teoría sin contexto
• Truco: Si no lo usaste, inventá un caso de uso específico como "Si tuviera que hacer X, haría Y porque Z"

Semana 3: Código en vivo sin que se note que nunca lo hiciste

La parte que más pánico genera es escribir código mientras alguien mira. Acá no buscan que resuelvas un problema de algoritmos nivel Google. Buscan ver cómo pensás, cómo debuggeás y si pedís ayuda cuando te trabás.

Simulá entrevistas técnicas de backend con estos ejercicios:

Ejercicio 1: Endpoint básico con validación

Consigna: "Creá un endpoint que reciba datos de un usuario y valide que el email sea correcto antes de guardar."

Anti-patrón junior:

app.post('/users', (req, res) => {
  const user = req.body;
  db.save(user);
  res.send('Usuario creado');
});

Por qué está mal:

• Sin validación
• Sin manejo de errores
• Sin tipado ni chequeos
• Respuesta genérica

Patrón correcto:

app.post('/users', async (req, res) => {
  try {
    const { email, name } = req.body;
    
    // Validación explícita
    if (!email || !email.includes('@')) {
      return res.status(400).json({ 
        error: 'Email inválido' 
      });
    }
    
    if (!name || name.trim().length === 0) {
      return res.status(400).json({ 
        error: 'Nombre requerido' 
      });
    }
    
    const user = await db.users.create({ email, name });
    
    res.status(201).json({ 
      id: user.id, 
      email: user.email 
    });
    
  } catch (error) {
    console.error('Error creando usuario:', error);
    res.status(500).json({ 
      error: 'Error interno del servidor' 
    });
  }
});

Lo que demuestra este código:

• Validás antes de guardar
• Manejás errores con try/catch
• Devolvés códigos HTTP correctos (400, 201, 500)
• No exponés datos sensibles en la respuesta

Ejercicio 2: Consulta a DB con relaciones

Consigna: "Traé todos los posts de un usuario con sus comentarios."

Anti-patrón junior:

app.get('/users/:id/posts', async (req, res) => {
  const posts = await db.query('SELECT * FROM posts WHERE user_id = ?', [req.params.id]);
  res.json(posts);
});

Patrón correcto:

app.get('/users/:id/posts', async (req, res) => {
  try {
    const userId = parseInt(req.params.id);
    
    if (isNaN(userId)) {
      return res.status(400).json({ 
        error: 'ID de usuario inválido' 
      });
    }
    
    // Consulta con JOIN para traer comentarios
    const posts = await db.query(`
      SELECT 
        p.id, 
        p.title, 
        p.content,
        c.id as comment_id,
        c.text as comment_text
      FROM posts p
      LEFT JOIN comments c ON p.id = c.post_id
      WHERE p.user_id = ?
      ORDER BY p.created_at DESC
    `, [userId]);
    
    // Estructurar respuesta para frontend
    const postsFormatted = posts.reduce((acc, row) => {
      let post = acc.find(p => p.id === row.id);
      
      if (!post) {
        post = {
          id: row.id,
          title: row.title,
          content: row.content,
          comments: []
        };
        acc.push(post);
      }
      
      if (row.comment_id) {
        post.comments.push({
          id: row.comment_id,
          text: row.comment_text
        });
      }
      
      return acc;
    }, []);
    
    res.json(postsFormatted);
    
  } catch (error) {
    console.error('Error obteniendo posts:', error);
    res.status(500).json({ 
      error: 'Error al obtener posts' 
    });
  }
});

Lo que esto comunica:

• Entendés relaciones entre tablas
• Estructurás datos para que sean fáciles de consumir
• Validás tipos (parseInt)
• Pensás en el frontend que va a consumir tu API

Cómo practicar código en vivo

1. Usá un timer de 20 minutos: Resolvé ejercicios simples con límite de tiempo
2. Pensá en voz alta: Grabate explicando tu código mientras lo escribís
3. Comentá tu código antes de escribirlo: Escribí los pasos en comentarios, después completá la lógica
4. Debuggeá a propósito: Introducí un error y practicá encontrarlo con console.log

Semana 4: Las preguntas que hacer y las que delatan ignorancia

Un junior que no pregunta nada en una entrevista levanta dos alarmas: o no le interesa la posición o no entiende lo suficiente como para tener dudas. Las mejores preguntas demuestran que entendés el trabajo real, no que leíste un artículo de Medium.

Preguntas que suman puntos

Sobre el código y stack:

• "¿Qué criterio usan para elegir entre SQL y NoSQL en un proyecto nuevo?"
• "¿Cómo manejan migraciones de base de datos en producción?"
• "¿Tienen alguna guía de estilo o linter configurado para el equipo?"

Sobre procesos:

• "¿Cómo es el proceso de code review? ¿Hay algún checklist?"
• "¿Qué pasa si depliego algo que rompe producción? ¿Tienen rollback automático?"
• "¿Cada cuánto hacen deploy? ¿Es manual o automatizado?"

Sobre crecimiento:

• "¿Qué buscan que un junior domine en los primeros 3 meses?"
• "¿Hay espacios para proponer mejoras técnicas o el roadmap está cerrado?"

Preguntas que restan puntos

• "¿Cuántos días de vacaciones hay?" (preguntalo después de la oferta)
• "¿Usan las últimas tecnologías?" (muy vago, suena a buzzword)
• "¿Hay home office?" (válido pero no como única pregunta)
• Cualquier cosa que esté en la descripción del puesto

Anti-patrón: La pregunta teórica que no suma

Evitá preguntar cosas que podés buscar en Google solo para demostrar que sabés el término:

• "¿Usan el patrón Repository?"
• "¿Tienen microservicios?"

Mejor convertirlas en preguntas de decisión:

• "¿Cómo deciden cuándo extraer lógica a un servicio separado?"
• "¿Qué los llevó a elegir microservicios o monolito?"

Plan de 30 días: Checklist completo

Semana 1-2: Respuestas estructuradas

• Elegí 10 conceptos clave (API REST, HTTP, autenticación, CORS, middleware, ORM, migraciones, status codes, JSON, Git)
• Escribí respuestas CAR para cada uno
• Practicá explicarlos en voz alta en menos de 2 minutos

Semana 3: Código en vivo

• Resolvé 5 ejercicios de CRUD básico con validaciones
• Resolvé 3 ejercicios de consultas con relaciones
• Grabate programando y explicando en voz alta

Semana 4: Simulacro completo

• Pedí a un amigo dev que te haga una entrevista falsa
• Prepará 5 preguntas para hacer al entrevistador
• Revisá tus proyectos: tené 2 decisiones técnicas claras para explicar

Anti-patrones que te delatan como junior sin experiencia:

• Responder solo con teoría sin ejemplos
• No validar datos antes de guardar
• No manejar errores en async/await
• Devolver siempre status 200
• No hacer preguntas en la entrevista
• Decir "no sé" sin proponer un approach

Preguntas frecuentes

¿Qué hago si me preguntan algo que no sé?

No inventes. Decí: "No lo usé todavía, pero mi approach sería investigar X y probar Y. ¿Es un tema que debería profundizar para este rol?" Eso demuestra criterio.

¿Es malo admitir que soy junior?

No. Lo que es malo es actuar como que sabés todo. Si te preguntan por un concepto avanzado, podés decir: "Leí sobre eso pero no lo implementé. ¿Podrías darme un ejemplo de cuándo lo usarían acá?" Te hace ver humilde y con ganas de aprender.

¿Cuánto código tengo que saber de memoria?

Ninguno. Pero tenés que saber la estructura general. Si te piden un endpoint con Express, no es necesario que recuerdes la sintaxis exacta del middleware, pero sí tenés que saber que va antes de las rutas y que recibe req, res, next.

¿Me van a preguntar algoritmos complejos?

Para posiciones junior de backend, raramente. Es más probable que te pidan explicar qué hace un código, debuggear un error o diseñar un endpoint. Si te piden un algoritmo, suelen ser cosas básicas: filtrar un array, sumar valores, agrupar datos.

¿Tengo que saber Docker, AWS, Kubernetes?

No para junior. Pero sí tenés que saber que existen y por qué se usan. Si te preguntan, una respuesta válida es: "Sé que Docker permite empaquetar aplicaciones con sus dependencias para que corran igual en cualquier ambiente. No lo configuré desde cero, pero corrí proyectos con docker-compose." Eso es suficiente.