5 Consejos para destacar en la prueba técnica

Cada vez más empresas utilizan pruebas técnicas como parte de su proceso de selección. Una de las más habituales es enviarte el enunciado de un problema de negocio (generalmente relacionado con su actividad) para que lo resuelvas en casa. Tu ejercicio será posteriormente evaluado por tus potenciales colegas de trabajo de forma asíncrona, sin tener contacto contigo. En otras palabras, tu carta de presentación en esta parte del proceso es tu código, por lo tanto, debe transmitir todas tus capacidades.

He estado en ambos lados del muro: He sido candidata y he sido revisora, y esto me ha ayudado a aprender varios trucos y normas de “etiqueta” que me gustaría transmitirte a través de los siguientes consejos:

 

Haz preguntas

Lee con detenimiento el ejercicio y si hay algo que no te queda claro pregúntalo. Una de las capacidades más útiles en programación es la empatía. ¡Programar no cosiste en picar código! En nuestro trabajo es muy importante que entendamos bien el contexto de nuestras tareas, el vocabulario de nuestro sector, las necesidades del cliente. Por lo tanto, no dejes de hacer una pregunta porque pienses que vas a quedar mal, al contrario, vas a dar una imagen muy profesional al mostrar tu compromiso con la entrega de valor.

 

Preocúpate por el enfoque, no por terminarlo

No necesito que termines el ejercicio. No voy a ponerlo en producción ni a venderlo. Lo que necesito es saber cómo programas. Por lo tanto, preocúpate más por cosas como, por ejemplo, tu historial de commits.

Los commits son una buena representación de tu metodología. Sólo leyendo el nombre de tus commits podría conjeturar si has escrito los tests antes que el código, si has dado pasos pequeños, qué importancia tiene para ti la fase de refactor, cuánto tiempo has tenido los tests en rojo e incluso tu capacidad para expresarte y tu nivel de inglés.

Lo cierto es que las aplicaciones nunca están terminadas. El código es un ser vivo que muta constantemente a lo largo del tiempo, por lo tanto es irrelevante si te has creado un “Facebook” de una sentada en una noche. Eso sólo demuestra que tenías tiempo para hacerlo. Lo realmente importante es si tu código es legible por otras personas, si eres capaz de transmitir tus conocimientos, si encajas con nuestra cultura ágil.

Piensa: si tuvieras que irte de vacaciones y dejar este código en manos de otra persona, ¿sería fácil para esta persona trabajar con él? Si la respuesta es sí, no importará que no esté terminado.

Escribe un código limpio

Seguramente estoy dejando de hacer otras cosas para revisar tu ejercicio. Tengo poco tiempo: No me obligues a perderlo descifrando tu código.

Hay muchos trucos y recursos que pueden enseñarte a escribir un código legible y expresivo: Leer mucho para adquirir vocabulario, aprender a detectar los olores de código y a refactorizarlos, programar en parejas…

Mejorar en esta habilidad te será muy útil para comunicarte con tus compañeras y compañeros de trabajo, e incluso con tu yo del futuro. Y también será útil, como hemos visto, para la empresa, ya que un código limpio es un código escalable.

Truco: Si necesitas explicarte a través de comentarios por todo el código, algo no va bien. El código debería autodocumentarse a través de la semántica y de los tests.

 

Cuida tu README

El README es el documento en el que se define en qué consiste un proyecto y cómo interactuar con él. Y es lo primero que voy a buscar. Intenta incluir en él toda la información que creas que voy a necesitar:

  • El enunciado del problema: no des por hecho que me lo sé. Puede que hiciera este ejercicio hace meses o años, o tal vez nunca, y ahora está perdido en el laberinto de documentación laboral de la empresa. No me hagas ir a donde quiera que tengamos los enunciados a buscar el tuyo.
  • Cómo levantar la aplicación y ejecutar los tests: En definitiva, cómo utilizar tu programa. No asumas que tengo el mismo entorno que tú instalado en mi ordenador, ponme links a recursos si debo descargarme alguno, concreta versiones, lista requisitos, dime cuál es el comportamiento esperado.
  • Notas: Si quieres decirme algo que no puedes expresar a través del código, puedes reservar una sección del Readme para “Observaciones”. Por ejemplo, si tenías en mente hacer algunas cosas pero no te ha dado tiempo, o no has podido tomar alguna decisión porque preferirías debatirlo con alguien, escribe una lista de “To-Do” explicando qué, por qué y cómo.
    Por otro lado, es importante que cuides las formas. No te tomes confianzas. No soy tu “coleguita de birras”, soy una profesional que está juzgando tu trabajo, por cierto, con un código de conducta bajo el brazo. Dame sólo la información necesaria, de una forma concisa.
    Y sobretodo no utilices el Readme para quejarte de algo o de alguien, para disculparte, o para explicarme tu situación personal. Estas son cosas que debes hablar con tu persona de contacto de la empresa, que es quien debe valorarlo. Si tu situación personal te ha impedido que dediques más tiempo al ejercicio, lo dicho, escribe en la lista de “To-Do” lo que habrías hecho si hubieras podido.

Haznos la vida fácil

En general, lo que se agradece es que tu ejercicio sea fácil de revisar: Fácil de entender y fácil de operar. En este aspecto, mi mayor consejo es que virtualizes tu entorno de pruebas.

Como he comentado seguramente la persona que te lo está revisando tiene poco tiempo y muchos ejercicios en la cola de espera, y es muy incómodo tener que instalarse el entorno concreto que requiera cada ejercicio.

Por eso agradezco mucho cuando una aplicación está Dockerizada, ya que trae todo el entorno preconfigurado, con las versiones necesarias, etc. Ayúdame a centrarme en tu código.

 

¡Espero que estos consejos te sirvan de utilidad en futuras oportunidades laborales! Ten en cuenta que están basados en experiencias y opiniones personales, por lo tanto, no los sigas al pie de la letra. Los ejemplos que he puesto sirven para procesos de selección en los que se valora ante todo la excelencia técnica y el seguimiento de las buenas prácticas, sin embargo puede que no te sirvan si aspiras a un puesto de Data Science o desarrollo de videojuegos, por ejemplo. Investiga siempre qué es lo que se espera de tí y cuáles son los valores de la empresa.

¿Conoces algún otro truco o consejo para superar las pruebas técnicas?

¿Dónde están esas devs?

¿Cuántas veces has oído eso de que “a las chicas no les gusta programar”? Yo estoy harta de oírlo y leerlo así que lo primero que quiero dejar claro con este artículo es que que nos gusta. ¡Claro que nos gusta! ¿Por qué no iba a gustarnos uno de los oficios más creativos, más empáticos, mejor pagados y con mayor empleabilidad del panorama?

 

¿Entonces, por qué no tengo candidatas?

Te propongo un ejercicio: Por un momento, imagínate que a las mujeres nos gusta programar tanto (o tan poco) como a los hombres.

Visualiza ese supuesto. Créelo. ¿Lo tienes? Vale, ahora vuelve a preguntarte por qué no tienes candidatas. Por qué, aunque nos guste programar, no nos hemos interesado por el puesto que ofreces. Pregúntate también por qué nos pierdes antes de que acabemos nuestros estudios. O incluso antes de que los empecemos, cuando nos enseñan que la ingeniería es “cosa de chicos”.

Bienvenido a nuestra triste realidad.

Nos gusta programar. Lo que no nos gusta es el trabajo que ofreces. Puede que el problema resida en cómo enfocas la pregunta. Deja de preguntarte por qué nosotras no aplicamos, y empieza a preguntarte…

 

¿Cómo puedo hacer mi oferta atractiva para las mujeres?

Aquí tienes algunos consejos:

 

  • Permite el trabajo en remoto sin límites

No te escondas tras “horarios flexibles”, “jornadas intensivas” o “remoting de vez en cuando si tienes una excusa”. Si quieres facilitar la conciliación, permite el trabajo en remoto todos los días. Adapta tu infraestructura para permitirlo. Se puede ser agile, hacer extreme programming e incluso generar sensación de equipo trabajando 100% en remoto, te lo digo por experiencia.

A cambio, tanto nosotras como ellos tendremos más tiempo para estar en casa compartiendo derechos y obligaciones.

 

  • Ofrece salarios competitivos

No nos infravalores. Si quieres que creamos de verdad que vamos a cobrar lo mismo que nuestros compañeros, publica los salarios de forma transparente (al menos de forma interna).

También valoramos beneficios como el seguro de salud privado y los cheques guardería, y seguridades como la estabilidad que ofrece tu proyecto.

 

  • No pidas requisitos mínimos

Muchas mujeres tienden a abstenerse ante una oferta de trabajo cuando no cumplen todos los requisitos mínimos especificados.

Sin embargo, tal vez no necesites ninguno de esos requisitos. En varias charlas he mencionado que el trabajo de un programador no consiste en picar código, sino en pensar.

Esto significa que no necesitas que la candidata sepa “Java”. Lo que necesitas es que sea una persona comunicativa, empática, profesional, resolutiva, responsable. Igual hasta te convence de que Java no es la herramienta que necesitas.

Otra estadística apunta a que las mujeres abandonamos las carreras STEM antes de acabarlas porque, entre otros factores, pensamos que ese no es nuestro sitio. Sin embargo, muchas estudiamos FP, somos autodidactas o nos hemos reinventado gracias a un bootcamp.

Por lo tanto, no pidas títulos universitarios. Estamos llenas de energía y ganas por obtener nuestro primer empleo, pero como en la oferta pone que se necesitan “ingenieros”, directamente no aplicamos.

 

  • Incluye mujeres en las entrevistas técnicas

Con esto no me refiero a que tengas una chica en RRHH. Me refiero a que incluyas una programadora en la entrevista técnica, en el code review, con voz y voto.

De esta forma tu candidata verá que en tu empresa hay otras compañeras y se sentirá más motivada a continuar con el proceso. Tal vez incluso se sienta más relajada durante la sesión de pairing, lo que os ayudará a descubrir su verdadero potencial.

 

  • No acapares su tiempo

No exijas que dediquen su tiempo libre a la programación. Las mujeres no tenemos demasiado tiempo libre ya que, aparte de trabajar, se nos atribuyen por defecto las tareas de cuidado del hogar y la familia.

Por lo tanto no esperes que dediquemos nuestro limitadísimo tiempo de ocio a hackear, a preparar charlas o a acudir a meetups por la tarde-noche o en fin de semana. Algunas lo hacemos y otras no, pero esto no significa que no nos apasione nuestro oficio ni que debas descartarnos por incompatibilidad cultural.

En cuanto a los estereotipos que nombro, luego hablaremos sobre formación.

 

  • Garantiza un ambiente seguro

No solo para contratar, sino también para mantener a las que hayas contratado. No queremos ni tenemos que “luchar” por nada. Estamos cansadas de tener que demostrar nuestra valía todos los días.

Queremos trabajar en entornos sanos, en los que se nos escuche sin necesidad de levantar la voz, en los que se nos dé credibilidad y se respete nuestra profesionalidad. Tenemos muchas ideas, explícanos qué foros nos ofreces para compartirlas: Retrospectivas, code reviews, global dev meetings…

Detalla también cómo de diverso es tu equipo técnico. No la empresa en general, sino en concreto tu equipo técnico. ¿Cuántas mujeres programadoras hay? ¿Qué acciones tomáis para que el entorno sea seguro? ¿Cómo evitáis los prejuicios de género en los procesos de selección?

 

  • Utiliza un lenguaje inclusivo

Supongo que es obvio, ¿no? Programadores y programadoras. Y si lo que buscas en concreto son mujeres, no lo maquilles. Redacta la oferta para una mujer.

 

Vale, ya tengo claro cómo redactar la oferta perfecta. Pero…

 

¿Cómo puedo encontrar talento femenino?

Igual que encuentras talento masculino: Buscándonos.

 

  • Búscanos

No te limites a preguntarle a tus amigos si conocen a alguna chica que quiera aplicar. Sé proactivo. Búscanos en redes sociales, páginas de empleo, universidades, centros de FP, bootcamps (¡incluso en la Devscola! ;)).

 

  • Contrata referentes

Preocúpate de buscarnos en la comunidad. Existen miles de comunidades dedicadas a visibilizar a las profesionales del sector, la más básica búsqueda por internet te devolverá una avalancha de nombres.

Ven a ver nuestras charlas. Asiste a eventos de visibilización. Es imposible que conozcas a mujeres programadoras si evitas este tipo de eventos o charlas. Que esté hecho por mujeres no significa que esté dirigido exclusivamente a mujeres.

 

  • Lidera el cambio

Predica con el ejemplo. Lidera vuestro compromiso con la diversidad acudiendo a cursos a través de los cuales aprendas a ponerte en la piel de una mujer y sentir cómo es nuestro día a día. El peso que cargamos, ocupándonos del trabajo y del hogar, luchando por defender nuestra valía, soportando comportamientos machistas a diario.

Promueve vuestra presencia en charlas impartidas por mujeres o en eventos de visibilización. Igual que quedáis para ir juntos al Codemotion, ¿por qué no quedar para ir al WTM?

 

  • Implícate

Si eres patrocinador, prioriza los eventos de visibilización y eventos con paridad entre ponentes. Si organizas charlas y talleres en tus oficinas, intenta que al menos la mitad de los ponentes sean mujeres. Propón tus propias iniciativas de visibilización.

De esta forma ayudarás a crear más referentes femeninas en las que la siguiente generación pueda fijarse. No hay mejor forma de conseguir que haya más mujeres programadoras.

 

Conclusión

El sector tecnológico es el que más puestos de trabajo genera, y el que mejor proyección a futuro tiene. Como mujeres no podemos permitir que nos expulsen de esa prometedora industria pero, a su vez, la industria no puede permitirse perder a la mitad del talento. Así que, por el bien de todos, actúa.

The Agile Breakfast

Do you know which is the best way to start the day? It’s a fact: A good day starts with a good breakfast. Don’t you agree?

This is the reason why every Tuesday morning we, people from Devscola, buy a bunch of food full of sugar and saturated fats and eat it while making what we like most: Coding. And this nutritional heresy received the name of Katayuno.

Katayuno is a combination of the words ‘Code Kata’ and ‘Desayuno‘. It is an event during which we sharpen our programming skills using code katas and Agile and XP methodologies, like pairing, TDD and code reviews.

But, what does ‘Agile’ and ‘XP’ refer to?

Continue reading “The Agile Breakfast”

Pair programming

This post belongs to this root post and may be out of context if it is read separately.

Pairing is a practice where two developers work together in the same computer. We can imagine it like a ride in a car: The driver manipulates the steering wheel and uses its driving skill, while her companion guides and supports her.

In the same way, during pairing, the driver uses the keyboard and writes the code, while the navigator guides her.

Continue reading “Pair programming”

Timebox

This post belongs to this root post and may be out of context if it is read separately.

Meetings

How many times have you entered a meeting thinking ‘oh my god, this will take hours. I have no idea around what time this meeting will end.‘ Many of us experienced this situation before.

Continue reading “Timebox”

Test Driven Development

This post belongs to this root post and may be out of context if it is read separately.

The Test Driven Development (TDD) is a software development technique that uses tests to make the design merge using the Red-Green-Refactor cycle.

How could I illustrate this…

Have you ever use a ‘gap filling’ exercise? They are used in grammar and language learning, and they look like this:

Gap filling exercise

Continue reading “Test Driven Development”

Retrospective

This post belongs to this root post and may be out of context if it is read separately.

The retrospective is a meeting during which the team discusses about the last three or four weeks. This is a conversation about factual subjects surrounding our work as a team. What did work? What did not work so well? What can we improve?

Continue reading “Retrospective”

Code it yourself

This post was titled after a talk I gave to people attending a course to learn how to develop software. One of the main purposes of my talk was to prevent wrong ideas about what software development really means.

In the past (and nowadays), the industry has considered programmers as ‘coding monkeys’, like if developing software was a repetitive task, similar to assembly lines in factories. But the truth is that the work of a programmer does not consist in writing code, but in THINKING. Thinking solutions that solve problems. It is a creative and adaptive job, therefore, the methodology used for repetitive tasks does not work for software development.

Continue reading “Code it yourself”

Indie games IV – Game design

This post is the first part of the talk I gave at IES Alfons III and belongs to this root post.

Now we know the employable tools, it’s time to get into the core. This post will be composed by two parts: Lifecycle and How to make it work.

The former makes a small tour around different steps that a game has, from its conception to its distribution, while the latter explains how to build a place on the market for your game.

Continue reading “Indie games IV – Game design”

Indie games

Last week I gave a talk about indie games at IES Alfons III in Vall d’Alba. One of its teachers saw my previous talk, where I was speaking about AI. He thought it could be interesting for students to learn about video game development, but he was not sure if they would understand a technical lesson. So we spoke on the phone and arranged a more suitable talk, focused on explaining video games creation and motivating students to choose a related career.

Continue reading “Indie games”

SOLID principles

I’m applying for a job in a frankly interesting company, so I’m reviewing all the good programming practices I was taught and learned during my career. Those are essential for developing good code, however an alarming number of “programmers” don’t really understand them (or actually never heard about them).

Continue reading “SOLID principles”

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑