Non che parece estraño que cando estás a piques de cambiar de traballo e xurde a necesidade de aprobar unha entrevista, o primeiro que pensas é "necesitas preparar a entrevista". Resolve problemas en HackerRank, le Crack a entrevista de codificación, memoriza como funciona ArrayList e en que se diferencia de LinkedList. Ah, si, tamén poderían preguntar sobre a clasificación e, obviamente, sería pouco profesional dicir que a clasificación rápida probablemente sería a mellor opción.
Pero espera, programas 8 horas ao día, resolves problemas interesantes e non triviais, e no teu novo traballo farás o mesmo, máis ou menos. Pero, non obstante, para aprobar unha entrevista, cómpre prepararse, nin sequera mellorar as súas habilidades diarias, senón aprender algo que non precisaba no seu traballo actual e que é improbable que necesite no próximo. Ás túas obxeccións de que a informática está no noso sangue, e se nos espertas no medio da noite, vémonos na obriga de escribir cos ollos pechados nunha funda de almofada un paseo polo ancho dunha árbore sen sequera recuperar a consciencia, eu responderá que se consigo un traballo no circo, e o meu principal o truco sería exactamente este; entón quizais si, estou de acordo. Esta habilidade debe ser probada.
Pero por que probar habilidades que son irrelevantes para o teu traballo actual? Só porque se puxo de moda? Porque Google fai isto? Ou porque o teu futuro xefe de equipo tivo que aprender todos os métodos de clasificación antes da entrevista e agora cre que "todo bo programador debe saber de memoria a implementación de atopar un palíndromo nunha cadea".
Ben, non es Google (c). O que Google pode permitirse, as empresas comúns non poden. Google, despois de analizar os datos dos seus empregados, chegou á conclusión de que os enxeñeiros con formación nas Olimpiadas son bos para xestionar as súas tarefas específicas. Ademais, ao deseñar o seu proceso de selección, poden permitirse o luxo de correr o risco de non contratar uns bos enxeñeiros porque non poden resolver problemas de matemáticas facilmente. Pero isto non é un problema para eles, hai moita xente que quere traballar en Google, o posto estará pechado.
Agora imos mirar pola fiestra e se diante da túa oficina os enxeñeiros que queren traballar para ti aínda non crearon un campamento de tendas e os teus desenvolvedores buscan con máis frecuencia a stackoverflow para a seguinte anotación de primavera que debe instalarse, en lugar das complejidades dos algoritmos de clasificación, entón, ao parecer, é hora de que penses se deberías copiar Google.
Ben, se esta vez Google fallou e non deu resposta, que deberías facer? Comproba exactamente o que fará o programador no traballo. Que valoras nos desenvolvedores?
Establece criterios para quen queres contratar e desenvolve probas que proben exactamente estas habilidades.
ThoughtWorks
Que ten que ver ThoughtWorks con isto? Foi aquí onde atopei un exemplo dunha entrevista exemplar para min. Quen son ThoughtWorks? En definitiva, trátase dunha consultora de gama alta con oficinas en todo o mundo, dende China, Singapur ata os continentes americanos, que leva uns 25 anos asesorando no campo do desenvolvemento, conta coa súa propia división Science, dirixida por Martin. Fowler. Se buscas unha lista de 10 libros imprescindibles para un enxeñeiro de software, quizais 2 ou 3 deles sexan escritos polos rapaces de ThoughtWorks, como Refactoring By Martin Fowler e Building Microservices: Designing Fine-Grained Systems de Sam Newman ou edificio de arquitecturas evolutivas
por Patrick Kua, Rebecca Parsons, Neal Ford.
O negocio da empresa baséase na prestación de servizos bastante caros, pero o cliente paga unha calidade fenomenal, que consiste en experiencia, estándares internos e, por suposto, persoas. Polo tanto, aquí é vital contratar as persoas adecuadas.
Que tipo de persoas teñen razón? Por suposto, hai diferentes para todos. ThoughtWorks determinou que os criterios máis importantes para o seu modelo de negocio para desenvolvedores son:
- Capacidade para desenvolverse en parellas. É capacidade, non experiencia ou habilidade. Ninguén espera que veña xente que leva 5 anos practicando a programación en parella, pero ser receptivo ás opinións dos demais e poder escoitar é unha habilidade necesaria.
- Capacidade para escribir probas, e idealmente practicar TDD
- Comprender SOLID e OOP e ser capaz de aplicalos.
- Presenta a túa opinión. Como consultor, hai que traballar cos desenvolvedores do cliente, con outros consultores, e non hai moito beneficio se unha persoa sabe facer algo ben, pero é completamente incapaz de transmitilo ao resto do equipo.
Agora é importante avaliar estas habilidades particulares do candidato. E aquí quero falar da miña experiencia de entrevistar en ThoughtWorks. Direi de inmediato que fun a Singapur e pasei, pero o proceso de contratación é unificado e non diferirá moito dun país a outro.
Fase 0. HR
Como adoita suceder, unha entrevista de 20 minutos con RRHH. Non me deterei niso, só direi que nunca coñecín a unha persoa de RRHH que puidese falar durante 15 minutos sobre a cultura de desenvolvemento na empresa, por que usan TDD, por que a programación en pares. Normalmente, os RR.HH. inciden nesta cuestión e din que o seu proceso é normal: os desenvolvedores desenvolven, os probadores proban, os xestores conducen.
Fase 1. Que bo é vostede en OOP, TDD?
1.5 horas antes do comezo da entrevista, enviáronme unha tarefa para facer un simulador de Mars Rover.
Misión rover a MarteUn escuadrón de rovers robóticos será aterrado pola NASA nunha meseta en Marte. Esta meseta, que é curiosamente rectangular, debe ser navegada polos rovers para que as súas cámaras a bordo poidan ter unha visión completa do terreo circundante para enviar de volta á Terra. A posición e localización dun rover está representada por unha combinación de coordenadas x e y e unha letra que representa un dos catro puntos cardinais do compás. A meseta está dividida nunha cuadrícula para simplificar a navegación. Unha posición de exemplo pode ser 0, 0, N, o que significa que o rover está na esquina inferior esquerda e mirando ao norte. Para controlar un rover, a NASA envía unha simple cadea de letras. As letras posibles son 'L', 'R' e 'M'. "L" e "R" fan que o rover xire 90 graos á esquerda ou á dereita, respectivamente, sen moverse do seu punto actual. "M" significa avanzar un punto da grella e manter o mesmo título.
Supoña que o cadrado directamente ao norte de (x, y) é (x, y+1).
ENTRADA:
A primeira liña de entrada son as coordenadas superior dereita da meseta, as coordenadas inferior esquerda suponse que son 0,0.
O resto da entrada é información relativa aos rovers que foron despregados. Cada rover ten dúas liñas de entrada. A primeira liña indica a posición do explorador e a segunda liña é unha serie de instrucións que lle indican ao explorador como explorar a meseta. A posición está formada por dous números enteiros e unha letra separados por espazos, correspondentes ás coordenadas x e y e á orientación do rover.
Cada rover terminarase secuencialmente, o que significa que o segundo rover non comezará a moverse ata que o primeiro remate de moverse.
SAÍDA:
A saída de cada rover debe ser as súas coordenadas e rumbo finais.
NOTAS:
Simplemente implementa os requisitos anteriores e demostra que unha aspiradora funciona escribindo probas unitarias para ela.
A creación de calquera forma de interface de usuario está fóra do alcance.
Será preferible resolver o problema seguindo un enfoque TDD (Test Driven Development).
No pouco tempo dispoñible, preocúpanos máis a calidade que a integridade.
*Non podo publicar a tarefa que me enviaron, esta é unha tarefa antiga que se deu hai varios anos. Pero créame, fundamentalmente todo segue igual.
Gustaríame chamar especialmente a atención sobre os criterios de avaliación. Cantas veces atopou unha situación na que as cousas que son importantes para un candidato non teñen importancia durante a auditoría e viceversa. Non todos pensan do mesmo xeito que ti, pero moitos poden aceptar e seguir os teus valores se están claramente establecidos. Polo tanto, a partir dos criterios de avaliación queda inmediatamente claro que as habilidades máis importantes nesta etapa son
- TDD;
- Capacidade para usar POO e escribir código mantible;
- habilidades de programación por parellas
Entón, avisáronme de que pasase esas 1.5 horas pensando en como ía facer a tarefa, en lugar de escribir código. Escribiremos o código xuntos.
Cando chamamos por teléfono, os mozos dixéronnos brevemente quen son e que fan e ofrecéronnos comezar o desenvolvemento.
Durante toda a entrevista, nunca tiven a sensación de estar sendo entrevistado. Hai a sensación de que estás a desenvolver código nun equipo. Se te quedas atrapado nalgún lugar, axudan, aconsellan, discuten e incluso discuten entre eles sobre a mellor forma de facelo. Na entrevista, esquecín como comprobar en JUnit 5 que un método lanza unha excepción: ofrecéronse a seguir escribindo a proba, mentres un deles buscaba en Google como facelo.
Literalmente unhas horas despois da entrevista, recibín comentarios construtivos: o que me gustou e o que non. No meu caso, eloxioume por usar clases Sealed como alternativa ao obxecto nulo; polo feito de que antes de escribir o código escribín en pseudocódigo como me gustaría controlar o rover, e así recibín un bosquexo das clases, polo menos as que están implicadas na API do robot.
Paso 2: Coméntanos
Unha semana antes da entrevista, pedíronme que preparase unha presentación sobre calquera tema que me interesase. O formato é sinxelo e familiar: 15 minutos de presentación, 15 minutos de resposta a preguntas.
Eu escollín Clean Architecture do tío Bob. E outra vez fun entrevistado por un par de persoas. Esta foi a miña primeira experiencia de presentación en inglés e, quizais, se estivera nunha situación estresante, non sería capaz de facerlle fronte. Pero de novo, nunca tiven a sensación de estar nunha entrevista. Todo é como sempre - dígolles, escoitan con atención. Incluso a tradicional sesión de preguntas e respostas non era como unha entrevista, estaba claro que as preguntas non se facían para "afundir", senón as que realmente lles interesaban na miña presentación.
Un par de horas despois da entrevista, recibín comentarios: a presentación foi moi útil e lles gustou moito escoitala.
Fase 3. Código de calidade da produción
Despois de advertirme de que esta era a última etapa das entrevistas técnicas, pedíronme que levase o código na casa a un estado listo para a produción, que enviase o código para a súa revisión e programase entrevistas nas que cambiarían os requisitos para a tarefa e o código requirir modificación. De cara ao futuro, podo dicir que a revisión do código realízase a cegas, os revisores descoñecen o posto para o que se presenta o candidato, non ven o seu currículo, nin sequera ven o seu nome.
Soou o teléfono, e outra vez había un par de rapaces ao outro lado do monitor. Todo é igual que na primeira entrevista: o principal é non esquecerse do TDD, contar o que fas e por que. Se non practicaches TDD antes, recoméndoche comezar a facelo de inmediato, non porque sexa necesario nas empresas, senón porque simplifica significativamente a túa vida, reduce o teu nivel de estrés se o desexa. Lembras como tiveches que buscar frenéticamente cun depurador un erro que só se pode reproducir a través do navegador, pero non podes reproducilo con probas? Agora imaxina que terás que detectar un erro así durante unha entrevista: tes garantido un par de canas. Que conseguimos con TDD? Cambiamos o código e inesperadamente decatámonos de que agora as probas son vermellas, pero cal é o erro que non podemos descubrir a primeira vez? Está ben, dicimos "Vaia" aos entrevistadores, preme Ctrl-Z e comeza a dar pequenos pasos adiante. E si, cómpre desenvolver a capacidade de desenvolverse usando TDD en ti mesmo, a capacidade de ir cara ao obxectivo para que as túas probas sexan permanentemente verdes, e non vermellas durante medio día, porque "tedes moito refactorización". Esta é exactamente a mesma habilidade que escribir código mantible ou escribir código produtivo.
Entón, o ben que se pode cambiar o teu código depende do deseño que teñas en mente para comezar, do sinxelo que sexa e do bos que sexan as túas probas.
Despois da entrevista, recibín comentarios en poucas horas. Nesta fase, decateime de que estaba case rematado e que quedaba moi pouco ata que "coñecín a Fowler".
Fase 4. Final. Basta de preguntas técnicas. Queremos saber quen es!
Para ser sincero, quedei algo desconcertado por esta formulación da pregunta. Como podes entender que tipo de persoa son nunha hora de conversa? E aínda máis, como podes entender isto cando falo unha lingua que non é a miña nativa e, a verdade, moi pésima e idiota. Nas entrevistas anteriores, persoalmente, era máis fácil para min falar que responder preguntas, e o acento era o culpable. Polo menos un dos entrevistadores era asiático, e o seu acento, ben, digamos, é algo específico do oído europeo. Por iso, decidín adoptar un enfoque proactivo: preparar unha presentación sobre min e ao comezo da entrevista ofrécese falar de min con esta presentación. Se están de acordo, polo menos haberá menos preguntas para min; se rexeitan a oferta, ben, 3 horas da miña vida dedicadas a unha presentación non son un prezo tan alto. Pero que debes escribir na túa presentación? Biografía - Nacido alí, naquel momento, foi á escola, licenciouse na universidade - pero a quen lle importa?
Se buscas en Google un pouco sobre a cultura Thoughtworks, atoparás un artigo de Martin Fowler [https://martinfowler.com/bliki/ThreePillars.html] que describe os 3 Pilares: Negocio Sostible, Excelencia de Software e Xustiza Social.
Supoñamos que xa se comprobou Software Excellence para min. Queda por mostrar Negocio Sostible e Xustiza Social.
Ademais, decidín centrarme neste último.
Para comezar, díxenlle por que ThoughtWorks: lin o blog de Martin Fowler na universidade, de aí o meu amor polo código limpo.
Tamén se poden presentar proxectos desde diferentes ángulos. Tamén desenvolveu un software para a medicina que simplificaba a vida dos pacientes e mesmo, segundo os rumores, salvou unha vida. Tamén desenvolvín software para bancos, que tamén facilitou a vida dos cidadáns. Sobre todo se este banco é utilizado polo 70% da poboación do país. Non se trata de Sberbank nin sequera de Rusia.
Queres saber de min? OK. A miña afección é a fotografía, dun xeito ou doutro levo uns 10 anos cunha cámara nas mans, hai fotografías que non me dá moita vergoña mostrar. Ademais, nun momento, axudei a un refuxio de gatos: fotografaba gatos que necesitaban un fogar permanente. E con boas fotografías é moito máis doado colocar un gato. Probablemente fotografei cen gatos :)
Ao final, o 80% da miña presentación estaba chea de gatos.
Inmediatamente despois da presentación, HR escribiume que aínda non coñecía os resultados da entrevista, pero toda a oficina xa estaba impresionada cos gatos.
En última instancia, agardei os comentarios: satisfei a todos como persoa.
Pero durante a conversación final, RRHH dixo con tacto que a Xustiza Social é moi boa e necesaria, pero non todos os proxectos son así. E preguntou se me daba medo. En xeral, paseime un pouco coa Xustiza Social, pasa :)
Total
Como resultado, levo varios meses traballando en Singapur en Thoughtworks, vexo que aquí demasiadas empresas están adoptando as “mellores prácticas de entrevista” de Google, empregando follas e pizarra para codificar, a pesar de que teñen máis coñecementos que Spring. , Symfony, RubyOnRails ( Subliña o que é necesario) non é necesario no traballo. Os enxeñeiros tómanse unha semana de descanso antes dunha entrevista para "prepararse".
En Thoughtworks, ademais dos requisitos adecuados para o candidato, os seguintes principios están á vangarda:
Alegría de entrevistar. Ademais, para os dous lados. De feito, se queres conseguir o mellor persoal (e quen non?), entón unha entrevista non é un mercado onde se elixen os escravos, senón un espectáculo onde o empresario e o candidato se avalían mutuamente. E se un candidato asocia emocións agradables cunha empresa, é probable que elixa esta empresa en particular
Múltiples entrevistadores para mitigar prexuízos. En Thoughtworks, a programación por parellas é o estándar de facto. E se esta práctica se pode aplicar a outras áreas, TW tenta facelo. En cada fase, a entrevista é realizada por 2 persoas. Así, cada persoa é avaliada por polo menos 8 persoas, e TW trata de seleccionar entrevistadores con diferentes formacións, diferentes direccións (non só técnicos) e xénero.
En definitiva, a decisión de contratación tomarase en función das opinións de polo menos 8 persoas, sen que ninguén teña voto de calidade.
Contratación por atributos En lugar de tomar unha decisión en función dos gustos ou aversións dun candidato, desenvólvese un formulario para cada función e cada etapa que inclúe os atributos que se están avaliando. Ao mesmo tempo, á hora de avaliar, é moi recomendable valorar non a experiencia nunha determinada habilidade, senón a capacidade de aplicala. Así, se un candidato non foi capaz de aplicar ningunha competencia, como TDD, pero, con todo, intenta aplicalas, escoita consellos sobre como usalas correctamente, ten todas as posibilidades de aprobar a entrevista.
Non se requiren certificados de estudos TW non require ningunha certificación ou educación en Informática. Só se avalían habilidades.
Esta é a primeira entrevista que teño con empresas estranxeiras para a que non tiven que preparar. Despois de cada etapa, non me sentía esgotada, senón que, pola contra, alegroume de poder aplicar as mellores prácticas, de que a xente do outro lado do monitor o valorase e as aplicase todos os días.
Despois de varios meses, podo dicir que as miñas expectativas se cumpriron plenamente. En que se diferencia ThoughtWorks dunha empresa normal? Nunha empresa normal podes atopar bos desenvolvedores e xente agradable, pero en TW a súa concentración está fóra das listas.
Se estás interesado en unirte a ThoughtWorks, podes ver as nosas posicións abertas
Tamén suxiro prestar atención ás vacantes interesantes:
Enxeñeiro de software principal: , , ,
Enxeñeiro Senior de Software: , , ,
Enxeñeiro informático: , ,
Técnico Superior de Datos:
Analista de calidade:
Infraestrutura: , ,
(Gustaríame advertirche honestamente de que a ligazón é unha ligazón de referencia, se vas a TW, recibirei un bonito extra). Elixe unha oficina que che guste, non tes que limitarte a Europa, ao fin e ao cabo, cada 2 anos TW estará encantado de trasladalo a outro país, porque... isto forma parte da política de ThoughtWorks, polo que se espalla e homoxeneiza a cultura.
Non dubides en facer preguntas nos comentarios ou pedirme recomendacións.
Se o tema parece interesante, escribirei sobre como é traballar en ThoughtWorks e como é a vida en Singapur.
Fonte: www.habr.com