¿Cómo preparar un proceso de selección para SDE?. Si has llegado hasta aquí puede que sea por dos motivos:

  1. Te ha contactado un recruiter para invitarte a un proceso de selección de una empresa “muy tocha
  2. Estás pensando en aplicar a un proceso de selección de una empresa americana (Silicon Valley o del estilo)

Ahora hace justo un año que me estuve preparando para un proceso de selección para SDE o Software Development Engineer.

Lo que en español viene a ser “Ingeniero de Software” y lo que según algunos es una profesión absurda, un mito y un timo, la gran estafa y una pérdida de tiempo. Ya que “para desarrollar software basta con leer unos cuantos tutoriales por Internet o para diseñar un algoritmo sólo tienes que buscarlo en Google“.

Bueno, después de soltar esa pequeña granada, hoy voy a contar cómo me preparé el proceso de selección para Software Development Engineer de una de las empresas gordas de desarrollo de software de Ameuica.

1. El recruiter

Si tienes perfil en LinkedIn, llevas más de 5 años trabajando y eres Software Engineer, Data Scientist, Big Data Engineer o similar, seguramente estarás recibiendo varias propuestas de recruiters cada mes.

En mi caso, durante varios años estuve recibiendo mensajes de “esta empresa” (y muchas otras) hasta que al final decidí dar el paso. La verdad es que me lo tomé como una experiencia y una oportunidad, sin más. No lo buscaba, simplemente surgió.

No siempre es así, pero a veces, los recruiters de puestos tecnológicos, son mujeres, tienen formación en psicología y muchas veces están buenas (y no es casualidad).

De los recruiters hay que fiarse a medias:

Primero porque van de culo y aunque al final acabas intercambiando correos y llamadas con ellos durante meses, no saben quién eres.

Y segundo porque van a comisión/objetivos osea, a su propio interés. Aún así, a veces ayudan bastante.

2. El curriculum vitae para un proceso de selección

Lo primero que te va a pedir el recruiter es tu curriculum. Doy por hecho que si eres “Software Engineer” sabes hacer un curriculum. Por si acaso, aquí algunos errores típicos de estudiantes (de letras) en sus curriculum que, lógicamente, hay que evitar.

Para redactar mi curriculum de “Software Engineer” seguí 3 pasos fundamentales:

  1. Cuidar el diseño y la ortografía: Diseño minimalista y cero faltas de ortografía. Que no duela a los ojos
  2. Quitar la morralla: Prácticamente no puse casi nada de lenguajes de programación, frameworks, ni pajas mentales. Sobretodo, formación y experiencia, sólo lo más relevante y en una página. Muy breve.
  3. Contar mis aptitudes: La segunda página para hablar de mis aptitudes (en qué soy bueno), lo que me gusta y cualidades más allá de sentarme delante de una pantalla a programar (también tengo vida).

Ahora bien, cada uno que lo haga como quiera. Eso sí, tu curriculum vitae es la única referencia que tienen sobre ti en cada entrevista.

Buscan ingenieros pero no te van a pedir el título. Lo utilizan como una barrera de entrada para que la gente que aplica sepa los conocimientos mínimos que hay que tener. Ahora bien, no creo que pidan el título para nada (a mí no me lo pidieron)

3. La prueba de código

Antes de llegar al proceso de selección para un puesto de SDE, normalmente van quitando la morralla (lo que viene ser descartar a gente).

Así que, si tu curriculum les ha parecido molón, te citan para una prueba de código.

¿Cómo funciona la prueba de código en un proceso de selección de ingeniero de software?

Muy fácil. Hay varias plataformas, donde te dan un usuario y una contraseña. Tienes hasta una fecha límite, para entrar y resolver un problema programándolo en una interfaz web.

Una vez empiezas la prueba de código, tienes un tiempo límite para resolverlo (ahora no recuerdo, pero ponle una hora). Tienes un botón para validar mediante un test que tu solución es correcta. Y luego, es posible que tengas que contestar un par de preguntas relacionadas con el problema.

En mi caso, utilizaron HackerRank. Te puedes crear un usuario por tu cuenta y practicar unos días antes, aunque yo fui a pelo.

HackerRank_logo_with_slogan

El problema no era muy complicado, recuerdo que se resolvía con un par de HashMaps. Lo dicho, típica prueba de código para descartar la morralla.

Normalmente, puedes elegir el lenguaje de programación que quieras para resolverlo o al menos elegir entre los más típicos (Java, C o python).

Y ya está, al cabo de unos días te dicen por mail si lo has pasado o no.

4. La entrevista telefónica

Obviamente en mi caso, pasé la prueba de código.

A continuación, te citan para una entrevista telefónica (o screening phone interview). No te dan muchos detalles, sólo que durará entre media hora y una hora y serán preguntas generales de “Computer Science, vamos lo que se estudia en los primeros años de la carrera: estructuras de datos, algoritmos, coste computacional, etc.

La verdad es que durante esa semana estuve buscando bastante información sobre cómo sería la entrevista (sin mucho éxito por cierto). Y al final no fue para tanto.

En mi caso, me llamó una chica desde Ameuica y me hizo unas cuantas preguntas, que obviamente no me acuerdo (ha pasado un año), pero cosas sobre HashMaps, árboles, cómo resolvería tal cosa, qué estructura de datos utilizaría para no sé qué problema y la última pregunta sí me acuerdo:

“Si utilizas una lista para guardar los contactos de tu agenda telefónica cuál es el coste de buscar un número”

Cosas de primero de carrera. Pero ya vas viendo por donde van a ir los tiros de la entrevista de verdad.

Como consejo, recomiendo hacer la entrevista en una habitación sin mucho ruido y con auriculares (para oír las preguntas mejor). En mi caso, la tía tenía un acento muy chungo y la entendía a medias. Pero bueno, allá cada uno con el nivel de inglés que tenga.

Antes de colgar, la persona al otro lado me dijo que había hecho bien la entrevista y que si estaba interesado me citaban para la entrevista “onsite“. Yo dije que sí y a los pocos días tenía un mail con las instrucciones.

5. Antes de la entrevista “onsite

Llegados a este punto ya habían pasado unos dos meses desde el primer contacto con la recruiter, pasando por la prueba de código, entrevista telefónica y ahora me citaban para la entrevista “onsite“.

Normalmente estas entrevistas, lo plantean como “eventos“, ya que citan a varios candidatos durante varios días en algún sitio (un hotel en mi caso). Lo hacen así, para hacer varias entrevistas de un plumazo y porque los entrevistadores vienen de Ameuica.

Bueno, antes de la entrevista “onsite“, hubo una pila de correos con instrucciones, las características del puesto que ofertaban, información sobre la “cultura, principios y valores” de la empresa/secta y una retahíla de mierda que me empezó a agobiar bastante.

También un par de correos con preguntas muy concretas y de dudosa ética, como por ejemplo tu sueldo actual, si estás en otro proceso de selección, cuánto quieres cobrar y cosas varias (que contestas si quieres).

Luego más correos organizativos, sobre el viaje (vuelos, hotel, etc.).

Y unos días antes de la entrevista, re-confirmación de que vas a ir y que tu situación laboral no ha cambiado con respecto al proceso de selección.

Durante todo este tiempo, en mi caso, le estuve dedicando algo de tiempo a preparar la entrevista (al final del post explico cómo)

6. La entrevista “onsite

Llega el día. Y para mí, ha sido uno de los momentos más tensos de mi carrera profesional (y mira que llevo proyectos, reuniones, reviews, presentaciones, auditorías y cacotes a la espalda).

Bueno, la entrevista “onsite” paso a paso:

Llego un día antes a la ciudad de la entrevista: hotel molón. Elijo la entrevista por la tarde porque soy vago y no me gusta madrugar. Prefiero invertir la mañana en cagar varias veces.

La entrevista es en un hotel, llego apurado, te recibe parte del equipo de “recruiters” (a ti y al resto de candidatos). Y te explican el funcionamiento, que más o menos ya sabes porque te lo contaron por mail.

  • 3 entrevistas con 3 personas diferentes de 45 minutos de duración
  • A resolver preguntas y problemas en una pizarra (los que dé tiempo)
  • 5 minutos al final de cada entrevista para que preguntes lo que quieras
  • 10 minutos de descanso entre cada entrevista
  • Opcionalmente, puede haber una 4ª entrevista (no dicen porqué)

Así fueron las mías (muy resumidamente y de lo que me acuerdo):

    Primera entrevista

  1. La primera con un desarrollador americano con esta cara u_u.

    Dos problemas, el primero diseñar un algoritmo para encontrar anagramas en una lista, el segundo algo de árboles.

    Hice el primero bien y el segundo no me dio tiempo a acabar.

    Le pregunto que qué tal se trabaja, qué frameworks usan, etc.

  2. Segunda entrevista

  3. La segunda con un “manager“.

    Un indio que al entrar se mete un caramelo de esos duros en la boca. No se le entendía una mierda, pero apreté el culo para afinar el oído.

    Preguntas: Diseña un algoritmo para obtener identificadores únicos en un sistema utilizado por mil millones de usuarios. Y la otra: Diseña una aplicación para gestionar un parking (a nivel de clases).

    Mis preguntas: ¿Cómo gestionan los proyectos? ¿Cómo es la toma de decisiones?

  4. Tercera entrevista

  5. La tercera con un señor mayor y un chaval joven.

    Preguntas: Diseña un algoritmo para serializar y deserializar un heap y la otra ni me acuerdo.

    Las preguntas que le hice a este fueron buenas y me marcaron. Primero ¿A qué se dedica en la empresa? (esto se lo pregunté porque a diferencia de los otros no me lo había dicho) Bien, resulta que era el jefazo (el tío controlaba la verdad).

    proceso de selección SDE

    Segunda pregunta y la clave de todo: Como jefazo ¿Qué esperas de un SDE? Respuesta: Everything. A lo que el chanclillas de al lado añade: Everything… and more.

  6. Colofón

  7. En fin, me dejaron sólo en la sala y o bien venían a decirme que me fuera a casa o bien me metían el puño por el culo más fuerte con la 4ª entrevista.

    Me tocó la 4ª entrevista.

    Un chavalín hablando inglés que se notaba que era español. Me pone el problema más jodido de todos, iba de ordenar un árbol con un montón de restricciones que obviamente no me acuerdo (a parte que estaba hasta los huevos de “trabajar“). Y luego me hizo a saco de preguntas sobre mi carrera profesional (cosa que los otros no me habían hecho).

    Al final le hice un par de preguntas clave que sumadas a lo de “Everything… and more“, me dejaron claro todo lo que necesitaba saber.

Después de eso me liberaron con gran amabilidad. Por cierto, no se pasaron ni un segundo del tiempo de 45 minutos por entrevista. Flipante la puntualidad en todo.

7. La decisión final

La decisión final se hizo esperar un par de semanas. Durante este tiempo estuve un poco jodido la verdad, por la incertidumbre y porque tenía mis dudas.

Podían pasar tres cosas:

  1. O me lo ponían fácil y no me seleccionaban
  2. O me lo ponían más fácil aún y me seleccionaban con el sueldo que había pedido
  3. O me lo ponían difícil y me seleccionaban con un sueldo de mierda

Y me lo pusieron fácil (pero no “más fácil aún” :P).

Mi opinión sobre el proceso de selección

Por partes:

1. Cuando acabé sinceramente me quité un peso de encima.

Menudo coñazo, qué agobio y qué tensión. Y eso que era sólo el proceso de selección, no me imagino lo que tiene que ser el día a día…

A parte, 3 meses para un proceso de selección y que cuando acabas tienes la sensación de que es absurdo.

entrvista de código

2. Cuando no me seleccionaron, al principio un poco de decepción porque yo lo que quería era decir que NO. (En realidad me hubiera gustado pasar todas las pruebas por superación personal).

Eso sí, es toda una experiencia y por lo menos ya sé cómo funciona. Trabajar en una empresa de esas, a no ser que valoren algo que no sé durante las entrevistas, parece bastante factible.

3. Respecto a las entrevistas “onsite“, me parecen absurdas.

Cualquier chavalín medio espabilado que haya estudiado los dos primeros cursos de Ingeniería Informática, se saca los problemas con la punta del nabo. A mí me costaron algo, pero es que son cosas que no hago normalmente…

Pero bueno, parece que este método de entrevistas es bastante común.

Mis consejos sobre un proceso de selección de este tipo

Muy brevemente 3 cosillas más a parte de todo lo que ya he contado:

1. Tomárselo como una experiencia. No vale la pena agobiarse. Oportunidades hay miles. Hoy mismo me han vuelto a escribir de la misma empresa (por eso me he acordado de lo de hace un año y estoy escribiendo esto)

2. El trato con todo el mundo es cordial, gente amable, simpática (un poco “sectosos”). La ropa que tienes que usar es casual (nada de trajes y escobitas por el culo) y por supuesto nivel alto de inglés (eso ni se pregunta).

3. Leer bien sobre la cultura, valores de la empresa y opiniones de trabajadores. A veces, las empresas de Silicon Valley son una secta. Así de claro.

4. Puesto que la entrevista se basa en resolver problemas en una pizarra. Practica a saco. Cambia mucho resolver algo programando en una pantalla, a hacerlo en una pizarra. Sobretodo por el espacio.

whiteboard

5. Y por último y esto puede que sea algo muy concreto de la empresa con la que hice el proceso de selección. Prepara dinerico fresco para algunos gastos del viaje. Luego te devuelven todo, sí. Pero yo pagué 150€ de una noche de hotel (no me pillaron uno barato no), más manutención, más transporte urbano, etc.

Material, ejercicios y problemas para un proceso de selección para SDE

Por último, respecto al material con ejercicios y problemas que utilicé para la entrevista de código:

1. HackerRank

La verdad que hice un par de problemas más después de la primera prueba de código. Pero puede estar bien para practicar.

2. Quora y otros foros

En Internet hay cientos de sitios con gente contando su experiencia en este tipo de entrevistas (como he hecho yo).

3. Libros

Yo me pillé dos libros para preparar la entrevista de código que me empollé de cabo a rabo:

  1. Cracking the coding interview
  2. Programming interviews exposed

La verdad es que están muy bien. Los problemas que me preguntaron eran muy parecidos sino iguales a los que aparecen en el libro.

Además, te explica todas las estructuras de datos, cómo calcular el coste computacional, como recorrer árboles, listas enlazadas, etc. Todo lo importante que se estudia en la carrera pero resumido y bien explicado.

A parte, ambos libros los han escrito personas que se han dedicado a hacer ese tipo de entrevistas.

Así que altamente recomendables, ambos.

A parte de esos, pues desempolvé algunos libros clásicos de patrones de diseño (el libro de la amateur con coletas), estructuras de datos y algoritmos, etc.

En fin, eso es todo. Si te vas a presentar próximamente, ánimo! 🙂