¿No te parece extraño que cuando estás a punto de cambiar de trabajo y surge la necesidad de pasar una entrevista, lo primero que piensas es “hay que prepararse para la entrevista”? Resuelva problemas en HackerRank, lea Descifra la entrevista de codificación, memorice cómo funciona ArrayList y en qué se diferencia de LinkedList. Ah, sí, es posible que también pregunten sobre la clasificación, y obviamente sería poco profesional decir que la clasificación rápida probablemente sea la mejor opción.
Pero espera, programas 8 horas al día, resuelves problemas interesantes y no triviales, y en tu nuevo trabajo harás lo mismo, más o menos. Sin embargo, para pasar una entrevista, necesita prepararse adicionalmente de alguna manera, ni siquiera perfeccionar sus habilidades diarias, sino aprender algo que no necesitaba en su trabajo actual y que es poco probable que necesite en el próximo. A sus objeciones de que la informática está en nuestra sangre, y si nos despiertan en medio de la noche, nos vemos obligados a escribir con los ojos cerrados sobre una funda de almohada un paseo a lo ancho de un árbol sin siquiera recuperar el conocimiento, yo Responderé que si consigo un trabajo en el circo y mi principal truco sería exactamente este, entonces tal vez sí, estoy de acuerdo. Esta habilidad necesita ser puesta a prueba.
Pero ¿por qué poner a prueba habilidades que son irrelevantes para su trabajo actual? ¿Solo porque se puso de moda? ¿Porque Google hace esto? O porque su futuro líder de equipo tuvo que aprender todos los métodos de clasificación antes de la entrevista y ahora cree que "todo buen programador debe saber de memoria la implementación de la búsqueda de un palíndromo en una cadena".
Bueno, no eres Google (c). Lo que Google puede permitirse, las empresas comunes y corrientes no pueden hacerlo. Google, después de analizar los datos de sus empleados, llegó a la conclusión de que los ingenieros con experiencia en los Juegos Olímpicos son buenos para realizar sus tareas específicas. Además, al diseñar su proceso de selección, pueden darse el lujo de correr el riesgo de no contratar a algunos buenos ingenieros porque no pueden resolver problemas matemáticos fácilmente. Pero esto no es un problema para ellos, hay mucha gente que quiere trabajar en Google, el puesto estará cerrado.
Ahora miremos por la ventana, y si frente a su oficina los ingenieros que quieren trabajar para usted aún no han instalado un campamento y sus desarrolladores buscan con más frecuencia en stackoverflow qué próxima anotación de Spring debe instalarse, En lugar de las complejidades de los algoritmos de clasificación, entonces, aparentemente, es hora de que pienses si deberías copiar a Google.
Bueno, si esta vez Google falló y no dio respuesta, ¿qué debes hacer? Compruebe exactamente lo que hará el desarrollador en el trabajo. ¿Qué valoras en los desarrolladores?
Establezca criterios sobre quién desea contratar y desarrolle pruebas que evalúen exactamente estas habilidades.
ThoughtWorks
¿Qué tiene que ver ThoughtWorks con esto? Aquí es donde encontré un ejemplo de entrevista modelo para mí. ¿Quiénes son ThoughtWorks? En definitiva, se trata de una empresa de consultoría High End con oficinas en todo el mundo, desde China, Singapur hasta el continente americano, que asesora en el campo del desarrollo desde hace unos 25 años, tiene su propia división de Ciencias, encabezada por Martin. Cazador de aves. Si busca una lista de 10 libros de lectura obligada para un ingeniero de software, entonces quizás 2 o 3 de ellos estén escritos por los chicos de ThoughtWorks, como Refactoring de Martin Fowler y Building Microservices: Designing Fine-Grained Systems de Sam. Newman o la construcción de arquitecturas evolutivas
por Patrick Kua, Rebecca Parsons y Neal Ford.
El negocio de la empresa se basa en la prestación de servicios bastante caros, pero el cliente paga por una calidad fenomenal, que consiste en experiencia, estándares internos y, por supuesto, personas. Por lo tanto, contratar a las personas adecuadas es vital aquí.
¿Qué tipo de personas tienen razón? Por supuesto, los hay diferentes para cada uno. ThoughtWorks ha determinado que los criterios más importantes para su modelo de negocio de desarrollador son:
- Capacidad para desarrollarse en parejas. Es habilidad, no experiencia o habilidad. Nadie espera que venga gente que lleva 5 años practicando programación en Parejas, pero ser receptivo a las opiniones de los demás y saber escuchar es una habilidad necesaria.
- Capacidad para redactar exámenes e idealmente practicar TDD.
- Comprender SOLID y OOP y poder aplicarlos.
- Presenta tu opinión. Como consultor, hay que trabajar con los desarrolladores del cliente, con otros consultores, y no hay mucho beneficio si una persona sabe hacer algo bien, pero es completamente incapaz de transmitirlo al resto del equipo.
Ahora es importante evaluar estas habilidades particulares del candidato. Y aquí quiero hablar sobre mi experiencia al realizar entrevistas en ThoughtWorks. Diré de inmediato que fui a Singapur y aprobé, pero el proceso de contratación está unificado y no diferirá mucho de un país a otro.
Etapa 0. RRHH
Como suele suceder, una entrevista de 20 minutos con RR.HH. No me detendré en eso, solo diré que nunca he conocido a una persona de RR.HH. que pudiera hablar durante 15 minutos sobre la cultura de desarrollo en la empresa, por qué usan TDD, por qué la programación en pares. Por lo general, los RR.HH. se desaniman ante esta pregunta y dicen que su proceso es normal: los desarrolladores desarrollan, los evaluadores prueban, los gerentes conducen.
Etapa 1. ¿Qué tan bueno eres en POO, TDD?
Una hora y media antes del inicio de la entrevista, me enviaron la tarea de hacer un simulador de Mars Rover.
Misión del rover a MarteLa NASA aterrizará un escuadrón de rovers robóticos en una meseta de Marte. Los rovers deben recorrer esta meseta, que es curiosamente rectangular, para que sus cámaras a bordo puedan obtener una vista completa del terreno circundante y enviarla de regreso a la Tierra. La posición y ubicación de un rover está representada por una combinación de coordenadas xey y una letra que representa uno de los cuatro puntos cardinales de la brújula. 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 al norte. Para controlar un rover, la NASA envía una simple cadena de letras. Las letras posibles son 'L', 'R' y 'M'. 'L' y 'R' hacen que el rover gire 90 grados hacia la izquierda o hacia la derecha respectivamente, sin moverse de su punto actual. 'M' significa avanzar un punto de la cuadrícula y mantener el mismo rumbo.
Supongamos que el cuadrado directamente al norte de (x, y) es (x, y+1).
ENTRADA:
La primera línea de entrada son las coordenadas superior derecha de la meseta; se supone que las coordenadas inferior izquierda son 0,0.
El resto de la información es información relativa a los rovers que se han desplegado. Cada móvil tiene dos líneas de entrada. La primera línea proporciona 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 se compone de dos números enteros y una letra separados por espacios, correspondientes a las coordenadas xey y la orientación del rover.
Cada rover finalizará secuencialmente, lo que significa que el segundo rover no comenzará a moverse hasta que el primero haya terminado de moverse.
SALIDA:
La salida para cada rover debe ser sus coordenadas y rumbo finales.
NOTAS:
Simplemente implemente los requisitos anteriores y demuestre que una aspiradora funciona escribiendo pruebas unitarias para ella.
La creación de cualquier tipo de interfaz de usuario está fuera de alcance.
Se preferirá resolver el problema siguiendo un enfoque TDD (Test Driven Development).
En el poco tiempo disponible, nos preocupa más la calidad que la integridad.
*No puedo publicar la tarea que me enviaron, esta es una tarea antigua que me dieron hace varios años. Pero créanme, en el fondo todo sigue igual.
Me gustaría especialmente llamar la atención sobre los criterios de evaluación. ¿Cuántas veces se ha encontrado con una situación en la que las cosas que son importantes para un candidato carecen por completo de importancia durante la auditoría y viceversa? No todo el mundo piensa igual que tú, pero muchos pueden aceptar y seguir tus valores si están claramente establecidos. Entonces, de los criterios de evaluación queda inmediatamente claro que las habilidades más importantes en esta etapa son
- TDD;
- Capacidad para utilizar programación orientada a objetos y escribir código mantenible;
- habilidades de programación de pares
Entonces, me advirtieron que pasara esas horas y media pensando en cómo iba a realizar la tarea, en lugar de escribir código. Escribiremos el código juntos.
Cuando hablamos por teléfono, los muchachos nos dijeron brevemente quiénes son y qué hacen y se ofrecieron a comenzar el desarrollo.
Durante toda la entrevista, ni una sola vez tuve la sensación de que me estaban entrevistando. Da la sensación de que estás desarrollando código en equipo. Si te quedas atascado en algún lugar, te ayudan, aconsejan, discuten e incluso discuten entre ellos sobre la mejor manera de hacerlo. En la entrevista, olvidé cómo verificar en JUnit 5 que un método arroja una excepción: ofrecieron continuar escribiendo la prueba, mientras uno de ellos buscaba en Google cómo hacerlo.
Literalmente, unas horas después de la entrevista, recibí comentarios constructivos: lo que me gustó y lo que no. En mi caso, fui elogiado por usar clases selladas como alternativa al objeto nulo; por el hecho de que antes de escribir el código, escribí en pseudocódigo cómo me gustaría controlar el rover y así obtuve un bosquejo de las clases, al menos aquellas que están involucradas en la API del robot.
Paso 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 sencillo y familiar: 15 minutos de presentación, 15 minutos de respuesta a preguntas.
Elegí Clean Architecture del tío Bob. Y nuevamente fui entrevistado por un par de personas. Esta fue mi primera experiencia de presentación en inglés y, tal vez, si hubiera estado en una situación estresante, no habría podido afrontarla. Pero repito, nunca tuve la sensación de estar en una entrevista. Todo es como siempre, les digo, me escuchan atentamente. Incluso la tradicional sesión de preguntas y respuestas no fue como una entrevista, estaba claro que las preguntas no eran para “hundir”, sino aquellas que realmente les interesaban en mi presentación.
Un par de horas después de la entrevista, recibí comentarios: la presentación fue muy útil y realmente disfrutaron escuchándola.
Etapa 3. Código de calidad de producción.
Habiendo advertido que esta era la última etapa de las entrevistas técnicas, me pidieron que llevara el código en casa a un estado listo para producción, luego lo enviara para revisión y programara entrevistas en las que los requisitos para la tarea cambiarían y el código cambiaría. requieren modificación. De cara al futuro, puedo decir que la revisión del código se realiza a ciegas, los revisores no saben el puesto al que se postula el candidato, no ven su CV, ni siquiera ven su nombre.
Sonó el teléfono y nuevamente había un par de chicos al otro lado del monitor. Todo es igual que en la primera entrevista: lo principal es no olvidarse de TDD, contar a qué se dedica y por qué. Si no has practicado TDD antes, te recomiendo que empieces a hacerlo de inmediato, no porque sea necesario en las empresas, sino porque te simplifica significativamente la vida, reduce tu nivel de estrés si quieres. ¿Recuerda cómo tuvo que buscar frenéticamente con un depurador un error que solo se puede reproducir a través del navegador, pero no puede reproducirlo con pruebas? Ahora imagine que tendrá que detectar ese error durante una entrevista: tiene garantizados un par de canas. ¿Qué conseguimos con TDD? Cambiamos el código e inesperadamente nos dimos cuenta de que ahora las pruebas están en rojo, pero ¿cuál es el error que no podemos resolver la primera vez? Bien, decimos “Ups” a los entrevistadores, presionamos Ctrl-Z y comenzamos a dar pequeños pasos hacia adelante. Y sí, necesitas desarrollar la capacidad de desarrollarte usando TDD en ti mismo, la capacidad de ir hacia la meta para que tus pruebas estén permanentemente en verde y no en rojo durante medio día, porque "tienes mucha refactorización". Esta es exactamente la misma habilidad que escribir código mantenible o escribir código productivo.
Entonces, qué tan bien se puede cambiar su código depende del diseño que tenga en mente para empezar, qué tan simple es y qué tan buenas sean sus pruebas.
Después de la entrevista, recibí comentarios a las pocas horas. En esta etapa, me di cuenta de que casi había terminado y que quedaba muy poco hasta "conocer a Fowler".
Etapa 4. Final. Basta de preguntas técnicas. ¡Queremos saber quién eres!
Para ser honesto, esta formulación de la pregunta me desconcertó un poco. ¿Cómo puedes entender qué tipo de persona soy en una hora de conversación? Y más aún, ¿cómo se puede entender esto cuando hablo un idioma que no es mi lengua materna y, francamente, muy pésimo y sin palabras? En entrevistas anteriores, personalmente para mí era más fácil hablar que responder preguntas, y el acento era el culpable. Al menos uno de los entrevistadores era asiático y su acento, bueno, digamos, es algo específico del oído europeo. Por lo tanto, decidí adoptar un enfoque proactivo: preparar una presentación sobre mí y al comienzo de la entrevista ofrecerme hablar sobre mí con esta presentación. Si están de acuerdo, al menos habrá menos preguntas para mí; si rechazan la oferta, bueno, dedicar 3 horas de mi vida a una presentación no es un precio tan alto. Pero, ¿qué deberías escribir en tu presentación? Biografía - Nací allí, en aquella época, fui a la escuela, me gradué en la universidad - ¿pero a quién le importa?
Si busca un poco en Google sobre la cultura Thoughtworks, encontrará un artículo de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] que describe los 3 pilares: negocios sostenibles, excelencia en software y justicia social.
Supongamos que ya se ha verificado Software Excellence. Queda por mostrar Negocios Sostenibles y Justicia Social.
Además, decidí centrarme en este último.
Para empezar, le dije por qué ThoughtWorks: leí el blog de Martin Fowler en la universidad, de ahí mi amor por el código limpio.
Los proyectos también se pueden presentar desde diferentes ángulos. También desarrolló software para medicina que simplificó la vida de los pacientes e incluso, según los rumores, salvó una vida. También desarrollé software para bancos, lo que también facilitó la vida de los ciudadanos. Especialmente si este banco es utilizado por el 70% de la población del país. No se trata de Sberbank ni siquiera de Rusia.
¿Quieres saber sobre mi? DE ACUERDO. Mi hobby es la fotografía, de una forma u otra tengo una cámara en mis manos desde hace unos 10 años, hay fotografías que no me da vergüenza mostrar. Además, en un momento ayudé a un refugio para gatos: fotografié gatos que necesitaban un hogar permanente. Y con buenas fotografías es mucho más fácil ubicar un gato. Probablemente fotografié cien gatos :)
Al final, el 80% de mi presentación estuvo llena de gatos.
Inmediatamente después de la presentación, Recursos Humanos me escribió diciendo que aún no conocía los resultados de la entrevista, pero que toda la oficina ya estaba impresionada con los gatos.
Al final esperé comentarios: satisfice a todos como persona.
Pero durante la conversación final, RRHH dijo con tacto que la Justicia Social es muy buena y necesaria, pero que no todos los proyectos son así. Y me preguntó si me asustaba. En general me excedí un poco con la Justicia Social, sucede :)
Total
Como resultado, he estado trabajando en Thoughtworks en Singapur durante varios meses y veo que aquí muchas empresas están adoptando las "mejores prácticas de entrevista" de Google, utilizando hojas y Whiteboard para codificar, a pesar de tener más conocimientos que Spring. Symfony, RubyOnRails (subrayar lo necesario) no es necesario en el trabajo. Los ingenieros se toman una semana libre antes de una entrevista para "prepararse".
En Thoughtworks, además de los requisitos adecuados para el candidato, los siguientes principios están a la vanguardia:
Alegría de entrevistar. Además, para ambos lados. De hecho, si se quiere conseguir el mejor personal (¿y quién no?), entonces una entrevista no es un mercado donde se eligen esclavos, sino un espectáculo donde tanto el empleador como el candidato se evalúan mutuamente. Y si un candidato asocia emociones agradables con una empresa, es probable que elija esta empresa en particular.
Múltiples entrevistadores para mitigar el sesgo. En Thoughtworks, la programación en pareja es el estándar de facto. Y si esta práctica se puede aplicar a otros ámbitos, TW intenta hacerlo. En cada etapa, la entrevista la realizan 2 personas. Por lo tanto, cada persona es evaluada por al menos 8 personas, y TW intenta seleccionar entrevistadores con diferentes orígenes, diferentes direcciones (no solo técnicos) y género.
En última instancia, la decisión de contratación se tomará en base a las opiniones de al menos 8 personas, y ninguna tiene voto de calidad.
Contratación basada en atributos En lugar de tomar una decisión basada en lo que le gusta o no a un candidato, se desarrolla un formulario para cada rol y cada etapa que incluye los atributos que se evalúan. Al mismo tiempo, al evaluar, se recomienda encarecidamente evaluar no la experiencia en una determinada habilidad, sino la capacidad para aplicarla. Por lo tanto, si un candidato no pudo aplicar ninguna habilidad, como TDD, pero aún así intenta aplicarla, escucha consejos sobre cómo usarla correctamente, tiene todas las posibilidades de aprobar la entrevista.
Certificados de educación no requeridos TW no requiere ninguna certificación o educación en Ciencias de la Computación. Sólo se evalúan las habilidades.
Esta es la primera entrevista que tengo con empresas extranjeras para la que no tuve que prepararme. Después de cada etapa no me sentí agotado, al contrario, me alegré de poder aplicar las mejores prácticas, de que la gente al otro lado del monitor lo valorara y las aplicara todos los días.
Después de varios meses, puedo decir que mis expectativas se cumplieron plenamente. ¿En qué se diferencia ThoughtWorks de una empresa normal? En una empresa normal puedes encontrar buenos desarrolladores y gente agradable, pero en TW su concentración está fuera de serie.
Si está interesado en unirse a ThoughtWorks, puede ver nuestros puestos vacantes
También sugiero prestar atención a las vacantes interesantes:
Ingeniero de software líder: , , ,
Ingeniero de programación superior: , , ,
Ingeniero de software: , ,
Ingeniero de datos sénior:
Analista de calidad:
Infraestructura: , ,
(Me gustaría advertirte sinceramente que el enlace es un enlace de referencia, si vas a TW recibiré un buen bono). Elige una oficina que te guste, no tienes que limitarte a Europa, al fin y al cabo, cada 2 años TW estará encantado de trasladarte a otro país, porque... Esto es parte de la política de ThoughtWorks, por lo que la cultura se difunde y homogeneiza.
No dudes en hacer preguntas en los comentarios o pedirme recomendaciones.
Si el tema parece interesante, escribiré sobre cómo es trabajar en ThoughtWorks y cómo es la vida en Singapur.
Fuente: habr.com