Questions to Ask in a Software Engineer Interview

Te quedan cinco minutos de entrevista y el entrevistador pregunta: "¿Tienes alguna pregunta para nosotros?". Si respondes "no, todo claro", acabas de perder la mejor oportunidad de saber si ese trabajo merece la pena. Y de demostrar que piensas como alguien con experiencia.

Las preguntas que haces al final dicen mucho de ti. Un junior pregunta por el sueldo y por las vacaciones. Un senior pregunta por cómo se toman las decisiones técnicas, qué pasa cuando algo se rompe en producción y por qué el puesto está libre. La diferencia se nota en diez segundos.

Aquí tienes doce preguntas con criterio, agrupadas por lo que revelan. Úsalas como base, no como guion. Elige tres o cuatro según la conversación que hayáis tenido.

Por qué importan las preguntas que haces#

Una entrevista es bidireccional. La empresa te evalúa, pero tú también estás evaluando si vas a pasar allí los próximos dos años de tu vida. Y hay información que solo sale si preguntas con concreción.

Además, hacer buenas preguntas cambia la dinámica de la entrevista. Pasas de estar respondiendo a tener una conversación técnica entre pares. Eso es exactamente lo que buscan los equipos buenos.

Si estás preparando varias entrevistas, revisa las ofertas abiertas en nuestro buscador de empleo tech para tener contexto sobre lo que pide cada empresa.

Preguntas sobre la realidad del equipo#

Estas preguntas te dan una foto de cómo se trabaja de verdad, no de cómo dice la web que se trabaja.

1. ¿Cuántos desarrolladores hay en el equipo y cómo se reparten las responsabilidades? ¿Hay alguien que sea el único que conoce un sistema importante?

La segunda parte es la buena. Si te dicen que sí, ahí tienes un riesgo real y una oportunidad de aportar valor. También te dice cómo gestionan el conocimiento.

2. ¿Cuándo fue la última vez que el equipo tuvo que hacer una guardia o resolver una incidencia fuera de horario? ¿Con qué frecuencia ocurre?

Esto te habla de la estabilidad del sistema y de cómo tratan a la gente. Una respuesta del tipo "casi nunca" es mejor señal que un discurso sobre la cultura de ownership.

3. ¿Cuánto tiempo dedica el equipo a trabajo nuevo frente a mantenimiento, deudas técnicas y soporte?

Si te dicen que el 80% es desarrollo de producto, ojo: o el sistema es nuevo, o no están contando todo. Un reparto realista suele estar entre 40 y 60% de trabajo nuevo, y eso no es malo si es transparente.

4. ¿Cómo se distribuye el trabajo? ¿Hay sprints, tickets, o cada quien toma lo que ve?

No hay una respuesta correcta. Hay la respuesta que encaja contigo. Lo que buscas es coherencia entre lo que te cuentan aquí y lo que te contaron en la primera llamada.

Preguntas sobre prioridades y decisiones#

Aquí averiguás si la empresa sabe lo que está haciendo o si cambia de objetivo cada dos semanas.

5. ¿Cuál es el mayor problema técnico que el equipo tiene pendiente para este año? ¿Por qué sigue sin resolverse?

La segunda pregunta es la que duele. Si te dicen "porque no nos dan tiempo", ya sabes cómo se prioriza. Si te dicen "porque lo estamos abordando por fases", mejor.

6. ¿Cómo se toman las decisiones técnicas importantes? ¿Quién tiene la última palabra?

Buscas distinguir entre un equipo donde el staff engineer escucha y decide, y uno donde el CTO cambia de framework según lo que leyó el fin de semana. Ninguna de las dos es automáticamente mala, pero son experiencias muy distintas.

7. ¿Qué porcentaje del roadmap del próximo trimestre está definido y cuánto suele cambiar por el camino?

Un roadmap que cambia un 20% es normal. Uno que cambia cada dos semanas significa que estás en modo reactivo y que tu trabajo difícilmente tendrá impacto medible.

Preguntas sobre criterios de éxito#

Estas preguntas evitan la sorpresa de llegar a los tres meses y descubrir que miden tu trabajo con una vara que nadie te explicó.

8. ¿Cómo sabré a los seis meses que estoy haciendo un buen trabajo? ¿Qué habré entregado o resuelto?

Si no te pueden responder esto con algo concreto, la empresa no tiene claro lo que espera del puesto. Y eso te va a costar caro en la próxima revisión de desempeño.

9. ¿Cómo es el proceso de revisión de código y de despliegue? ¿Cuántas personas tienen que aprobar un cambio y cuánto tarda en llegar a producción?

Esto te dice si vas a poder moverte o si cada cambio es una negociación. Preguntar por el tiempo medio de despliegue es una pregunta técnica que revela madurez sin sonar a examen.

10. ¿Qué formación o presupuesto de aprendizaje hay? ¿Se da tiempo dentro de la jornada o es algo que se hace fuera?

Las dos respuestas son válidas, pero si te dicen que hay "mucha libertad para aprender" y nadie te dice cuántas horas ni cuánto dinero, es un titular vacío.

Preguntas sobre riesgos y honestidad#

Estas preguntas incomodan un poco. Bien. La incomodidad controlada saca información que el resto de candidatos no consigue.

11. ¿Por qué está libre este puesto? ¿Alguien ha dejado el equipo en el último año?

Puede ser por crecimiento, por una promoción interna o porque la persona se fue. Todo es información útil. Si detectas incomodidad o evasivas, apúntalo.

12. ¿Cuál es la mayor debilidad del equipo según vosotros mismos? ¿Qué estáis intentando mejorar?

Esta pregunta filtra rápido. Los equipos buenos tienen una respuesta preparada y concreta. Los equipos que dicen "no se me ocurre ninguna" o "lo único malo es que trabajamos mucho", te están diciendo otra cosa.

Un ejemplo de cómo formularlas#

No sueltes la lista como un interrogatorio. Conecta la pregunta con lo que ya se ha hablado. Algo así funciona:

"Antes comentabais que el equipo ha crecido mucho este año. Justo eso me hace querer preguntar por los conocimientos que quedan concentrados: ¿hay sistemas donde solo una persona sabe cómo funcionan? ¿Cómo lo estáis gestionando?"

Esto suena a conversación, no a checklist. Y demuestra que has estado escuchando.

Qué preguntas evitar y por qué#

Hay preguntas que restan puntos, no porque sean ilegítimas, sino porque las haces demasiado pronto o de la forma equivocada.

• ¿Cuánto pagan? Es legítimo, pero dejalo para la conversación con RRHH o para cuando haya una oferta sobre la mesa. En la entrevista técnica resta.
• ¿Puedo trabajar desde casa todos los días? Mejor pregunta por la política concreta de trabajo remoto y por cómo se coordina el equipo a distancia.
• ¿Hacéis muchas horas extra? Suena a que buscas escaquearte. Pregunta por el equilibrio entre trabajo y vida personal, y observa la respuesta.
• ¿Qué hace exactamente la empresa? Eso lo deberías saber antes. Llegar sin haber leído la web da una mala impresión.
• ¿Cuánto tardaré en ascender? Pregunta por las expectativas del puesto primero. El ascenso es una consecuencia, no un punto de partida.

Si quieres contrastar lo que ves en la oferta con lo que te cuentan en la entrevista, usa el analizador de ofertas para sacar los requisitos ocultos de la descripción. Y si vas a enviar el CV antes de esa entrevista, conviene pasar el verificador de ATS para descartar problemas de formato.

Cómo leer las respuestas#

Preguntar es la mitad. La otra mitad es interpretar lo que te dicen, incluyendo lo que no te dicen.

Fíjate en la concreción. "Tenemos una cultura de feedback muy fuerte" no significa nada. "Hacemos retrospectiva cada dos semanas y en la última decidimos cambiar el proceso de revisión" significa que hay un mecanismo que funciona.

Fíjate en la consistencia. Si el hiring manager dice que el equipo es estable y luego el futuro compañero dice que se fueron tres personas en seis meses, ahí hay algo que no cuadra. Pregunta por la diferencia con respeto.

Fíjate en quién responde. Si solo habla el manager y el equipo calla, pregúntate por qué. En las buenas entrevistas, los futuros compañeros tienen cosas que decir.

Fíjate en la velocidad de respuesta. Una pregunta incómoda que recibe una respuesta rápida y honesta es una señal muy buena. Una pausa larga seguida de evasivas, también es una señal, solo que de otro tipo.

Y una última cosa. Si una empresa te penaliza por hacer preguntas difíciles, acabas de ahorrarte seis meses de mala experiencia. Mejor saberlo ahora que en febrero.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuántas preguntas debo hacer en una entrevista técnica?

Entre tres y cinco, según el tiempo que tengas. Es mejor hacer pocas preguntas bien conectadas con la conversación que soltar una lista de diez sin contexto.

¿Es buena idea preguntar por el salario en la primera entrevista técnica?

No en la entrevista técnica. Sí en la primera llamada con reclutamiento, donde encaja mejor y te ahorra perder tiempo en procesos que no encajan con lo que buscas.

¿Qué hago si el entrevistador no sabe responder mis preguntas?

Es normal que un compañero técnico no sepa detalles de compensación o de política de empresa. Lo raro es que nadie del proceso pueda responderte sobre el trabajo del día a día.

¿Debo hacer preguntas diferentes según el seniority del puesto?

Sí. Para un puesto junior, preguntas sobre mentoría y formación tienen más peso. Para un puesto senior, pesan más las de arquitectura, prioridades y decisiones.

¿Puedo enviar mis preguntas por escrito después de la entrevista?

Puedes enviar una o dos preguntas pendientes en el correo de agradecimiento. Es una buena forma de mantener la conversación viva sin parecer que estás presionando.