¡Hola a todos, javarashitas! Dio la casualidad de que recientemente tuve una entrevista y me gustaría contarles qué preguntas me hicieron asumiendo que estaba postulando para el puesto Junior++. Aquellos. Todavía no es un medio, pero tampoco un junior verde. Entonces, la entrevista transcurrió de acuerdo con este plan.
- JavaCore
- Base de datos.
- Las herramientas que utilizas.
JavaCore
- Excepciones. Aquí nuevamente se nos pidió que dibujáramos una jerarquía de excepciones, qué tipos hay, cuáles están marcadas y cuáles no. Qué hacer con las excepciones en tiempo de ejecución. Nombra la que se encuentra con más frecuencia (NullPointerException).
Primero, me pidieron que dibujara la jerarquía de interfaces para Colecciones (no fue difícil, solo hay unas pocas (Colección, Lista, Conjunto, Cola, Mapa).
¿Cuál es la diferencia entre ArrayList y LinkedList (esta es una de las preguntas y respuestas más trilladas en Internet, simplemente oscuridad)?
Discutimos la velocidad de ejecución de consultas en ellos y cuál es la diferencia entre las hojas.
Pregunta sobre la clase Objeto. ¿Cuáles son sus métodos, qué hacen?
Reflexión. Qué hace el método getClass(). Pregunta muy interesante, por favor investigue. Especialmente sobre cómo obtener todo lo relacionado con una clase, incluso si contiene variables o métodos privados.
Preguntaron sobre subprocesos múltiples. Creo que es débil decirte cómo entiendes qué es el subproceso múltiple. Lo que se necesita para iniciar un nuevo hilo. De manera realista, si tienes nivel 20+, estas preguntas te parecerán divertidas.
¿Qué puedes decir sobre Stream? No se trata de Java 8. Se trata de flujos de entrada y salida. Como interfaces básicas, qué son (carácter y byte). Para entenderlo, no hay detalles.
La pregunta es qué se debe hacer con las excepciones marcadas (avanzar más o procesar; ambos son claros).
POO
¿Qué es la POO en pocas palabras?
¿Qué otros paradigmas de programación existen? ¿En qué se diferencian de la programación orientada a objetos?
¿Cuáles son los principios básicos de la programación orientada a objetos (herencia, polimorfismo y encapsulación)? Cuéntanos sobre cada uno de ellos. Hasta ahora todo es abstracto, no ligado a ningún idioma.
Tarea de comprensión del diseño del sistema: hay un caballo y un pájaro. Necesitamos atrapar a Pegaso. principio "tiene un" y "es un"
DESCANSAR
¿Qué es el DESCANSO? Wikipedia habla de esto con mucha frialdad. De hecho, un artículo de Wikipedia es suficiente para familiarizarse.
HTTP. También hay frases generales aquí. Sus métodos, para qué sirve cada uno de ellos.
Códigos de estado HTTP. En qué cinco partes se deben dividir, cuéntanos cuáles son las más famosas (200,204,404,500,501). ¿Por que lo hacen? También preguntaron por 401 y 403. Pero yo no los conocía. Dijeron que eran importantes.
Base de datos
Aquí les dije que conozco MySQL. Habló de las tres formas normales. Hablé sobre las uniones, qué son y dibujé la intersección de áreas en las que se utilizan diferentes uniones. Hablé sobre cómo entiendo una base de datos relacional. Tampoco me olvidé de MongoDB: esta es una base de datos NoSQL. , escribiré sobre eso también.Otras herramientas
Aquí revisamos mi currículum. Estaba escrito que uso Maven/Gradle para ensamblar, uso JIRA para tareas, git, Docker, Swagger. Para una integración continua: Stash, Bamboo, Puppet. Para probar JUnit, Mockito, JMeter. Puede que haya olvidado algo, así que si estás interesado... pregunta en los comentarios Intentaré responder. Esta fue la primera parte de la entrevista. Ahora estoy esperando los resultados y si es así, habrá segunda parte. Escribiré sobre ello lo antes posible. Cualquiera a quien le haya gustado el artículo y lo haya encontrado útil, escriba "+". Escribe en los comentarios. Vea también mis otros artículos:Vistas: 805
En Internet se derrama mucho dolor por las entrevistas fallidas. A algunos no les gustaron las preguntas de los entrevistadores, a otros les ofendió el ridículo, a otros los juzgaron basándose en su página de VKontakte. Los entrevistadores siguen el ritmo de los candidatos y maldicen lo mala que es la situación del personal hoy en día y las respuestas estúpidas que dan los programadores sin experiencia a sus difíciles preguntas técnicas.
Desafortunadamente, no existen reglas universales para aprobar y realizar entrevistas, y no pueden existir, porque los empleados son seleccionados no sólo por sus habilidades técnicas y cualidades personales, sino también por su correspondencia con algún "perfil" (a menudo implícito y muy subjetivo), que, según para los entrevistadores, encaja en su equipo o empresa. En cuanto a las guías de la serie "Cómo pasar las entrevistas correctamente", no suelen causar menos dolor en los comentarios, porque son muy subjetivas y seguramente tocarán los puntos débiles de alguien.
A lo largo de mi carrera profesional he estado en ambos lados de la valla, aunque probablemente he tenido que hacer entrevistas un poco más técnicas que pasarlas. Pero durante este tiempo he acumulado una serie de "modas pasajeras" que me asustan durante una entrevista técnica e inmediatamente en mi mente ponen fin a una conversación posterior. De esto es de lo que quería hablar, desde la perspectiva del entrevistador y del solicitante. Me gustaría hacer una reserva de inmediato: el artículo refleja mis impresiones subjetivas personales y no pretende ser una "guía de entrevistas". Por otro lado, esto no es un estallido momentáneo de ira por una entrevista fallida, sino un conjunto de criterios ponderados durante mucho tiempo que, aunque sean negativos, me permiten descartar opciones o no asustar a un candidato potencialmente adecuado. mí mismo.
¿Qué te irrita o estresa durante las entrevistas? Comparte en los comentarios.
Entrevista desde la perspectiva del solicitante.
Cada vez que un programador busca trabajo, tiene que pasar por muchas entrevistas técnicas. Camina por las oficinas o habla por Skype, resuelve problemas o realiza exámenes, responde preguntas técnicas difíciles, tratando de demostrar su mejor lado. Sin embargo, él mismo también evalúa a las personas que lo entrevistan y lo prueban, pensando que mañana potencialmente tendrá que trabajar con estas personas. Y hay muchas formas en que los entrevistadores técnicos pueden asustar a un candidato y alejarlo de un puesto interesante. Hablaré de lo que siempre me ha asustado personalmente y de lo que trato de evitar como entrevistador.1. “¿Qué otra entrevista técnica?”
Lo primero y más importante que siempre me ha alarmado de una entrevista técnica es su ausencia. Sucede que toda la conversación con los especialistas técnicos, potencialmente futuros colegas, se basa en preguntas sobre la experiencia profesional: dónde trabajó, en qué proyectos trabajó, qué función desempeñó en ellos. En cuanto a tecnología o conocimiento, preguntas al nivel de "de qué color es el libro de texto". ¿Sabes qué es un Message Broker? ¡Genial, te llevamos!Este enfoque de las entrevistas siempre me ha puesto en contra de un posible empleador. No me hicieron ni una sola pregunta para comprobar que realmente sabía lo que hacía. Parece que las personas que me entrevistan no entienden nada sobre el tema y buscan al menos a una persona que lo entienda, o simplemente están desesperadas y dispuestas a enfrentarse a cualquiera. En cualquier caso, no me gustaría trabajar en un equipo así contratado.
2. “Bueno, ¿qué hacías ahí en ese…”?
Es sorprendente la frecuencia con la que se producen actitudes desdeñosas hacia los solicitantes durante las entrevistas técnicas. Sí, tal vez usted sea un programador severo y experimentado con un montón de proyectos en su haber, lo apartaron de un trabajo extremadamente importante por algunas entrevistas innecesarias con personas, la mayoría de las cuales, en su opinión, son completamente incompetentes. Pero no olvides que en este momento estás representando a tu empresa y a tu equipo, y una persona definitivamente hará una valoración en base a tu comportamiento sobre el clima en el equipo y cómo lo tratarán en este equipo. Sea cortés y respetuoso con el solicitante, incluso si desde los primeros cinco minutos se dio cuenta de que no se le debe permitir acercarse a su precioso código.3. “¡Su nombre/apellido/patronímico está escrito incorrectamente en su currículum!”
Esto no es nada técnico, pero, sin embargo, es un problema común incluso en las entrevistas técnicas. Afortunadamente, tengo un nombre bastante simple y común, y ese tipo de problemas no me han sucedido. Sin embargo, sé que hay un número sorprendente de personas que creen firmemente que ciertos nombres e incluso patronímicos simplemente no existen. Te convencerán de que el nombre correcto no es “Danila”, sino “Daniil”, o que no existe el nombre “Alena”, sino sólo “Elena”. Se ofrecerán a corregir y escribir “correctamente” en sus documentos. Las personas con nombres raros o inusuales a menudo tienen que tratar con personas tan alfabetizadas y bien intencionadas, y créanme, es increíblemente molesto. Entonces, hay una regla simple: no existen nombres que no existan. Escriba correctamente como está escrito en el pasaporte. Muestre respeto al solicitante y no lo considere tan estúpido que no pueda copiar su propio nombre de su pasaporte a su currículum. Incluso si sospecha de un error, puede aclararlo con más tacto.4. “¿Cuántas pelotas de golf se necesitarían para limpiar todas las ventanas redondas de un autobús escolar que se redujo al tamaño de una moneda de cinco centavos durante la evacuación de San Francisco, utilizando no más de 3 pesajes?”
Ningún artículo sobre entrevistas estaría completo sin mencionar las tapas de alcantarilla. Puede considerar este mi punto personal relacionado con la incapacidad de resolver problemas no estándar de manera rápida y bajo presión. Pero estoy seguro de que los acertijos son absolutamente inútiles durante las entrevistas. O más bien, esta es una excelente manera de reclutar un departamento completo de niños prodigios con Brain Olympiad, quienes intercambiarán nuevos acertijos durante todo el día en lugar de trabajar. Un verdadero programador en su hábitat natural, incluso cuando se ocupa de tareas muy interesantes y no estándar, rara vez codifica bajo estrés, sino que pasa la mayor parte del día sentado y pensando tranquilamente en un ambiente relativamente tranquilo sobre cómo puede cortar bellamente el código. métodos. Nunca utiliza sus “músculos cerebrales” para resolver problemas complicados en este proceso.5. “Mal. Más."
Por supuesto, no es trabajo del entrevistador capacitar a las personas que acuden a una entrevista. Sin embargo, si el solicitante no pudo responder la pregunta, pero aún está interesado, entonces incitarlo o al menos indicarle la solución correcta antes de pasar a la siguiente pregunta es una cuestión de ética profesional, demostrando que aquí lo ayudarán y enseñarán. Si pasa algo, no se quedará solo con los problemas técnicos. Dígale al menos algunas palabras, qué buscar en Google, qué leer. Después de todo, el interés en la solución correcta del problema es en sí mismo una cualidad positiva de un especialista técnico, y esa persona no debe desmotivarse por una actitud desdeñosa hacia sus errores o inexactitudes.Entrevista desde la perspectiva del entrevistador.
Cada vez que se abre una nueva vacante, un especialista destacado o un jefe de departamento tiene que realizar muchas entrevistas técnicas. Las personas acuden a las entrevistas con diferentes experiencias técnicas, niveles de formación y expectativas. Para realizar entrevistas, es necesario pensar en un plan de conversación, elaborar una lista de preguntas y luego tratar de comprender a partir de las respuestas a estas preguntas si la persona es adecuada para el puesto o no. Y a veces los solicitantes durante las entrevistas dicen cosas que inmediatamente queda claro: no, no se puede trabajar con esta persona. Aquí hay una selección de frases clave de los solicitantes que me alarman personalmente.1. “Algunas de tus preguntas son teóricas. ¡No soy fuerte en teoría, tengo experiencia en la práctica! ¡Hagamos una prueba mejor!
La palabra “teórico” suele pronunciarse con una connotación despectiva, como si fuera algo malo. Pero ese ni siquiera es el problema. ¿Crees que esta frase fue precedida por la petición del entrevistador de demostrar el teorema de Cauchy? ¿Dar una definición precisa de tercera forma normal? De nada. Escuché tales exclamaciones en respuesta a las siguientes preguntas:- ¿En qué se diferencia la comparación por == de la comparación por iguales en Java?
- cuéntanos cómo funciona el mapa hash.
- Explica con tus propias palabras qué es REST.
- ¿Qué son las transacciones y por qué son necesarias?
2. “¡No esperaba la Inquisición española aquí! Es como hacer un examen en el instituto. Por lo general, simplemente preguntan dónde trabajó y qué hizo”.
Has venido a una entrevista técnica. En una entrevista técnica, se le harán preguntas técnicas para poner a prueba sus habilidades técnicas. Deje la metodología de prueba y la elección de las preguntas a la conciencia del entrevistador; es posible que las preguntas no siempre le parezcan adecuadas, pero el entrevistador sabe exactamente qué información quiere obtener sobre usted al analizar sus respuestas. Se necesitan muchas preguntas no para poner a prueba sus conocimientos, sino para obligarlo a pensar y observar su línea de pensamiento. Recuerda también que no todas las preguntas requieren una respuesta perfectamente precisa, y si respondes claramente al menos la mitad de lo que te preguntaron, esto ya causará una buena impresión.3. “¡No necesito saber eso, me especializo en tareas de nivel superior!”
No confundas especialización con desconocimiento de los conceptos básicos de programación. Escuché cosas similares de desarrolladores de aplicaciones móviles sobre los protocolos de la pila TCP/IP, y de programadores de aplicaciones para el usuario en respuesta a preguntas sobre algoritmos de clasificación y búsqueda. "¿Por qué debería saber esto? Todo está en la biblioteca estándar, trabajo en un nivel superior". En respuesta a tales declaraciones, hace mucho tiempo se me ocurrieron un par de pequeños problemas con algoritmos furtivamente ocultos, con la esperanza de demostrar que una solución "ingenua", nacida de la ignorancia de los algoritmos, no resiste las críticas, y al menos al menos fomentar la autoeducación. Además, estas no son tareas construidas artificialmente, sino cosas que ocurren en el desarrollo todos los días. Cualquier código es un algoritmo. Comprender los algoritmos básicos y las estructuras de datos es importante para cualquier programador, y los protocolos de Internet son una base sin cuyo conocimiento es imposible escribir de manera competente algo que vaya más allá de los límites de una computadora.4. “¡Y tú mismo! / ¡Muéstrame tu código! / Pero fui a tu GitHub y hay esto...”
Lo último que quiere un entrevistador es contratar a una persona y luego tener que escucharla criticar su código base. Sí, lo más probable es que sea imperfecta. Sí, la deuda técnica está en todas partes y todo el mundo la tiene. En cualquier código hay algo que criticar. Pero si realmente te consideras tan genial que ves problemas obvios en el código de tus posibles empleadores, traduce esto en algo positivo y constructivo: sé cómo mejorar, tengo experiencia en este tema, puedo beneficiarte.5. "¡Estás equivocado!"
Por supuesto, puede pasar cualquier cosa, pero es mejor conservar hasta el final de la entrevista su opinión sobre si el entrevistador se equivoca o si tiene dudas sobre su competencia. Luego busque en Google y descubra cuál de ustedes tenía razón. Una entrevista técnica no es un lugar para la discusión o la autoafirmación, y las preguntas aquí están dirigidas principalmente a usted. El entrevistador no preguntará sobre algo que él mismo no comprenda.Conclusión
¿Sabes qué es lo más agradable que escuché de los solicitantes durante las entrevistas? “Realmente no respondí, ¿verdad? ¿Puedes darme un trozo de papel? Escribiré tus preguntas y las resolveré en casa, incluso si no me contratas, al menos lo sabré ahora”. Lágrimas de orgullo brotan de tus ojos: no en vano pasaste una hora y media con una persona, él mismo aprendió algo de esta entrevista. Incluso si ahora es demasiado débil para este puesto, tal vez esto lo anime a educarse y en uno o dos años volverá, mostrará su mejor lado y conseguirá un trabajo, como sucedió una vez en mi carrera.Las entrevistas ocupan un lugar destacado en la lista de los mayores temores de la mayoría de las personas, junto con hablar en público. No solo estás actuando frente a alguien, sino que también te evalúan constantemente todo el tiempo... ¡brrrr!
Por supuesto, estamos lejos de intentar comprender y superar sus barreras psicológicas, pero definitivamente es mejor ver las entrevistas como una oportunidad para mostrar todas las cosas interesantes que ha creado y todas las nuevas e interesantes habilidades que ha aprendido. Las mejores entrevistas son conversaciones técnicas y entusiastas.
El primer paso antes de todo esto es la preparación. Querrá pensar en las posibles preguntas (y las respuestas más comunes que resaltan su brillantez) e investigar la empresa contratante. Su conocimiento de la empresa le ayudará a presentarse de una manera que se adapte a sus necesidades y también le permitirá hacer preguntas inteligentes sobre sus productos y tecnologías cuando llegue el momento. Una vez más, consulte el artículo de Happy Bear para obtener consejos prácticos.
¿Qué es todo este proceso?
Solo un vistazo rápido al proceso por el que pasa la empresa de tecnología promedio al contratar desarrolladores:
- Entrevista preliminar por teléfono (Phone Screen)
- Entrevista técnica
- Términos de referencia de la prueba
- Entrevistas de seguimiento para garantizar que usted encaja bien (Entrevistas de ajuste)
- Oferta de trabajo
- Discusión de los términos de la oferta (Negociación de oferta)
- Aceptación de oferta
Entrevista telefónica preliminar
¡Felicidades! Su currículum resultó no ser el más desastroso y lo invitaron a una entrevista telefónica (tenga en cuenta que a veces primero realiza una tarea de prueba). El verdadero propósito de este paso, que a menudo implica una conversación de media hora con alguien de RR.HH. (en lugar de con quien toma las decisiones de contratación), es asegurarse de tener buenas posibilidades de superar el resto del proceso de entrevista. Así que considérelo como una versión más ligera de los otros pasos.
Probablemente le preguntarán sobre algunos de los aspectos técnicos que incluye en su currículum, pero no profundice demasiado (aunque algunos empleadores hacen algunas preguntas bastante complicadas), y probablemente le harán algunas preguntas "más suaves" sobre por qué elegiste este trabajo y qué hiciste antes. Las entrevistas telefónicas pueden variar mucho de una empresa a otra. La táctica principal aquí no es una táctica en absoluto, sólo ser honesto, enérgico y abierto. Y no tengas miedo de practicar hablar de ti mismo frente al espejo.
NOTA FINAL: Este no es un método único para todos y muchas empresas lo omiten y se sumergen directamente en las profundidades de una entrevista técnica, por lo que debe prepararse por si acaso. El siguiente enlace a Coding Horror es el más ilustrativo de este caso.
- Logre la excelencia en las entrevistas telefónicas con Monster
- 7 pasos para lograr la excelencia en las entrevistas telefónicas
Entrevista técnica
La entrevista técnica suele ser la parte más aterradora del proceso de selección. Aquí es donde evaluarán si tienes las habilidades técnicas necesarias. Esto significa que no sólo le preguntarán con gran detalle sobre su trabajo, sino que también le pedirán que resuelva problemas lógicos o escriba código allí mismo o esboce un diagrama de algunos componentes nuevos.
De hecho, uno de los propósitos de dicha entrevista es llevarlo al límite de sus capacidades, solo para ver cómo reacciona ante cosas desconocidas. Si haces un ejercicio demasiado fácil, pasarán a algo mucho más difícil. Siempre habrá lugares en los que tropezar, especialmente para los principiantes. Tu mayor activo es tu honestidad y curiosidad.
Al resolver un problema, asegúrate de hacerlo de forma clara y lógica, explicando en voz alta por qué estás realizando un paso en particular. Hable sobre los obstáculos que encuentre y dé ejemplos de cómo los resolvería en el “mundo real”. A menudo, la respuesta es "Buscar en Google" una característica específica. ¡Dilo! Saben que usted no es un experto en Ruby, pero también necesitan saber que puede encontrar soluciones a los problemas que inevitablemente encontrará en el trabajo.
También es completamente normal si utilizas la fuerza bruta (un método ineficiente) para resolver un problema de codificación. Este suele ser el mejor punto de partida para tener una idea adecuada del problema. Lo más probable es que le pregunten cómo se puede mejorar la solución, pero esto es mucho mejor que intentar encontrar la solución perfecta y no tener tiempo para escribir nada al final. Una vez más, su trabajo no es ser un candidato destacado, sino demostrar que es adaptable y resiliente ante los desafíos.
Y si no sabes algo, es mejor que lo digas con sinceridad y trates de pensarlo bien con el entrevistador. Créeme, quieren que tengas éxito tanto como tú, porque no hay nada peor para un entrevistador que ver a alguien tratando de resolver un problema en silencio, quedándose cada vez más atascado sin pedir ayuda y sin dejar que nadie sepa lo que estaba haciendo. pensamiento.
Tendrá que leer sobre muchas cosas que no se enfatizaron en cursos anteriores, como estructuras de datos y algoritmos, simplemente porque es muy popular preguntar sobre ellos en las entrevistas. No siempre reflejan bien las habilidades de programación, pero da la casualidad de que responderás preguntas que pertenecen al ámbito más académico de la informática.
Enlaces
- Veamos la entrevista para programadores: DEBE LEER EL MATERIAL quien se convertirá en tu mejor amigo. Se necesita una mirada integral a todos los tipos de desafíos que enfrentará en una entrevista. Va más allá de lo que ya hemos cubierto en este curso y toca cosas que es bueno saber porque es probable que las encuentres. Tómese el tiempo para familiarizarse con la mayor cantidad de material posible.
- Interviewing.io te brinda la oportunidad de practicar entrevistas técnicas de forma anónima y en línea.
- Cómo conseguir una puntuación perfecta en una entrevista técnica
- Cómo destacarse en su próxima entrevista de trabajo de desarrollador web
- Lea 40 conceptos clave de informática explicados en un lenguaje fácil de entender
- Guía de habilidades tecnológicas de Google(para avanzados)
Tareas de prueba de programación:
- 8 reinas es un problema clásico.
- Programar para entrevistas: conocer las bibliotecas estándar puede ser excesivo para un principiante, pero nunca está de más si se toma el tiempo para hacerlo.
- En Project Euler encontrará problemas más generales y complejos que deben resolverse de manera eficiente (pueden requerir muchos cálculos).
- Las preguntas de práctica para Java y Python se publican en Coding Bat.
Entrenamiento de algoritmos:
- Curso de algoritmos de Udacity (no sincronizado)
- Curso de algoritmos de Coursera (parcialmente sincronizado)
Arquitectura:
Tarea de prueba técnica
La tarea de prueba puede realizarse antes o después de la entrevista en persona, según la empresa. Se le asignará una tarea que requerirá un día completo para completarse en cualquier momento que le resulte conveniente. Ejemplos de tal tarea podrían ser crear una aplicación web de muestra con pruebas o resolver un problema algorítmico complejo escribiendo código.
La evaluación se basará en la integridad de la solución y la calidad de su código. Si esto sucede antes de la entrevista técnica, entonces es una buena manera de poner a prueba su interés (hasta la mitad de los solicitantes ni siquiera regresan con una solución).
Entrevista final (“Fit”)
El último paso antes de tomar una decisión suele ser conocer durante unas horas al equipo y las oficinas. Es posible que te pongan a prueba técnicamente, pero el objetivo principal es asegurarte de que serás un buen colega. Si algún otro miembro del equipo dice que no trabajarás bien, lo más probable es que no te contraten. ¿Consejo? No hay necesidad de ser raro o incómodo, incluso si estás en casa :)
Esta también es una oportunidad para ti. Si ha llegado hasta aquí para llegar a este paso, es muy probable que, en general, sea elegible. Debe considerar si desea trabajar para esta empresa, así que prepare una lista de preguntas y obtenga respuestas.
Un poco de salario
No. Exprésalo. Tuyo. Salarios. Expectativas.
Siempre se le preguntará "¿cuánto le gustaría recibir?" ¿Tu respuesta? “Me gustaría que me pagaran al precio promedio del mercado” (a menos que sea tan arrogante como para pedir un precio por encima del mercado. Veamos cómo le funciona). No ganará nada indicando el nivel salarial que desea. Si resulta ser inferior a lo que querían ofrecerte, simplemente bajarán este nivel. Y si es más alto, simplemente interrumpirán todo el proceso y decidirán que usted es demasiado caro para ellos.
Una vez que reciba una oferta, puede comprobar cómo se compara con el salario promedio del mercado preguntándole a algunas personas (con suerte, ya conoce a algunas personas a quienes preguntar) o yendo a Glassdoor (solo recuerde que es un principiante, lo que significa que no recibirá un salario “promedio”). Lo más importante es no hacerte daño cuando te lo pidan.
Ya has publicado un anuncio en sitios de trabajo con un buen salario y una descripción vívida que sería de tu interés, has seleccionado 20 candidatos y mañana comenzarás a realizar entrevistas. Todo lo que queda es averiguar qué preguntar exactamente.
Tienes un producto, un equipo establecido y financiación. Usted (el equipo) ha trabajado bien y la gerencia está dispuesta a pagar más dinero para contratar a una persona para, en consecuencia, acelerar el desarrollo, mejorar la calidad y poder gastar recursos en el desarrollo tecnológico del producto. Ya publicó un anuncio en hh con un buen salario y una descripción vívida que sería de su interés, ha seleccionado 20 candidatos y comenzará a realizar entrevistas mañana. Todo lo que queda es averiguar qué preguntar exactamente. ¿Situación común? Entonces bienvenido al gato.
Quizás la situación sea un poco utópica, pero muchos casos también entran dentro del alcance de este artículo. Las excepciones son las empresas que "necesitaban una persona ayer" o las empresas que no necesitan una persona nueva en absoluto, simplemente están "observando el mercado" y (o) esperando encontrar un "profesional poco común".
En otras palabras, este es un artículo para aquellos que quieren invertir dinero y esfuerzo en fortalecer el equipo.
Para empezar, observemos que es sumamente perjudicial contratar a una persona para una necesidad momentánea. Digamos que ahora mismo el desarrollo de la parte del servidor se está ralentizando ligeramente para usted. ¿Significa esto que necesitas contratar un programador del lado del servidor? En realidad no. Si tienes un desarrollo bastante activo, la prioridad de las diferentes piezas cambiará inevitablemente. En este sentido, es una estupidez contratar a una persona para una tarea durante el próximo mes. Después de todo, pasará un mes, pero aún tendrás a la persona. Y si este mes repara un agujero en el desarrollo del lado del servidor, el próximo mes resultará que el lado del servidor se escribe más rápido de lo que se remacha la interfaz. Entonces, ¿el mes que viene tendremos que contratar a un programador de UI? ¿O activar el “eslabón débil” en el lado del servidor? No, esto debe abordarse de otra manera. Mire lo que ha hecho antes en el desarrollo de productos. Pregunte a los vendedores, a los inversores o a quien establezca los objetivos de desarrollo y trate de hacerse una idea de lo que le espera, digamos, dentro de un año. Ahora imagina qué tipo de persona te ayudaría a trabajar más eficazmente en el pasado y en el futuro. Espero que te hayas presentado a más de una persona. Lo más probable es que resulte que es posible fortalecer el equipo aquí y aquí. Y si en algún lugar resulta ser demasiado fuerte (y, en consecuencia, en algún lugar demasiado delgado), entonces alguien del equipo existente puede aceptar "cambiar" su actividad.
Así pues, ha esbozado varios retratos de candidatos “ideales”. Es hora de realizar una entrevista técnica. Por cierto, espero que en su empresa sea la entrevista técnica la que influya en la decisión de contratar empleados. Suelen hablar de una empresa como una “familia” o “un equipo donde pasar un buen rato”. Entonces una empresa todavía no es una familia. Y no los amigos con los que vas a jugar a los bolos. Por supuesto, si una persona está enferma de cleptomanía o lepra, es peligroso contratarla, incluso si fue la mejor en pasar la entrevista técnica. Pero no se obsesione demasiado con las cualidades personales. En principio, antes o después de una entrevista técnica, es necesario averiguar si la persona lanzará algún tipo de truco y, en este sentido, una entrevista "no técnica" de este tipo desempeñará el papel de "umbral". quien no lo apruebe definitivamente no trabajará en la empresa, pero si lo aprueba, no importa si es la "vida de la empresa" o simplemente un empleado concienzudo. Pero eso es todo; de hecho, todas las demás decisiones deben ser determinadas por la entrevista técnica. Si el departamento de recursos humanos de su empresa está molestando a los candidatos con preguntas sobre sus aspiraciones profesionales y "dónde se ven dentro de 10 años" o "por qué la empresa debería contratarlo", entonces es demasiado pronto para buscar talento técnico. Primero, necesitas encontrar un nuevo RRHH.
Pero, ¿qué deberías preguntar en una entrevista técnica? ¿Crear una prueba? ¿Averiguar qué hacía la persona en su trabajo anterior? ¿Hacer una pregunta complicada? ¿Dame un problema de Braingames.ru?
Veamos estas opciones en orden.
La prueba puede parecer algo útil para ahorrar tiempo. Sin embargo, es bastante difícil crear una buena prueba; esta tarea en sí requiere mucho tiempo. Una mala prueba sólo puede descartar a los candidatos que no asisten a muchas entrevistas y no conocen las respuestas a las preguntas "estándar". Una prueba muy mala puede descartar candidatos realmente buenos que acaban de hacer cosas ligeramente diferentes. En general, la prueba es sólo una especie de filtro primario. No puedes contratar a una persona que no pueda responder cinco preguntas que consideras triviales. Pero definitivamente no deberías contratar a una persona después de una prueba sin preguntarle una palabra.
¿Qué hiciste en tu último trabajo? Bueno, ya sabes, lo que el solicitante hizo en su trabajo anterior, ya no lo hará contigo. En principio, puede hacer esa pregunta para encontrar un tema de conversación. Pero, sinceramente, parece una pérdida de tiempo. Daré un ejemplo de mi práctica.
¿Qué hiciste en tu último trabajo?
- Pues existía un sistema complejo que simulaba el sistema de comunicaciones urbanas con la búsqueda de rutas óptimas y (...)
- ¿Qué es el algoritmo de Dijkstra?
- Um, sí, y escuché algo así.
¿Así que, qué hemos aprendido? No importa. Algún tipo de proyecto complejo. No está realmente claro qué tipo de proyecto era, qué hizo exactamente este empleado, qué aprendió a hacer bien finalmente. Perdimos 5 minutos sin saber nada de la persona. Por supuesto, puedes dedicar media hora a solucionarlo todo. Pero hay dos “peros”.
Primero, valora tu tiempo. Si dedica 4 horas a cada candidato, es posible que simplemente no llegue al que realmente vale la pena. En general, en mi opinión, la entrevista debe limitarse estrictamente a un período de tiempo, digamos una hora. Y trate de sacar de la persona durante esta hora todo lo que necesita para tomar una decisión.
En segundo lugar, no se obsesione demasiado con quién era la persona. Intente evaluar en quién podría convertirse en su empresa. ¿Su candidato dice que en su último trabajo completó un módulo en una semana y usted tardó un mes en completarlo? Entonces, tal vez en su trabajo anterior había procesos de negocios interesantes y una montaña de código listo para usar, pero en su casa él habría estado haciendo este módulo exactamente la misma cantidad de tiempo que usted. ¿O le pareció que el candidato no hizo nada destacable en su último trabajo? Es muy posible que lo sea. Pero tal vez se trate de una persona talentosa que ha vegetado con “cuernos y pezuñas” de tercera categoría, ¡y se revelará todo su potencial! Créame, en muchas situaciones vale la pena luchar por una persona así incluso más que por un especialista consumado.
¿Debería preguntar algo complicado? Digamos que ayer leíste en Habré que resulta que un código hash en Java no es una dirección (como siempre pensaste), sino un número aleatorio, y te preguntas si el candidato lo sabe. O la semana pasada estabas husmeando en nicks y descubriste que “[” no es parte de un script bash como lenguaje, sino un programa normal con el nombre “[”. ¿Sería útil saber si el candidato sabe esto?
Aquí vale la pena volver a intentar jugar con las opciones de preguntas y respuestas.
Juego de roles.
- Bueno, esta es la dirección del objeto.
Y la segunda opción:
¿Qué es Object.hashCode()?
- Sí, hay un generador de números aleatorios, por lo que regresa.
Dedicaste 3 minutos a esta pregunta. ¿Cómo se compara al primer y segundo candidato? ¿Podemos decir que uno de ellos es mejor que el otro? Quizás el segundo estaba hojeando el código grep a su antojo. O leer habr en lugar de trabajar. O tal vez no. ¿Pero esto significa algo para ti?
No es que no importe si una persona conoce o no las sutilezas de la implementación. Al contrario, creo que es muy importante saber las pequeñas cosas. Una persona que sabe ensamblador es más valiosa para mí que alguien que no lo sabe, incluso cuando estoy buscando un desarrollador de Java. Pero, lamentablemente, hay tantas pequeñas cosas que la pregunta directa "¿Sabes qué?" casi nunca tiene sentido. Pero no podemos preguntar sobre cientos de cosas porque tenemos un tiempo limitado.
Entonces, ¿qué debería preguntar?
Me parece que lo mejor es mantener una conversación en el contexto de lo que usted hace habitualmente y observar cómo el candidato resuelve los problemas que usted resuelve a menudo.
Digamos que su aplicación tiene lógica de interfaz de usuario y código de servidor. Pregúntele al candidato qué cree que es más interesante.
¿Código del servidor? Excelente. Imaginemos algún fragmento de código típico en su programa. Nos interesan las preguntas que tiene el candidato y cómo conecta los conocimientos teóricos con las necesidades prácticas.
Digamos este problema:
Hay un fragmento de código
vacío x(Lista
...algo de procesamiento
Pregunta para el candidato: supongamos que en este código necesitamos ordenar la lista en orden alfabético antes de "Algún procesamiento". ¿Qué vas a hacer? Por cierto, sí, puede informarle inmediatamente al candidato sobre Collections.sort; no estamos verificando el "vocabulario".
Digamos que nuestro candidato escribió algo como
vacío x(Lista
Lista
Colecciones.sort(b);
... Algún procesamiento con b
(Espero que nuestro candidato haya resuelto este problema de esta manera y no haya comenzado a ordenar a).
Sin embargo, solucionar el problema no es lo principal aquí. Lo principal es la discusión.
¿Por qué creó una lista nueva y no utilizó la anterior? ¿Es esto siempre correcto?
¿Por qué usaste ArrayList y no otra cosa? ¿Sabe qué más hay?
Lo más interesante es que la discusión aquí puede ser casi interminable. El candidato dirá que ArrayList es mejor porque tiene acceso aleatorio, pero usted dirá que ordenar aún copia los datos en una matriz antes de ordenarlos y luego los devuelve. ¿ArrayList es mejor ahora, en opinión del candidato? ¿Qué, ya no? ¿O es aún mejor?
Una conversación con un candidato debería revelar su forma de pensar. Mira cuántos detalles conoce. ¿Cómo reacciona ante algo nuevo? Y lo más importante, ¿puede utilizar correctamente la información que le das? Al fin y al cabo, un “saberlo todo” abstracto no suele ser especialmente importante, hay compañeros cerca y a menudo se puede discutir un tema problemático. Los colegas pueden dar consejos, pero no escribirán código en lugar del nuevo empleado, así que intente comprender si, después de escuchar los consejos, podrá escribir un programa mejor.
O digamos otro ejemplo.
No preguntes "qué es un recolector de basura". No preguntes "¿cuántas generaciones hay?" ¿Qué diferencia hace? ¿Qué diferencia hay si una persona puede decirle o no cómo funciona gc? Para su trabajo, lo único importante puede ser si una persona puede solucionar un problema de rendimiento si surge uno y si puede contar una historia conmovedora al respecto. ensamblaje a lo largo de generaciones o sobre barrido de marcas concurrente gc.
No digo que cualquiera pueda resolver problemas interesantes con GC sin saber cómo funciona. Una vez, por supuesto, puede que tengas suerte. Pero en la práctica, el conocimiento es extremadamente importante. El problema es diferente: no todos los que pueden decirte cómo funciona algo pueden solucionar un problema con ese algo. Y, en términos generales, la intuición y el conocimiento técnico general suelen ser más importantes para resolver un problema que la descripción de un algoritmo leído en alguna parte.
Por ejemplo, para gc sería bueno volver a plantear algún problema práctico.
Digamos: "iniciaste un programa con un montón de 2 gigabytes y funciona lentamente, ¿qué harás?"
voy a aumentar mi cadera
¿Será más rápido? Y lo más interesante es, ¿no vale la pena preguntar antes de responder esta pregunta qué significa para mí “más rápido”? Vea si el candidato comprende la diferencia entre rendimiento y latencia. No preguntes qué es ni cuál es la diferencia. Si un candidato, dada la formulación del problema descrita anteriormente, no piensa en hacer preguntas tan triviales, en la práctica no tendrá estas preguntas. Sin embargo, no debemos olvidar que estamos manteniendo una conversación. Si el candidato intervino directamente, deténgalo y cuéntele sobre las diferentes características de desempeño. El candidato nunca había oído hablar de ellos, pero inmediatamente se dio cuenta de que hacer crecer una cadera podría mejorar una cosa, pero definitivamente empeoraría otra. Bueno, ¡esto es maravilloso!
Se pueden dar un número infinito de ejemplos de este tipo. La mejor parte es que estos problemas son fáciles de resolver y no hay números: puede preguntar a cada nuevo candidato sobre cosas diferentes y adaptar los problemas para un candidato específico.
- Reclutamiento y selección, Evaluación, Mercado laboral, Adaptación
Te sugerimos abordar tu entrevista para un puesto de desarrollador de software con humor y tratarla como si estuvieras atravesando un juego de computadora en el que avanzas hacia la victoria y completas niveles. Por eso, hemos preparado varios códigos de trucos para ayudar al personaje principal de este juego.
Benjamin Weiss, de Infusive Solutions, recurrió a colegas de RR.HH. y desarrolladores de videojuegos para crear un "juego de entrevistas". Habrá niveles en el “juego” que tendrás que “pasar” para conseguir un puesto, comenzando con una entrevista con un reclutador. El concepto del juego puede parecer ridículo, pero la información que Weiss y sus colegas proporcionaron no tiene precio.
Códigos de trucos para derrotar a los 4 jefes que puedes encontrar en la búsqueda para convertirte en un nuevo desarrollador de software
En la mayoría de los casos, el largo camino para obtener un puesto de desarrollador de software es sinuoso y lleno de dificultades.
Por supuesto, si eres una persona muy talentosa y creativa, es posible que te acepten más rápido de lo habitual. El proceso también puede acelerarse si la empresa necesita un empleado con urgencia.
Pero, por lo general, los desarrolladores de software se encuentran en una búsqueda enorme e intrincada para escalar múltiples niveles y conseguir el trabajo de sus sueños.
Espera un segundo, ¿qué es esta súper misión? ¿Cuales son los niveles? Parece un juego de ordenador, ¿no?
Vayamos al corazón de nuestra idea. Si lo piensas bien, los gerentes involucrados en el proceso de entrevista técnica son similares a los "jefes" que los jugadores encuentran al final de cada nivel de un juego de computadora.
El jugador principal (por ejemplo, Mario, Zelda o Duke Nukem) necesita derrotar a todos los jefes del juego para poder avanzar al siguiente nivel: al igual que los directivos de las empresas de TI.
El héroe necesita aprender a construir estrategias dependiendo de las características de los diferentes jefes para poder ganar el juego, porque cada uno de ellos tiene características diferentes (aunque existen tácticas comunes).
Entonces, tomemos la entrevista para un puesto de desarrollador de software con humor y percibamos todo el proceso como un juego emocionante en el que pasas a la final y derrotas a los gerentes que te contratan, quienes serán:
- Especialista en reclutamiento;
- desarrollador Senior;
- administrador de software;
- CTO.
¿Listo? ¡Excelente! Empezamos con un scrum con un reclutador del departamento de recursos humanos de primer nivel.
Nivel 1: jefe, reclutador
El jefe de RRHH tiene las siguientes características: - vigila el acceso a otros jefes;
- la primera persona en leer y evaluar su currículum;
- normalmente no están técnicamente preparados;
- Interesado en que usted postule para varias vacantes en la empresa.
Jennifer Loffus, directora regional de Astron Solutions, ex presidenta de la Asociación de Recursos Humanos de Nueva York.
Cualquiera que se haya entrevistado para un puesto de desarrollador de software sabe que lo más probable es que primero deba reunirse con alguien del departamento de recursos humanos. Por lo general, él o ella tiene muchas preguntas para usted y también tiene la clave para pasar a los siguientes niveles, donde se reunirá con los gerentes del departamento de TI. ¿Cómo pasas ese primer nivel en el que se revisa tu currículum, recibes una llamada telefónica y tienes una conversación cara a cara con tu jefe de recursos humanos?
Existe la opinión de que los oficiales de personal sólo tienen un deseo: encontrar candidatos para un nuevo puesto. ¿Recuerdas a Toby de The Office? Por lo tanto, su imagen de especialista en recursos humanos se embellece enormemente.
Quizás los reclutadores ya hayan puesto un freno a sus planes profesionales. Sin embargo, su principal objetivo no es impedir que usted sea aceptado. Se enfrentan a la tarea específica de la dirección de encontrar al mejor candidato para la vacante abierta, por lo que analizan las siguientes características del solicitante: educación, experiencia profesional y calificaciones en el campo requerido. Exploremos una estrategia para construir relaciones ideales con RR.HH.
Para llegar al primer nivel de una entrevista con un empleado de RR.HH., evite los siguientes errores:
No envíes tu currículum con errores
Tu currículum habla de ti, tu atención al detalle y tu interés en el trabajo. Un currículum con errores les dirá a los funcionarios de recursos humanos que usted es indiferente tanto a la empresa como al puesto en sí. Revise cuidadosamente su currículum en busca de errores varias veces, léalo en voz alta para detectar errores tipográficos. Pídale a otra persona que lo lea nuevamente, ya que es posible que encuentre errores que usted pasó por alto.
No envíes tu currículum demasiado tiempo
Has logrado mucho en tu carrera y quieres hablar de ello. Y el oficial de personal quiere saber si usted es apto para un puesto específico, mientras que tiene muy poco tiempo para conocer su currículum. Edite su currículum para que sea relevante para el puesto que está solicitando. El currículum debe contener entre 500 y 1000 palabras y tener una extensión máxima de dos páginas. Utilice fuente 12 para que el texto sea más fácil de leer (no 8 o 9).
No envíe currículums generales ni cartas de motivación.
Su currículum y carta de motivación deben adaptarse a su puesto, empresa y área comercial específicos. Por ejemplo, si está solicitando un puesto como desarrollador de Internet en una empresa de servicios financieros, pero su currículum y su carta indican su interés en la gestión de tecnología de la información en una organización sin fines de lucro, es poco probable que lo inviten a una entrevista. ¡Describir!
¡Te han invitado a una entrevista con un miembro del departamento de RRHH!
¡Felicidades! Ya recibió una invitación para la primera entrevista con el responsable de recursos humanos. Hemos preparado varios códigos de trucos que te ayudarán a aprobarlo y conocer al desarrollador senior en el nivel 2.
Código de trucos: Si envía un currículum que es demasiado largo, no está diseñado para un puesto específico o contiene errores, su juego terminará incluso antes de comenzar.
Ven temprano y bien preparado.
Cuando llegue a la oficina de la empresa, es posible que deba completar algunos trámites. para que puedan completarse antes de que comience la entrevista. Los gerentes suelen tener una agenda de entrevistas muy ocupada, por lo que esperar 20 minutos por un candidato les resulta inaceptable. Además, trae la información de contacto de quienes aceptaron darte recomendaciones.
Vístete formalmente
Se requiere traje de negocios con corbata para los hombres y traje de pantalón o chaqueta con falda para las mujeres. Si solicita un puesto creativo en una empresa joven, es posible que el estilo clásico no sea adecuado. Consulte con el oficial de recursos humanos el código de vestimenta.
Ponte en orden
Los olores desagradables no deben distraer a su interlocutor. Asegúrate de no oler a cebolla, ajo, tabaco o café antes de tu reunión. Abastecerse de chicle o spray bucal.
¡Enfocar!
Dedique toda su atención al empleado de RRHH durante la entrevista, sea cortés con él, apague su teléfono móvil para no interferir.
¡Casi el nivel 2!
Asegúrese de vestirse apropiadamente, oler bien y estar completamente preparado para la entrevista. ¡Y ahora estás en la meta del nivel 1! Además de asegurar que tienes todas las habilidades y experiencia requeridas para el puesto, debes...
Mantener el contacto visual
Si miras a tu interlocutor a los ojos estás demostrando un interés genuino por el trabajo y la empresa. Míralo, y no a tus manos, al techo, a la puerta o a la ventana, así aumentarás notablemente tus ingresos.
ir a la ofensiva
Muchos se toman un descanso de su experiencia profesional, especialmente en tiempos de crisis. Sea el primero en explicar los motivos de las interrupciones en su carrera y no espere a recibir preguntas sobre este tema. Una posición abierta y activa le dará una ventaja sobre aquellos que intentan ocultar tales hechos.
Esté preparado para hablar sobre empleadores anteriores
Probablemente le preguntarán por qué dejó su último trabajo, así como qué le gustó y qué no le gustó hacer en su último puesto. Prepare respuestas creíbles y discretas. Recuerde que la información negativa sobre su anterior gerente o colegas no funcionará a su favor.
Habla con palabras claras
Los desarrolladores de software utilizan muchas siglas: ASP, CAO, GAC, IIS, etc. Cuando hable con una persona de recursos humanos (quizás sin experiencia técnica), deletree cada acrónimo la primera vez que lo diga. Asegúrate de hablar en un idioma que la otra persona pueda entender para no provocar más preguntas.
Hacer preguntas
Estudie la información sobre la empresa con antelación y prepare al menos 3 preguntas para el empleado de RRHH. Aquí hay algunas preguntas sin fallas que puede hacer durante su entrevista:
- ¿Qué es lo que más te gusta de la organización?
- ¿Por qué trabajas aquí? ¡A las personas les encanta hablar de sí mismas!
- ¿Cómo apoyan las tecnologías de la información los planes de desarrollo de la empresa?
- ¿Qué errores suelen cometer los nuevos empleados?
Di gracias"
Si la entrevista salió bien, el reclutador pasará entre 30 y 60 minutos contigo. El mismo día, envía una carta tradicional y un correo electrónico agradeciéndoles su tiempo.
Esta técnica probada te hará destacar entre la multitud y tu interlocutor definitivamente te recordará. En la carta, indique un par de temas de los que habló el gerente de recursos humanos para que sea personal.
Entonces, pasaste la entrevista con el reclutador y la búsqueda continúa; en el siguiente artículo conoce al jefe en el nivel 2: desarrollador senior.
Etiquetas:
