¿No les parece extraño que cuando están a punto de cambiar de trabajo y necesitan pasar una entrevista, lo primero que piensan es 'debo prepararme para la entrevista'? Resolver problemas en HackerRank, leer Crack the Coding Interview, memorizar cómo funciona un ArrayList y en qué se diferencia de un LinkedList. Ah, sí, también pueden preguntar sobre algoritmos de ordenación, y sería poco profesional decir que el quick sort probablemente será la mejor opción.
Pero esperen, ustedes programan 8 horas al día, resuelven problemas interesantes y no triviales, y en su nuevo trabajo harán más o menos lo mismo. Sin embargo, para pasar la entrevista, es necesario prepararse adicionalmente, incluso no se trata de perfeccionar habilidades diarias, sino de aprender lo que no han necesitado en su trabajo actual y que difícilmente necesitarán en el siguiente. A sus objeciones de que la informática está en nuestra sangre, y que si nos despiertan en medio de la noche debemos escribir a ciegas en una almohada cómo recorrer un árbol en anchura sin siquiera tomar conciencia, les responderé que si voy a trabajar en un circo y mi truco principal es precisamente eso, entonces quizás sí, estoy de acuerdo. Es necesario comprobar esta habilidad.
Pero, ¿por qué comprobar habilidades que no son relevantes para el trabajo actual? ¿Solo porque se ha vuelto una moda? ¿Porque Google lo hace? ¿O porque a su futuro líder de equipo le tocó aprender todos los métodos de ordenación antes de pasar la entrevista y ahora piensa que 'cada buen programador debe saber de memoria la implementación para detectar un palíndromo en una cadena'?
Entonces, ustedes no son Google (c). Lo que Google puede permitirse, las empresas normales no pueden. Google, analizando los datos de sus empleados, llegó a la conclusión de que, específicamente para sus tareas, es efectivo contar con ingenieros con un pasado en olimpiadas. Además, al construir el proceso de selección, pueden permitirse asumir el riesgo de no contratar a varios buenos ingenieros porque no pueden resolver problemas matemáticos con tanta facilidad. Pero para ellos, eso no es un problema, hay mucha gente deseando trabajar en Google, el puesto se llenará.
Ahora echemos un vistazo por la ventana, y si frente a su oficina aún hay ingenieros deseando trabajar para usted, que no han levantado un campamento, y sus desarrolladores buscan más en stackoverflow qué anotación de Spring necesitan implementar, en lugar de las sutilezas de los algoritmos de clasificación, entonces, probablemente, sea hora de considerar si vale la pena copiar a Google.
Bien, si esta vez Google falló y no proporcionó una respuesta, ¿qué hacer? Verificar exactamente lo que el desarrollador hará en el trabajo. ¿Qué valora en los desarrolladores?
Establezca criterios sobre a quién desea contratar y desarrolle pruebas que evalúen precisamente las habilidades que busca.
ThoughtWorks
¿Y qué tiene que ver ThoughtWorks con esto? Precisamente aquí encontré un ejemplo de entrevista ejemplar. ¿Quiénes son ThoughtWorks? En pocas palabras, es una compañía de consultoría de alto nivel con oficinas en todo el mundo, desde China y Singapur hasta los continentes americanos, dedicada a la consultoría en el ámbito del desarrollo desde hace aproximadamente 25 años, contando con su división de Ciencia, dirigida por Martin Fowler. Si busca una lista de 10 libros que todo ingeniero de software debe leer, seguramente 2-3 de ellos serán escritos por gente de ThoughtWorks, como por ejemplo 'Refactoring' de Martin Fowler y 'Building Microservices: Designing Fine-Grained Systems' de Sam Newman, o 'Building Evolutionary Architectures'.
por Patrick Kua, Rebecca Parsons, Neal Ford.
El negocio de la empresa se basa en ofrecer servicios bastante costosos, pero el cliente paga por una calidad fenomenal, que proviene de la experiencia, los estándares internos y, por supuesto, las personas. Por lo tanto, es vital contratar a las personas adecuadas aquí.
¿Pero quiénes son las personas adecuadas? Por supuesto, para cada uno son diferentes. ThoughtWorks ha determinado que para su modelo de negocio, los criterios más importantes para los desarrolladores son:
- La capacidad de trabajar en pareja. Específicamente, la capacidad, no la experiencia o habilidad. Nadie espera que lleguen personas que han practicado el Pair programming durante 5 años. Pero ser receptivo a la opinión de los demás, saber escuchar, es una habilidad necesaria.
- La habilidad de escribir pruebas, y en ideal, practicar TDD.
- Entender SOLID y OOP y poder aplicarlos.
- Presentar su opinión. Como consultor, se trabaja con los desarrolladores del cliente, con otros consultores, y no hay mucho beneficio si una persona puede hacer algo bien, pero es completamente incapaz de comunicárselo a los demás miembros del equipo.
Ahora es importante evaluar estas habilidades en el candidato. Aquí quiero compartir mi experiencia en la entrevista en ThoughtWorks. Para ser claro, la hice en Singapur y la superé, pero el proceso de reclutamiento es unificado y no diferirá mucho de un país a otro.
Etapa 0. RRHH
Como suele suceder, una entrevista de 20 minutos con RRHH. No me detendré en esto, solo diré que nunca había conocido a un RRHH que pudiera hablar 15 minutos sobre la cultura de desarrollo en la empresa, por qué aplican TDD, por qué la programación en pareja. Normalmente, en esta cuestión, los de RRHH se desinflan y dicen que su proceso es normal: los desarrolladores desarrollan, los testers prueban, los gerentes presionan.
Etapa 1. ¿Qué tan bueno eres en OOP, TDD?
1.5 horas antes del inicio de la entrevista, me enviaron la tarea de crear un simulador de Mars Rover.
Tarea de Mars RoverUn escuadrón de rovers robóticos debe ser aterrizado por la NASA en una meseta en Marte. Esta meseta, que es curiosamente rectangular, debe ser navegada por los rovers para que sus cámaras a bordo puedan obtener una vista completa del terreno circundante para enviarla de vuelta a la Tierra. La posición y ubicación de un rover se representan mediante una combinación de coordenadas x e y y una letra que representa uno de los cuatro puntos cardinales. La meseta está dividida en una cuadrícula para simplificar la navegación. Una posición de ejemplo podría ser 0, 0, N, lo que significa que el rover está en la esquina inferior izquierda y mirando hacia el Norte. Para controlar un rover, la NASA envía una simple cadena de letras. Las posibles letras son ‘L’, ‘R’ y ‘M’. ‘L’ y ‘R’ hacen que el rover gire 90 grados a la izquierda o a la derecha respectivamente, sin moverse de su posición actual. ‘M’ significa avanzar un punto en la cuadrícula y mantener la misma dirección.
Suponga que el cuadrado directamente al norte de (x, y) es (x, y+1).
ENTRADA:
La primera línea de entrada son las coordenadas superiores derechas de la meseta, se asume que las coordenadas inferiores izquierdas son 0,0.
El resto de la entrada es información relativa a los rovers que han sido desplegados. Cada rover tiene dos líneas de entrada. La primera línea ofrece la posición del rover y la segunda línea es una serie de instrucciones que le indican al rover cómo explorar la meseta. La posición consta de dos enteros y una letra separados por espacios, correspondientes a las coordenadas x e y y la orientación del rover.
Cada rover terminará secuencialmente, lo que significa que el segundo rover no comenzará a moverse hasta que el primero haya terminado.
SALIDA:
La salida para cada rover debe ser sus coordenadas finales y dirección.
NOTAS:
Simplemente implemente los requisitos anteriores y demuestre que un aspirador funciona escribiendo pruebas unitarias para ello.
Crear cualquier forma de interfaz de usuario está fuera del alcance.
Se preferirá resolver el problema siguiendo un enfoque TDD (Desarrollo Guiado por Pruebas).
En el poco tiempo disponible, nos preocupa más la calidad que la completitud.
*No puedo publicar la tarea que me enviaron, es una tarea antigua que se dio hace varios años. Pero créanme, el principio sigue siendo el mismo.
Es importante prestar atención a los criterios de evaluación. ¿Cuántas veces te has encontrado en la situación en la que cosas que son importantes para el candidato son irrelevantes al momento de la revisión, y viceversa? No todos piensan igual que tú, pero muchos pueden adoptar tus valores y seguirlos si están claramente definidos. Así que, a partir de los criterios de evaluación, queda claro que las habilidades más importantes en esta etapa son
- TDD;
- La habilidad de utilizar OOP y escribir código mantenible;
- la capacidad para la programación en pareja
Así que, me advirtieron que debía dedicar estas 1.5 horas a reflexionar sobre cómo iba a abordar la tarea, en lugar de escribir código. El código lo escribiremos juntos.
Cuando nos contactamos, los chicos me contaron brevemente quiénes eran y qué hacían, y propusieron comenzar con el desarrollo.
Durante toda la entrevista, en ningún momento sentí que estuviera en una entrevista. Hay una sensación de que estás desarrollando código en equipo. Si te quedas atascado en algún lugar, ellos ayudan, aconsejan, discuten, incluso debaten entre ellos sobre la mejor manera de hacerlo. En la entrevista, olvidé cómo comprobar en JUnit 5 que un método lanza una excepción; ellos sugirieron seguir escribiendo la prueba, mientras uno de ellos buscaba cómo hacerlo.
Literalmente unas horas después de la entrevista, recibí retroalimentación constructiva sobre lo que les gustó y lo que no. En mi caso, me elogiaron por usar clases selladas como alternativa a null; por escribir un pseudocódigo sobre cómo me gustaría controlar el rover, lo que me dio un esquema de clases, al menos de las que se utilizan en la API del robot.
Fase 2. Cuéntanos
Una semana antes de la entrevista, me pidieron que preparara una presentación sobre cualquier tema que me interesara. El formato es simple y familiar: 15 minutos de presentación, 15 minutos de preguntas y respuestas.
Elegí Clean Architecture de Uncle Bob. Y de nuevo fui entrevistado por un par de personas. Esta fue mi primera experiencia presentando en inglés y, seguramente, si hubiera estado en una situación estresante, no habría podido manejarlo. Pero, nuevamente, en ningún momento tuve la sensación de estar en una entrevista. Todo como de costumbre: yo hablo, ellos escuchan atentamente. Incluso la tradicional sesión de preguntas y respuestas no se parecía a una entrevista, era evidente que las preguntas no se hacían para 'hundirme', sino que realmente les interesaban respecto a mi presentación.
Un par de horas después de la entrevista recibí comentarios: la presentación fue muy útil y disfrutaron sinceramente escuchándola.
Etapa 3. Código de Calidad de Producción
Advirtiendo que esta era la última etapa de las entrevistas técnicas, me pidieron que dejara el código en casa listo para producción, después de lo cual enviaría el código para revisión y programaría entrevistas en las que los requisitos para la tarea cambiarían y el código requeriría modificaciones. Anticipándome, puedo decir que la revisión del código se lleva a cabo a ciegas, los revisores no conocen ni la posición a la que aspira el candidato, ni ven su CV, ni siquiera ven su nombre.
Llamada, y una vez más un par de chicos al otro lado de la pantalla. Todo como en la primera entrevista: lo principal es no olvidar sobre TDD, contar lo que haces y por qué. Si antes no has practicado TDD, te recomiendo que comiences a hacerlo de inmediato, no porque sea necesario en las empresas, sino porque simplifica enormemente tu vida y reduce el nivel de estrés, si así lo quieres. ¿Recuerdas cómo tenías que buscar desesperadamente un error con el depurador que solo se reproducía en el navegador, y no podías reproducirlo con las pruebas? Ahora imagina que tienes que atrapar un error así durante la entrevista; un par de canas te están aseguradas. ¿Qué nos garantiza TDD? Cambias el código y, sorprendentemente, te das cuenta de que ahora las pruebas están fallando, y no logras entender el error a la primera. Está bien, le decimos a los entrevistadores 'Ups', presionamos Ctrl-Z y comenzamos a avanzar paso a paso. Y sí, la habilidad de desarrollar utilizando TDD hay que cultivarla, la habilidad de avanzar hacia el objetivo de modo que tus pruebas estén permanentemente en verde, y no en rojo durante medio día porque 'tienes una gran refactorización'. Es exactamente la misma habilidad que tener la capacidad de escribir código mantenible o de escribir código eficiente.
Así que, cuán bien se puede modificar tu código depende del diseño que inicialmente implementaste, de cuán simple es, y de cuán buenos son tus pruebas.
Después de la entrevista, recibí feedback en unas pocas horas. En esta etapa, entendí que prácticamente había pasado y que solo quedaba un poco para la 'reunión con Fowler'.
Etapa 4. Final. Suficientes preguntas técnicas. ¡Queremos saber quién eres!
Honestamente, esta formulación de la pregunta me dejó algo perplejo. ¿Cómo se puede entender qué tipo de persona soy en una hora de conversación? Y mucho menos, ¿cómo se puede comprender esto cuando hablo en un idioma que no es el mío, y, para ser sincero, lo hago de forma bastante torpe y poco clara? En las entrevistas anteriores, a mí me resultaba más fácil contar que responder a las preguntas, y la culpa la tenía el acento. Al menos uno de los entrevistadores era asiático — y su acento, digamos que es un poco peculiar para el oído europeo. Así que decidí adoptar un enfoque proactivo: preparar una presentación sobre mí y, al comienzo de la entrevista, ofrecerla para que me hablaran de mí con esa presentación. Si aceptan, al menos habrá menos preguntas para mí y si rechazan la oferta, bueno, tres horas de mi vida dedicadas a la presentación — no es un precio tan alto. Pero, ¿qué escribir en la presentación? ¿Una biografía? — Nací aquí y allá, fui a la escuela, terminé la universidad — ¿a quién le interesa eso?
Si buscas un poco sobre la cultura de Thoughtworks, puedes encontrar el artículo de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html], en el que se describen los 3 Pilares: Negocios Sostenibles, Excelencia en Software y Justicia Social.
Supongamos que ya han comprobado mi Excelencia en Software. Solo me queda mostrar Negocios Sostenibles y Justicia Social.
Decidí enfocarme en este último.
Para empezar, expliqué por qué ThoughtWorks — ya en la universidad, leía el blog de Martin Fowler, de ahí mi amor por el Código Limpio.
Los proyectos también se pueden presentar desde diferentes ángulos. Desarrollé software para la medicina que facilitó la vida de los pacientes, e incluso, según rumores, salvó una vida. También desarrollé software para bancos, que también es una forma de simplificar la vida de los ciudadanos. Especialmente si ese banco es utilizado por aproximadamente el 70 % de la población del país. No hablo de Sberbank ni siquiera de Rusia.
¿Quieres saber más de mí? De acuerdo. Mi pasatiempo es la fotografía; de alguna manera, he tenido una cámara en mis manos durante unos 10 años, tengo fotos que no me da vergüenza mostrar. También, en un momento, ayudé a un refugio de gatos: fotografiaba gatos que necesitaban un hogar permanente. Con buenas fotos, es mucho más fácil adoptar un gato. Probablemente, he fotografiado a unos cien gatos 🙂
Al final, el 80 % de mi presentación estaba lleno de gatos.
Just after the presentation, the HR wrote to me that he still doesn't know the interview results, but the whole office is already impressed with the cats.
In the end, I received feedback — I satisfied everyone as a person.
However, the HR tactfully mentioned in the final conversation that Social Justice is very good and necessary, but not all projects are like that. He asked if it scared me. In general, I may have overdone it a bit with Social Justice, it happens 🙂
Summary
As a result, I have been working in Singapore at Thoughtworks for several months now, and I see that many companies here adopt the 'best interview practices' from Google, using little sheets and Whiteboards for coding, while knowledge beyond Spring, Symfony, RubyOnRails (underline what’s needed) is not required at work. Engineers take a week off before the interview to 'prepare.'
At Thoughtworks, in addition to reasonable requirements for candidates, the following principles are prioritized:
Joy of Interviewing. For both parties. Indeed, if you want to attract the best talent (and who doesn’t?), the interview is not a marketplace where slaves are chosen, but a viewing where both the employer and the candidate assess each other. And if the candidate associates pleasant emotions with the company, it is quite likely that he will choose this very company.
Multiple interviewers to mitigate bias. At Thoughtworks, pair programming is the de facto standard. And if this practice can be applied in other areas, TW tries to do so. At each stage, the interview is conducted by 2 people. Thus, each candidate is evaluated by at least 8 people, and TW tries to select interviewers with different backgrounds, various fields (not just techies), and genders.
Ultimately, the hiring decision will be made based on the opinion of at least 8 people, and no one has the right to a decisive vote.
Attribute-based hiring En lugar de tomar decisiones basadas en lo que le gusta o no al candidato, se ha diseñado un formulario para cada puesto y cada etapa que incluye los atributos a evaluar. En este sentido, se recomienda encarecidamente valorar no la experiencia en una habilidad específica, sino la capacidad de aplicarla. Así, si un candidato no ha tenido la oportunidad de aplicar ciertas habilidades, como TDD, pero, sin embargo, intenta aplicarlas y escucha consejos sobre su uso correcto, tiene todas las posibilidades de pasar la entrevista.
Certificados educativos no requeridos TW no exige a los candidatos certificados obligatorios ni educación en Ciencias de la Computación. Se valoran solo las habilidades.
Esta es la primera entrevista, de las que he tenido en empresas extranjeras, para la que no tuve que prepararme. Después de cada etapa, no me sentí exprimido como un limón, sino todo lo contrario, estaba contento de poder aplicar las mejores prácticas, de que la gente al otro lado de la pantalla las valora y también las utiliza cada día.
Después de unos meses, puedo decir que las expectativas se han cumplido completamente. ¿Qué diferencia a ThoughtWorks de una empresa convencional? En una empresa convencional puedes encontrar buenos desarrolladores y personas agradables, pero en TW su concentración es abrumadora.
Si deseas unirte a ThoughtWorks, puedes ver las vacantes abiertas
También sugiero prestar atención a vacantes interesantes:
Ingeniero de Software Senior: , , ,
Ingeniero de Software: , , ,
Ingeniero de Software: , ,
Ingeniero de Datos Senior:
Analista de Calidad:
Infraestructura: , ,
(Quiero advertir honestamente que el enlace es referencial, si ingresas a TW, recibiré un bonito bono). Elige la oficina que prefieras, no es necesario limitarse solo a Europa, al fin y al cabo, cada 2 años TW estará feliz de trasladarte a otro país, ya que es parte de la política de ThoughtWorks, de esta manera la cultura se expande y se normaliza.
No dudes en hacer preguntas en los comentarios o pedirme que te recomiende.
Si el tema te parece interesante, escribiré sobre cómo es trabajar en ThoughtWorks y cómo es la vida en Singapur.
Fuente: habr.com
