¿Hay desarrolladores realmente productivos que simplemente no les va bien con las entrevistas técnicas?

Parece que hay un ” Libro de jugadas para el entrevistador técnico secreto ” que todo gerente técnico o RR. HH. Intenta aplicar en su proceso de contratación, independientemente de los requisitos de trabajo reales para un desarrollador de software.

Como la mayoría de los otros coroanos han mencionado, 99 de cada 100 es una serie de preguntas que se asemejan a la programación competitiva y los desafíos algorítmicos de un estudiante universitario de tercer año sin exposición práctica al desarrollo real de software.

Personalmente, soy un asco en estos a pesar de que participé y pasé olimpiadas nacionales en informática. No me molesté en memorizar todos y cada uno de los algoritmos utilizados en la programación competitiva para poder escribirlo en una pizarra frente a un montón de personas.

He tenido algunas de esas entrevistas para trabajos que no tenían nada que ver con las tareas del día a día.

Plan de estudios

Desde que soy un experimentado entrenador técnico desde 2006, tenía algunas clases de algoritmos obligatorios en mi plan de estudios a pesar de que nuestros cursos son bastante prácticos (en 6 meses creamos aplicaciones web que funcionan sobre una base de datos, con una aplicación de escritorio que puede insertar nuevos registros según sea necesario y microservicios para posibles extensiones de terceros).

No estaba realmente entusiasmado con eso, ya que la programación competitiva era demasiado para un desarrollador de software en general, pero la gerencia dijo que estos son un requisito previo para las entrevistas. Así que tuvimos que enseñar habilidades y también capacitar a las personas sobre los tipos de preguntas irracionales que recibirán en las entrevistas.

La contratación está rota

En general, el proceso de contratación se rompe bastante a menudo. Hace 5–6 años, tuve una corporación multinacional que me acosaba durante 2 semanas por un trabajo de consultoría desesperado para un “proyecto paralelo” de $ 2M que tuvieron que cerrar para retener el proyecto principal de $ 250M para el mismo cliente.

Así que finalmente acepté a pesar de que ya estaba reservado. Fui al sitio, tuve una breve reunión, también me uní al almuerzo con su cliente. En aquel entonces, su plataforma principal era Java Enterprise, mientras que el proyecto paralelo era una tienda WooCommerce sobre PHP / WordPress. Tenía algunos años de experiencia práctica con cada grupo, así que me hice cargo de la reunión y obtuve un acuerdo verbal de que el cliente continuaría con ellos.

Después de la reunión exitosa, volvimos a la sede con el equipo de administración que estaba muy emocionado de que el cliente finalmente estuvo de acuerdo con su plan. Para mi sorpresa, el siguiente paso fue una “prueba de programación” que tuve que completar para continuar.

Me eché a reír y pensé que era una broma.

No lo fue.

Todavía no estaba realmente interesado en el trabajo ya que el proyecto no era muy interesante, la compañía no me dejaba usar el proyecto o su compañía como referencia, etc. Así que pensé en simplemente salir de la habitación, pero decidí divertirme con un cuestionario (la reunión de salida fue en un balcón de 360 ​​oficinas con una vista sólida de la ciudad). Tuve que dibujar algunos diagramas UML, mostrar OOP en Java en la práctica, etc.

20-30 minutos después, he completado el cuestionario. La gerencia trató de reclutarme como empleado a tiempo completo.

Fui contactado varias veces como consultor externo que ya tenía un equipo, pero que ni siquiera hicieron su tarea.

Les conseguí un acuerdo de $ 2M que rescató un proyecto de un cuarto de billón además de eso y me han entrevistado justo después.

Uno de los entrevistadores fue el director de operaciones de la compañía tenedora que generó más de $ 10B en ingresos.

En general, la mayoría de las entrevistas técnicas le piden que resuelva los tipos de problemas que nunca enfrentará en los próximos 2 a 5 años trabajando en esa empresa. La mayoría de los recursos humanos rara vez están preparados para candidatos también.

Hacer coincidir los requisitos de trabajo con un proceso de solicitud legítimo y una tarea práctica que se asemeje a lo cotidiano es lo que necesita la industria de TI. Las startups y algunas corporaciones ya están haciendo la transición a este modelo, pero el cambio todavía está a una o dos décadas de la mayoría de las organizaciones.

Sí. He tenido éxito en cada puesto en el que he estado por más de 20 años. Nadie que haya trabajado conmigo diría que no soy productivo. Me va extremadamente mal en las entrevistas técnicas. Soy un desarrollador muy atípico; No me gustan los juegos, no juego Go, no hago acertijos, no me gustan los crucigramas ni los rompecabezas de ningún tipo. Antes de convertirme en programador, tocaba el piano para vivir, y en el fondo soy pianista de jazz. La parte de mi cerebro que alcanza ese estado de “flujo” que me permite improvisar jazz es la parte que se activa al escribir código; y no puedo acceder a eso en una entrevista. Para ser justos, si el posible empleador quiere a alguien que “piense bien en sus pies” y pueda debatir los méritos técnicos de las cosas en un formato de reunión abierta, bueno … No soy su hombre. Sin embargo, muchos de nosotros somos pensadores profundos, y el hecho es que podría no ser el tipo de desarrollador que crees que quieres, pero la historia ha demostrado que soy el tipo de desarrollador que necesitas.

No todos encajamos en un molde. Las entrevistas técnicas en la pizarra seleccionan para un determinado tipo de personalidad, y en realidad es bastante posible tener un candidato que entreviste brillantemente pero que simplemente no produzca. Si eres un veterano del software, has visto a esta persona. No entiendo bien por qué esto sucede a veces; Entiendo cómo funciona para mí y por qué entrevisto mal, pero me resulta más difícil entender cómo un candidato puede entrevistar en una pizarra de manera brillante, pero no ser productivo.

La vida es divertida.

Si el formato de la entrevista no mide qué tan productivo será el desarrollador, entonces encontrará que algunos desarrolladores productivos no lo hacen bien. Solo pregúntale a Max Howell, creador de Homebrew:

Fuente: Max Howell a través de freeCodeCamp

Las entrevistas técnicas que involucran problemas de pizarra o pruebas de algoritmos no miden la productividad. En cambio, evalúan habilidades realmente básicas que, si bien son importantes, son irrelevantes para determinar si un desarrollador es productivo o no.

Lleva a mi amigo Stan. Lleva más de diez años trabajando en Python, liderando equipos que han creado algunas soluciones importantes y de misión crítica dentro de los plazos establecidos. Es lo que la mayoría de la gente llamaría un desarrollador senior realmente productivo.

A pesar de esto, tiene un historial realmente pobre con entrevistas en pizarra y pantallas de pruebas algorítmicas. ¿Que es eso? Él compara estos a la división larga. Esta es una habilidad importante que todos necesitan, lo suficientemente justo. ¿Pero cuándo fue la última vez que hiciste una división larga en un pedazo de papel? Probablemente no recientemente. ¿Y usted sabe por qué?

Calculadoras Son excelentes herramientas si caben en su bolsillo, son parte de su reloj o están en su teléfono. No solo eso, pueden dividir al instante, sin importar la longitud de los números. Un ingeniero no hace matemáticas a mano larga todo el día, usa una calculadora y usa el tiempo que ahorra para abordar las tareas de nivel superior en las que trabaja todos los días.

Para un desarrollador, las pruebas de algoritmos y las tareas de pizarra como invertir árboles binarios son como una división larga. Son importantes para entender, pero como un ingeniero y matemática básica, un desarrollador productivo no crea un algoritmo fuera de su cabeza cada vez que lo necesita. En su lugar, utilizan bibliotecas disponibles para ofrecer soluciones de trabajo de manera más eficiente.

Como desarrollador senior de Python, Stan no ha memorizado algoritmos en años, sino que se ha centrado en problemas de nivel mucho más alto. Su corazón generalmente se hunde cuando entra en una entrevista o hace una pantalla de tecnología solo para descubrir que lo están probando en estas habilidades de bajo nivel.

Sin embargo, con lo que Stan ha hecho bien son pantallas y entrevistas que realmente prueban su eficiencia y productividad. En general, esto implica resolver un problema comercial en condiciones del mundo real. Como alguien con un montón de años de experiencia haciendo esto, Stan generalmente sobresale en estos.

Toman la forma de una entrevista de emparejamiento de códigos amn o una prueba automática del primer día de trabajo en una plataforma como Devskiller. Ambos le dan al candidato una tarea que refleja su primer día de trabajo. Se les da acceso a todos los recursos que normalmente tendrían, incluidas bibliotecas, marcos, Stack Overflow, Google y su IDE preferido, entre otros. En estas condiciones, el entrevistador o el sistema pueden ver cómo el candidato utiliza los recursos disponibles para crear una solución limpia y eficiente dentro de un plazo. En otras palabras, cuán productivos son.

El punto es que las entrevistas de pizarra blanca y las pruebas de algoritmos requieren habilidades que son independientes del desarrollo de software. Como resultado, los desarrolladores productivos son frecuentemente descartados por ellos. Para saber si un desarrollador es realmente bueno en su trabajo, dele una tarea realista y vea cómo se desempeña.

Depende mucho de tu proceso de entrevista. El problema con la mayoría de las entrevistas es que no se parecen al trabajo diario que se realiza. Entonces no están seleccionando las habilidades relevantes. Están seleccionando a los desarrolladores que son buenos para memorizar algoritmos e implementar estructuras de datos.

La mayoría de los ingenieros, por ejemplo, no implementarán una lista vinculada. Hay muchas bibliotecas que ya hacen esto. Así que las entrevistas se convierten en un juego que juegas bien o no porque has memorizado cómo implementar BFS o DFS. Esto lleva a muchos falsos positivos. Estos falsos positivos son más caros de lo que las empresas se dan cuenta. El costo promedio para contratar a un ingeniero en el área de la bahía es de $ 30,000. Por lo tanto, puede llegar hasta el final del sitio y los grandes candidatos quedan descalificados, lo que de lo contrario sería una gran opción. Esto pasa mucho.

La mayoría del día a día para un desarrollador implicará corregir errores, escribir código nuevo, refactorizar código antiguo e interactuar con personas de otros equipos (atención al cliente para resolver errores, producto para convertir PRD en un producto real, etc.). Entonces, si hace esas preguntas, muchos desarrolladores podrán desempeñarse bien en ellas. He visto desarrolladores que podían responder a las preguntas tradicionales de la entrevista pero no eran buenos para corregir errores o refactorizar el código.

Entonces, si está haciendo preguntas al azar, muchos candidatos pueden memorizar y jugar bien el sistema. Otros no pueden. Pero la verdadera pregunta que debe hacerse es: ¿cuál es el proceso de entrevista adecuado para seleccionar a los mejores candidatos? ¿Cómo lo hago lo más natural y lo más cercano posible al trabajo real? Entonces, realmente ni siquiera importa si los candidatos no lo hacen bien o no porque si no lo hacen bien, entonces sabes que estás rechazando por las razones correctas. Estar nervioso también es una parte normal de la experiencia, por lo que la preparación puede ayudar con eso. Un producto que he creado es resolver ese problema en la etapa in situ. Al enviar horarios detallados en el sitio a un candidato, se presentarán preparados, relajados y tendrán un mejor desempeño. Echale un vistazo.

Una entrevista técnica es muy similar a pedir pizza para un extraño completamente al azar y esperar que les guste. ¿Qué demonios quieres decir con “No me gusta la piña”?

En mis entrevistas técnicas, los supere por completo o fracasé tanto que la seguridad me escoltó y luego prendió fuego a mi auto por perder el tiempo.

Caso en cuestión: estaba en mi tercera y última entrevista para Very Large Chip Fabricante. Obviamente había clavado los dos primeros para llegar tan lejos, pero de repente el desarrollador / entrevista principal me está haciendo preguntas sobre el desarrollo web. “No, realmente no tengo idea de cómo optimizar la sesión-cookie-evento-paso-a través de lo que sea que esté hablando. Solicité el puesto de sistemas integrados y nada en mi CV indicaba que sé algo sobre las cookies de sesión “.

Creo que soy bastante talentoso y productivo, pero no soy un experto en todas las cosas técnicas, así que si haces las preguntas correctas, fracasaré miserablemente.

Hay muchos desarrolladores que son buenos contratados pero que no son buenos en las entrevistas. Ambas compañías no obtuvieron el empleado adecuado y el desarrollador no obtuvo el trabajo que estaba buscando.

La mayoría de las entrevistas tienen estructuras de datos y las rondas de algoritmos pueden ser que el desarrollador no haya practicado correctamente antes de aparecer en una entrevista.

Se supone que deben escribir en una hoja de papel o pizarra. Hay casos en que los desarrolladores no pueden expresar sus pensamientos correctamente sin su IDE.

Muchas veces no recopilan el requisito correctamente y comienzan a resolver el problema que se establece prematuramente.

Cuando su experiencia aumenta, más de 4 años, entonces el Diseño del sistema se vuelve importante.

Si buscas preparación para la entrevista. Puede comenzar con “ Resolución de problemas en estructuras de datos y algoritmos ” escrito en varios lenguajes como C, C ++, Java, C #, Python, etc. Estos libros son fáciles de seguir y están escritos para el punto de vista de la entrevista . Además, estos libros tienen el último capítulo sobre Diseño de sistemas , que también se requiere en las entrevistas.

Los enlaces de los libros en Amazon están abajo:

1. Resolución de problemas en estructuras de datos y algoritmos utilizando C

2. Resolución de problemas en estructuras de datos y algoritmos usando C ++

3. Resolución de problemas en estructuras de datos y algoritmos utilizando Java

4. Resolución de problemas en estructuras de datos y algoritmos con C #

5. Resolución de problemas en estructuras de datos y algoritmos usando Python

6. Estructuras de datos y algoritmos en Go

Descargo de responsabilidad: soy autor de todos los libros anteriores.

Las personas de software más exitosas y productivas son pensadores profundos, no necesariamente pensadores rápidos, por lo que cualquier entrevista que se base en una tarea arrojará una alta tasa de falsos negativos, lo que significa que muchos ingenieros altamente productivos tendrán un mal desempeño y serán rechazados.

No tenemos una mejor manera de evaluar a los desarrolladores sin experiencia . El costo de una mala contratación es extremadamente alto, por lo que nos comprometemos con este proceso imperfecto y esperamos lo mejor.

¿Por qué tantas compañías todavía usan el mismo proceso para desarrolladores experimentados ? El rey lleva más tiempo desnudo y nadie se atreve a decir una palabra.

En mi experiencia, es mucho más valioso emparejar al candidato con los entrevistadores con antecedentes apropiados para que puedan centrarse en validar que el candidato se convirtió en un experto en las áreas en las que trabajó en los últimos X años.

Deben hacer preguntas de codificación relevantes basadas en la experiencia del candidato, en lugar de pasar por defecto a un cuestionario de un tamaño (no) adecuado para todos los algoritmos o alguna asignación de codificación aleatoria.

Respuesta corta: sí.

Y ahora para la respuesta no tan corta …

Hay trabajadores calificados y productivos en todas las industrias que luchan con las entrevistas. Para los desarrolladores, el desempeño en las entrevistas técnicas varía mucho de persona a persona, dependiendo de sus fortalezas individuales en lo que respecta a la programación. Pero no ser “naturalmente” bueno en las entrevistas no es excusa para darse por vencido y tener un desempeño pobre en las entrevistas técnicas.

Hay muchos recursos que puede utilizar para practicar y mejorar sus posibilidades de tener éxito en su entrevista técnica. InterviewCake y Pramp son plataformas en línea que le permiten practicar entrevistas de codificación en vivo con otra persona. Puede practicar tanto desde la perspectiva del entrevistador como del entrevistado. Hay otros sitios web en línea para completar problemas de práctica, revisar los conceptos básicos y fortalecer sus habilidades de comunicación. La combinación de practicar y prepararse para las entrevistas lo ayudará a sentirse mucho más seguro de lo real.

Una entrevista de trabajo mide mucho más que su productividad y habilidades de codificación. Además de mostrar sus habilidades y destrezas, debe venderse como un gran candidato para el puesto y la empresa. Practique, prepare e irradie confianza en su entrevista, ¡y aumentará drásticamente sus posibilidades de éxito!

Sin duda. ¿Por qué?

1. Las entrevistas técnicas en su mayoría verifican su destreza en estructuras de datos y algoritmos. Lo recuerdas mejor mientras estabas en la universidad. Ganas experiencia, comienzas a olvidar.
2. Muchos de estos desarrolladores productivos están acostumbrados a un IDE, es decir , finalización automática y sugerencia automática . ¡Así es como aumentan su productividad! Es posible que algunos no puedan replicar lo mismo en una pizarra blanca.
3. Muchos de estos desarrolladores productivos nunca van a usar un Trie o un BST autoequilibrante en el trabajo. O conoce muchos algoritmos. Si es necesario, usan bibliotecas. Es posible que no sepan lo que sucede internamente.
4. A algunas personas simplemente no les gusta la codificación de pizarra.
5. Algunas personas son malas para las entrevistas, pero son buenas con el código. Acepta eso.
6. Tienes más de 15 años de experiencia bajo el cinturón. ¿Y se le pregunta cómo fusionar dos matrices ordenadas ? Muchos se ofenden con esa línea de entrevistas.
7. Es posible que no hayan sido entrevistados durante años. Podría haber perdido el toque. Las entrevistas son un arte después de todo.

Agregaré uno más a la pila de ingenieros diciendo que sí.

Mi ejemplo personal favorito:

En el verano de 2016, me hicieron una pregunta relativamente simple sobre cómo usar operadores bit a bit para resolver un rompecabezas simple mientras utilizo una herramienta de codificación compartida. Sabía que alguien estaba mirando una pantalla en algún lugar esperando que escribiera.

Probablemente escribí mis primeras operaciones bit a bit en 87 y las aprecio mucho y las uso con frecuencia. Sin embargo, también puedo ser una criatura ansiosa y no me gustan este tipo de entrevistas. No pude escribir nada útil en el tiempo dado. Fallé la pantalla de tecnología de ingeniería junior y me negaron el trabajo. Si me hubieran dado el trabajo, probablemente habría sido el responsable de asesorar a la persona que me realiza la evaluación técnica.

Lo que creo que es más interesante sobre este ejemplo en particular es que estaba diseñando y programando personalmente una plataforma en la que las operaciones complicadas a nivel de bits serán esenciales para que la plataforma funcione a escala. Es una plataforma que se centrará en la gestión de problemas de calidad de datos en el espacio de big data. A medida que lo saque de alfa, comenzaré a usar los recursos de mi equipo para terminar la plataforma. Entonces, para hacer esto aún más vergonzoso, también tuve que escribir algunas demostraciones de entrenamiento ligero sobre cómo codificar con operaciones bit a bit para algunos de nuestros ingenieros que no están familiarizados con ellos.

¡Absolutamente! Yo, por mi parte, y es por eso que no sigo el paquete con la forma en que muchas empresas entrevistan en estos días …

Cuando entrevisto a personas, tiendo a hacer preguntas de diseño para ver cómo abordan un problema y reunir requisitos. La habilidad que estoy buscando es el desarrollo de aplicaciones, que es más que solo un par de algoritmos que probablemente puedas buscar y adaptar a tus propósitos.

También estoy buscando una buena actitud, la capacidad de comunicarme y trabajar en equipo. Si no puede traducir requisitos vagos de usuarios no técnicos a un diseño, ¿qué diferencia hay si combinan realmente bien 2 listas enlazadas? Si no hace preguntas y sabe cómo reducir los requisitos a algo que puede codificar eso funcionará para el usuario, sé que alimentaré a esta persona con una cuchara para que escriba la función X. Luego escriba Y y tendré que diseñar para ellos.

Eso es solo lo que pienso, puedes entrenar en algoritmos, no puedes entrenar una actitud. Desearía que menos personas estuvieran tan concentradas en preguntar la forma más rápida de eliminar duplicados de una secuencia de enteros, y más enfocadas en, ¿puede esta persona crear una aplicación en el mundo real, entendiendo lo que el usuario quiere? ¿Consideran las limitaciones de mantenimiento, tiempo y presupuesto?

Quiero saber el contexto de esta pregunta, qué significan estos datos, cómo se utilizarán, no solo responder ciegamente una pregunta teórica que probablemente se haya resuelto en una biblioteca de código abierto.

Esto no es la universidad, este es el mundo real, a veces hacemos lo que es conveniente (saber cuándo “invertir” en deuda técnica es una gran habilidad laboral) para estar a tiempo y presupuestar y satisfacer las necesidades de los usuarios. El código mantenible es más importante que la elegancia, si alguien puede entenderlo y modificarlo para futuros requisitos desconocidos, ¡ese es un buen software!

Eso es solo mis $ 0.02 …

He sido un desarrollador exitoso y productivo. No siempre me veo bien en las entrevistas técnicas. Algunas razones para esto …

• Han pasado 35 años desde la última vez que asistí a la universidad. Las preguntas de la entrevista se parecen mucho a los problemas de tarea de Ciencias de la Computación, y no tanto como el trabajo que hace un ingeniero de software todos los días, así que estoy fuera de práctica. He tenido que compensar al volver a practicar mis habilidades de resolución de tareas de CS.
• Sé mucho sobre algoritmos, pero mi carrera ha influido en los algoritmos que uso con frecuencia. Mi memoria para los algoritmos que no he usado con frecuencia se ha degradado durante 35 años. Uno podría afirmar que este es un defecto legítimo en mi conocimiento actual.
• Como desarrollador, no soy un pensador particularmente lineal. Para mí, escribir código es un proceso iterativo de revisión y refinación. Escribir código en la pizarra premia el pensamiento lineal. Recompensa la escritura desde la primera línea hasta la última, en lugar de desde afuera hacia adentro. No recompensa la fabricación de herramientas en forma de funciones auxiliares.
• Tengo una discapacidad, baja agudeza visual, lo que me hace parecer algo tentativo cuando uso una computadora o escribo en la pizarra. Esto no ha limitado de ninguna manera mi capacidad para tener una carrera o hacer un trabajo innovador, pero me hace ver sin preparación.

Sí, aunque como lo indican otros, no hay un tipo de entrevista técnica. En los años 90, Microsoft abrió el camino haciendo preguntas y acertijos, y muchas compañías se unieron, solo para finalmente darse cuenta de que, por mucho que nos guste hablar sobre programación como resolución de acertijos, no es eso. Muchas personas no podían ver las soluciones que eran obvias para otras personas, pero no reflejaban en absoluto la capacidad de ninguno de los dos para desarrollar software. Ahora tenemos el problema de las estructuras de datos y los algoritmos de la pizarra, y eso se acercará un poco más a las habilidades requeridas, pero aún se centra en un conjunto de habilidades estrechas que la persona podría no demostrar bien, independientemente de su comprensión. Lo difícil es no ser entrevistado o realizar una entrevista, es aprender a leer una entrevista. Como entrevistado, aprendí qué buscar en personas para las que NO quería trabajar, y cuando contraté, traduje eso. Solía ​​contratar personas de naturaleza inquisitiva y experimental que no tenían miedo de hacer preguntas y expresar sus limitaciones y preocupaciones. De lo contrario, obtienes hermanos tecnológicos hiperconfiados que superaron a Data Structures and Algorithms and Machismo 101, y terminan no siendo jugadores de equipo y no lidian bien con la complejidad de los problemas del mundo real que no se pueden resolver en una hora.

Dicho esto, debes aprender a presentarte bien. Aconsejo a todos mis alumnos que tomen clases introductorias de actuación. Muy pocos lo hacen, pero aquellos que lo hacen tienden a lidiar muy bien con todo tipo de entrevistas, incluidas entrevistas técnicas, independientemente de sus calificaciones en estructuras de datos y algoritmos. No se trata solo de obtener una respuesta correcta.

Hazme una pregunta sobre un juguete y te daré una respuesta. Si eso no es lo que está buscando, primero tiene que darme los requisitos. De lo contrario, estamos perdiendo el tiempo.

Tengo una queja sobre la experiencia de contratación que me hizo darme cuenta de eso. Soy 2e ADHD y no puedo sentir el subtexto. La parte 2e sale como un pensador visual no lineal largo. Tampoco son particularmente grandes corp. compatible. Pero he estado diseñando desde 1969 y la puesta en marcha de Chief Scientist o equivalente durante la mayor parte de ese tiempo, sin entrevistas. No pierdo el tiempo sobre ingeniería de trivialidades por su propio bien. Incrustado y comunicaciones de datos parecen ser de lo que se alimenta mi cerebro. Si alguna vez tengo que volver a hacer esto (es poco probable, cumpliré 70 años en noviembre), pediré requisitos y restricciones.

Así que me perdieron por una mofeta que funciona dentro de Nintendo. Hace 9 años. Tenía otras dos ofertas al mismo tiempo. Tomé la decisión correcta. Los otros tres grupos, dos ofertas y un insulto, desaparecieron en dos años.

¿Creo que si yo fuera un programador falso ya lo habrían notado?

Yo no siempre

• No siempre puedo pensar sobre mis pies lo suficientemente rápido. Podría dar una mala respuesta en vivo, luego recordar una gran historia al día siguiente
• No puedo hacer las cosas de la pizarra del algoritmo CS, ya que nunca las estudié. No los necesitas en el trabajo general
• Algunas pruebas de codificación son ‘este código extraño no se compila, dinos por qué’ ¿Honestamente? No tengo idea. Nunca escribiría tonterías así.
• Recientemente pasé un día completo preparando lo que pensé que era una presentación de 20 minutos sobre la calidad del software. Tenía una metáfora del juego de mesa y todo. No creo que a nadie realmente le importara

Las entrevistas están tan alejadas del trabajo que ser bueno en el trabajo no garantiza la aprobación de la entrevista.

Claro, soy uno de ellos. Solía ​​estar avergonzado de eso, pero ya no. Simplemente no puedo codificar en una pizarra blanca. Si entro en una entrevista y me piden que haga eso. Me disculparé cortésmente y me iré. Mi razonamiento es que si tienen una comprensión tan pobre de lo que lo convierte en un buen ingeniero, no es probable que disfrute trabajando allí de todos modos, así que prefiero pasar. Además, no es que tengamos una falta de oportunidades de todos modos, ¿por qué molestarse?

Ya ves, tengo una horrible escritura a mano. Afortunadamente, escribo todo en una computadora. Codificación en una computadora? Qué idea tan novedosa ¿verdad?

No necesito necesariamente un IDE para crear algo, pero necesito poder insertar cosas sin borrar toda la placa porque me di cuenta de que necesito un bucle anidado o un nuevo} else if () {.

La entrevista técnica es bastante vaga … La mayoría de la gente piensa que las entrevistas técnicas son como escribir en una pizarra, así que esa es mi opinión. Creo firmemente que es posible ser técnico sin involucrar a un Sharpie.

Sí, por supuesto.

Me consideraría un desarrollador productivo, bueno, nunca he tenido ninguna queja en ese departamento.

Sin embargo, si fuera a hacer una entrevista formal en la pizarra, estaría bastante seguro de mi capacidad de caer en una bola de llamas, creo que lo fallaría, creo que fallaría tanto que vuelva a verificar la prueba …

¿Por qué? Simplemente no tengo práctica ni experiencia en ello. Estoy acostumbrado a proyectos del mundo real, usando IDEs, obteniendo resultados de depuración, trabajando en mi propio tiempo a mi manera.

En la programación profesional, no escribes algoritmos de ordenación de burbujas, llamas al método sort ().

Aviad Ezra hace una muy buena observación, las compañías usan estas entrevistas porque no han pensado en nada mejor.

¿Por qué no me va bien en estas pruebas? Porque no tienen sentido.

El problema es que paso 2 horas de mi vida construyendo un sistema que será juzgado por alguien en base a algunos criterios desconocidos (por ejemplo, se prefiere la colocación del soporte C de K&R).

Luego presento esto para obtener una entrevista para alguna compañía en la que quizás no quiera trabajar porque no tienen el tiempo que perder, por lo que la prueba técnica filtra a sus solicitantes rápidamente.

Si esta aplicación se iba a integrar en un sistema, entonces vale la pena pasar el tiempo extra haciendo todos los controles y equilibrios. Todo lo que quiero hacer es demostrar que puedo responder la pregunta lo más rápido posible para pasar a la siguiente fase.

Las preguntas en sí mismas no son realistas. Tuve una prueba en línea sin completar ni cortar y pegar. (Como se señaló, ahora dependemos más de fragmentos y autocompletado). Las tres preguntas requerían una programación recursiva completa. En los últimos cinco años, pude haber usado la programación recursiva 3 veces y tuve que justificar la complejidad e incluso explicar cómo y por qué funciona. Así falta de verificación de la realidad.

Algunos son tan vagos que no tienen respuesta. Por ejemplo, tengo suficientes datos para calcular valores individuales para los datos, pero quieren combinaciones vagas de datos. ¿Los quieren a todos? ¿Quieren una serie de servicios web? ¿Qué quieren decir con algunos de los grupos? Los requisitos son claros al principio, pero el conjunto de resultados requerido es vago y no hay un gerente de producto para aclararlo.

Quiere una buena prueba de tecnología. Pruebe este: Únase a Readify Le dan una URL para validar los resultados. Puede implementar la solución de la forma que desee.

Esto sigue siendo un problema importante cuando ha estado codificando durante años y de repente se le pide que haga un trabajo sin sentido solo para satisfacer una casilla de verificación.

Por supuesto. Algunas personas tienen ansiedad social y no se encuentran bien en las entrevistas en general. Entonces tienes personas que tienen dificultades para funcionar cuando están nerviosas, pero que son muy productivas en un ambiente más relajado.

Algunas personas no son excelentes para la memorización y compensan teniendo a mano muchas “hojas de trucos” … a las que no tienen acceso durante una entrevista.

Una entrevista es un entorno muy diferente de la programación y el desarrollo del día a día. Algunas personas obtienen buenos resultados en un entorno de entrevistas, pero mal en “el mundo real”, y otras son lo contrario.