¿Cuál es tu pregunta favorita para la entrevista? [cerrado]
21
¿Qué pregunta le ha resultado especialmente valiosa al entrevistar a desarrolladores de software? ¿De qué se trata la pregunta que la ha hecho particularmente útil?
Estoy buscando una pregunta en particular que le gustaría hacer, no solo un enfoque de entrevista como "hacer que escriban código".
La pregunta, como está redactada, no es constructiva, pero tiene algunas buenas respuestas. Reformule la pregunta para que coincida con las mejores respuestas y le recomendaré que se vuelva a abrir.
ChrisF
@ChrisF: reformulé para tratar de obtener un poco más de "compartir experiencias" y "preguntar por qué", que también debería afectar a más de "invita a respuestas más largas". Avíseme si necesita más revisión.
Tim Goodman
¡eso es mejor!
ChrisF
Mirando la pregunta y las respuestas ahora, todavía se siente bastante no constructivo. No parece que ninguna de las respuestas contenga el "por qué" y simplemente enumere las preguntas.
Adam Lear
Respuestas:
29
Eche un vistazo a este código de muestra y dígame cómo lo mejoraría.
Esto es un poco específico para mi escenario, pero creo que fue una gran pregunta, sin embargo:
Entonces dices aquí que nunca has tocado C # o .NET antes, ¿verdad? Ok, entonces aquí hay una estación de trabajo. Descubre cómo escribir un programa que consulta esta base de datos aquí e imprime una lista de Clientes con sus pedidos, ordenados por nombre de cliente. Puede usar cualquier recurso que desee.
La única pregunta que he tenido que realmente puso a prueba mi capacidad de aprender.
Er, ¿no se supone que es una pregunta que te gustaría hacer?
Paddyslacker
8
+1, esta es una pregunta perfecta para hacer. Si no pueden descubrir construcciones de lenguaje básicas con Google, nada los salvará.
Josh K
Me gusta eso, muestra lo bien que pueden aprender un lenguaje de programación que nunca han usado. Podría robar eso para mis preguntas de la entrevista :)
Richard
1
Parece inútil, cualquiera puede copiar y pegar un código .net malo directamente desde msdn.
dotjoe
15
Esta no es una pregunta de codificación, sino de comportamiento:
Hábleme de un momento en que simplemente no pudo completar todo su trabajo a tiempo para cumplir con una fecha límite. ¿Qué hiciste? ¿Cuál fue el resultado?
¿Por qué es esta una buena pregunta? Parece inútil para mí
Joe Phillips, el
99
El punto es que de la respuesta de los desarrolladores obtengo mucha información. En primer lugar, si no admiten que esta situación les haya sucedido, entonces se han estado engañando a sí mismos o no tienen experiencia en proyectos reales. En segundo lugar, si no hablan sobre cómo comunicarían este problema al equipo, sino que solo hablan sobre lo duro que trabajarían para solucionarlo, no quiero contratarlos. La mala comunicación es responsable de la mayoría de los problemas que veo en los proyectos. Quiero contratar comunicadores proactivos.
Paddyslacker
3
¿Puedo hacer una pregunta similar, más general ( "Hábleme de un momento en el que algo salió mal, y lo que hizo en respuesta ...") muy abierta, y sin embargo tuve un entrevistado juro arriba y hacia abajo que nada tenía siempre salió mal para él. No hace falta decir que no lo recomendé para contratar.
Alex Feinman el
13
¿Cómo te metiste en la programación?
Buena manera de ver si la persona tiene pasión por la programación y rompe el hielo.
Al entrevistar a alguien que dice tener una experiencia no trivial en Java, les pregunto sobre hashcode() y equals()y la relación entre ellos. No es realmente posible adquirir una experiencia significativa en Java sin ser consciente de las posibles trampas y cualquiera que ignore el problema agregará errores difíciles de encontrar a mi proyecto.
También preguntaré sobre ArrayListyLinkedList , y las ventajas y desventajas relativas. Con suerte, esto debería demostrar que al menos son conscientes y están pensando en las implicaciones de rendimiento del código que escriben.
También me gusta hacer que expresen una opinión sobre algún tema técnico (la utilidad o no de Maven, excepciones marcadas o no marcadas, etc.), y luego jugar al abogado del diablo para ver qué tan bien pueden argumentar su punto.
+1 Me gusta ArrayList y LinkedList. He visto muchos comentarios sobre SO sobre personas que dicen que las ArrayLists deberían ser abolidas, pero puedo pensar en muchos usos donde son mejores que LinkedLists
Evan Plaice
Jajaja Una vez dos entrevistadores me preguntaron sobre la diferencia entre una lista y un mapa. Les di una mirada tan asombrada, que en realidad se disculparon (y luego respondí a su pregunta y seguimos con la entrevista, por supuesto).
Hila
6
"¿Cuál fue el último (mejor) libro técnico que has leído?"
o, más generalmente:
"¿Cómo mantiene actualizado su conocimiento?"
Es sorprendente cuántas personas nunca leen un libro técnico desde que terminaron la escuela. Y si nunca has leído un libro desde que terminaste la escuela y terminaste la escuela hace diez años, probablemente nunca hayas oído hablar de cosas como pruebas unitarias, patrones de diseño, principios SÓLIDOS ...
Respuesta al comentario :
Puede votarme si lo desea, pero esta es una de mis preguntas favoritas para la entrevista. Blogs, wikipedia, SO son excelentes fuentes para las últimas noticias de alta tecnología. Pero no creo que puedas aprender temas realmente complejos (como las cosas que encuentras en los libros de Knuth) en profundidad leyendo blogs.
Si tengo que elegir entre dos desarrolladores, donde uno muestra esta voluntad de aprender nuevos temas complejos y el otro no, contrataré al primero. Incluso si él o ella quiere más dinero. Pagará a la larga.
-1. Raramente abro libros técnicos, pero sé qué es TTD y conozco algunos de los patrones de diseño. Aprendí mucho más de SO (por ejemplo, qué es el patrón de fábrica) y de los blogs de Jon Skeet y otros profesionales de lo que aprendería de un libro mediocre. Ninguno de los libros que he visto explica, por ejemplo, por qué las comprobaciones de FxCop y StyleCop son tan importantes para escribir un código fuente descendente que pueda reutilizarse (ni siquiera mencionar esas herramientas).
Arseni Mourzenko
3
+1 Puedes aprender mucho con artículos y blogs en línea, pero aun así, no leer libros técnicos implica una falta de iniciativa y mediocridad también para mí.
Dunk
5
Invierta esta lista vinculada. Ahora hazlo en tiempo lineal. Ahora hazlo en tiempo lineal y espacio constante.
Leí esto en una entrevista de uno de los miembros fundadores de Bruel & Kjaer y me impactó. Es muy probable que las personas exitosas se consideren afortunadas. Ven los contratiempos como oportunidades para hacer mejoras y tienden a compartir sus éxitos (suerte) con las personas que los rodean: las personas afortunadas traen más suerte. *
Las personas que se ven desafortunadas tienen más probabilidades de ser una manzana podrida en su equipo.
* En este contexto, la Suerte debe leerse como una oportunidad de reunión de preparación , no como un trébol de cuatro hojas.
Napoleón dijo una vez: "¡Dame generales que tengan suerte!"
Zachary K
4
El que siempre funcionó para mí ...
"Cuéntame sobre tus proyectos anteriores" .
Y luego use sus respuestas como un punto de partida para preguntarles sobre su papel en los proyectos y por qué tomaron ciertas decisiones. En lugar de hacer la entrevista en los SAT, solo tengo una conversación con ellos. Eso siempre ha sido más que suficiente para juzgar si el desarrollador era adecuado para un puesto.
Solo una vez me contrataron para un trabajo donde ya sabía el idioma que se usaba, por lo que las preguntas específicas de idioma no tienen mucho valor para mí. Personalmente, no me interesan mucho las curiosidades sintácticas ( ¿cómo harías un dulce de algodón mientras estás atrapado en un corral lleno de cebras hambrientas? ) Y tengo preguntas, así que nunca hago ese tipo de preguntas.
+1. Yo también pregunto eso. Pero a veces es difícil descubrir cuál era la función del candidato en el proyecto (¿Gerente de proyecto? ¿Desarrollador principal? ¿Desarrollador de mantenimiento? ¿Operador de máquina de café?) Especialmente cuando trabajaban en proyectos grandes con muchas personas.
nikie
2
Si pudieras tener algún trabajo en el mundo, ¿cuál sería?
Solo estoy buscando realmente una cosa: un intento serio de responderla. La única respuesta incorrecta es reír y decirle al entrevistador que es la pregunta de entrevista más cliché del mundo. (No voté contratar).
Realmente es una configuración para mi pregunta favorita de todos los tiempos:
Si quiere ser [una estrella del rock], ¿por qué solicita ser un [ingeniero de desarrollo de Internet III] aquí en [HugeCorp]?
Funciona mejor si realmente dan una respuesta audaz. Raramente lo ven venir y esta es realmente una oportunidad para que alguien brille diciendo algo como "las horas aquí son mejores" o "mi carrera aquí durará más que la típica estrella de rock".
También mentí acerca de que no había una respuesta incorrecta a la primera pregunta. A menos que esté entrevistando para un trabajo soñado totalmente increíble, entonces el trabajo para el que están entrevistando es la respuesta incorrecta. Y si está entrevistando para el trabajo soñado y aún no lo tiene, debe preguntarse por qué no lo está solicitando.
"Y si estás entrevistando para el trabajo soñado y aún no lo tienes, debes preguntarte por qué no lo estás solicitando". - Suena como una pregunta "maldita sea si lo haces, maldita sea si no", especialmente si tratas la respuesta de la manera que la describes. Si alguien tiene un trabajo soñado en mente, tal vez no sienta que está listo para asumirlo y necesita más experiencia con lo que puede aprender en su empresa. ¿Por qué sostener eso contra ellos?
Mark Freedman
44
-1 He rechazado ofertas de trabajo de compañías donde la gente ha hecho preguntas estúpidas totalmente irrelevantes como estas. # 1 No tiene nada que ver con el trabajo o cómo se desempeñaría # 2 En lugar de entrevistar a la persona, el entrevistador realmente está tratando de mostrar cómo son más inteligentes que el entrevistado engañándolos, y créanme que su arrogancia se nota con fuerza # 3 No creo que me gustaría trabajar con pr @ # k $ que hagan ese tipo de preguntas en una entrevista de trabajo si no me gusta en la entrevista. Hacer la pregunta sobre una cerveza, es otra historia.
Dunk
@Dunk: Tienes razón, las preguntas capciosas dicen más sobre el entrevistador que el entrevistado. Pero preguntar sobre los objetivos y deseos de una persona en general tiene sentido. Desea que sus empleados estén contentos con sus trabajos (las personas infelices no son productivas), por lo que desea saber si tiene el trabajo adecuado para ellos.
nikie
@Dunk ya que los clientes con los que trato a diario hacen preguntas cliché y a menudo repiten los mismos errores estúpidos, una pregunta cliché como esta también ayuda a seleccionar el tipo de personas que no pueden tratar con los clientes en mi trabajo. Lo bueno es que el trabajo paga para compensar tener que tolerar ese comportamiento. Entonces, en ese sentido, realmente es la pregunta perfecta.
shemnon
@ Mark Freedman: no lo considero contra ellos. Esto les da la oportunidad de ser honestos y directos sobre su carrera profesional. Si un entrevistado siente que está "condenado si lo hace y condenado si no lo hace", entonces el trabajo no es para ellos. Si no está dispuesto a sacar el cuello con una respuesta honesta, esa es una marca en contra.
shemnon
2
Haciendo entrevistas en C #, me encanta preguntar, "¿Cómo manejas los errores en un método"? Si obtengo una respuesta decente a esa pregunta, pregunto "¿Cómo configuraría / manejaría el manejo de errores en una aplicación web?"
Siempre me sorprende la cantidad de desarrolladores que no tienen problemas con la primera pregunta y no tienen idea de la segunda. Incluso entrevisté a muchos que no podían describir cómo se manejaban los errores en su proyecto actual.
¿Su base de código requiere conocimiento de bit-twiddling o es solo para medir el interés en detalles minuciosos?
Peter Taylor
2
Tenga en cuenta que no dijo "o"
Ben L
1
@Ben, creo que acabas de lanzar una bomba lógica en la trampilla -: /
ocodo
2
¿No es justo (x << 3) - x?
user13278
1
O incluso más simple:x -(-x) - (-x) -(-x) - (-x) -(-x) - (-x)
nikie
1
Similar al de David pero ligeramente diferente:
Eche un vistazo al código de producción real desordenado de una versión anterior que luego corregimos y mejoramos. Dime que hace. Dime dónde están los problemas (corrección y estilo). Dime cómo lo arreglarías y mejorarías.
Esto ayuda a distinguir a las personas que solo pueden escribir código nuevo y las personas que pueden hacer frente a la realidad de las bases de código heredadas.
Es una pregunta bastante profunda: ¿cómo se define una coincidencia? ¿tiene algún conocimiento sobre el pedido parcial en la lista? ¿Qué tipo de lista es? ¿Se pueden ordenar los artículos? ¿Qué tan grande es la lista? ¿Cuál es el costo computacional relativo de comparar versus verificar una coincidencia? Diferentes respuestas a estas preguntas podrían cambiar el enfoque óptimo .....
mikera
¿Con qué frecuencia ocurrirá esta búsqueda? ¿Podría ser un cuello de botella para el rendimiento?
Justsalt
WTF, muchachos. Comience con el primer o el último elemento, compare, si no coincide, pase al siguiente elemento. La única pregunta es: ¿nos importan las coincidencias múltiples o interrumpimos la búsqueda en la primera coincidencia? Si desea dar una idea, puede agregar: Para las listas vinculadas no importa, pero para las listas indexadas, si también quiero extraer coincidencias, atravesaría la lista en orden inverso para no tener que actualizar el índice fuera de la condición del bucle.
NotGaeL
0
Mi pregunta favorita es:
(Presumiblemente en una mezcla de Java / C # y pseudocódigo)
Usando contenedores no exóticos, diseñe una clase que se comporte como un diccionario que sea lo más eficiente posible, que también le permita enumerar las claves no en orden "aleatorio" sino en el orden en que estas claves se agregaron al diccionario ya que fue creado por primera vez.
Este lleva a demasiadas preguntas de aclaración. ¿Es justo usar solo dos tablas hash o una tabla hash y una lista de matriz: una que contenga el orden y otra que contenga el orden? ¿Tiene que ser posible eliminar cosas? (Esto lo hace algo más complicado). Si se actualiza un valor, ¿eso cuenta como volver a agregarlo?
dsimcha
@dsimcha, buen punto. Tengo 20-30 minutos para hablar, y empiezo con: No dude en solicitar aclaraciones en cualquier momento. Si siente que está atascado, me complacería proporcionarle una pista o guiarlo en la dirección correcta. Si la persona todavía está girando sus ruedas, entonces diría que no entienden las estructuras de datos. En cuanto a aclarar lo que quiero, prefiero dejar esto abierto y tomarlo en diferentes direcciones.
Respuestas:
Eche un vistazo a este código de muestra y dígame cómo lo mejoraría.
fuente
Esto es un poco específico para mi escenario, pero creo que fue una gran pregunta, sin embargo:
La única pregunta que he tenido que realmente puso a prueba mi capacidad de aprender.
fuente
Esta no es una pregunta de codificación, sino de comportamiento:
fuente
¿Cómo te metiste en la programación?
Buena manera de ver si la persona tiene pasión por la programación y rompe el hielo.
fuente
Al entrevistar a alguien que dice tener una experiencia no trivial en Java, les pregunto sobre
hashcode()yequals()y la relación entre ellos. No es realmente posible adquirir una experiencia significativa en Java sin ser consciente de las posibles trampas y cualquiera que ignore el problema agregará errores difíciles de encontrar a mi proyecto.También preguntaré sobre
ArrayListyLinkedList, y las ventajas y desventajas relativas. Con suerte, esto debería demostrar que al menos son conscientes y están pensando en las implicaciones de rendimiento del código que escriben.También me gusta hacer que expresen una opinión sobre algún tema técnico (la utilidad o no de Maven, excepciones marcadas o no marcadas, etc.), y luego jugar al abogado del diablo para ver qué tan bien pueden argumentar su punto.
fuente
"¿Cuál fue el último (mejor) libro técnico que has leído?"
o, más generalmente:
"¿Cómo mantiene actualizado su conocimiento?"
Es sorprendente cuántas personas nunca leen un libro técnico desde que terminaron la escuela. Y si nunca has leído un libro desde que terminaste la escuela y terminaste la escuela hace diez años, probablemente nunca hayas oído hablar de cosas como pruebas unitarias, patrones de diseño, principios SÓLIDOS ...
Respuesta al comentario :
Puede votarme si lo desea, pero esta es una de mis preguntas favoritas para la entrevista. Blogs, wikipedia, SO son excelentes fuentes para las últimas noticias de alta tecnología. Pero no creo que puedas aprender temas realmente complejos (como las cosas que encuentras en los libros de Knuth) en profundidad leyendo blogs.
Si tengo que elegir entre dos desarrolladores, donde uno muestra esta voluntad de aprender nuevos temas complejos y el otro no, contrataré al primero. Incluso si él o ella quiere más dinero. Pagará a la larga.
fuente
Invierta esta lista vinculada. Ahora hazlo en tiempo lineal. Ahora hazlo en tiempo lineal y espacio constante.
fuente
¿Te consideras una persona afortunada?
Leí esto en una entrevista de uno de los miembros fundadores de Bruel & Kjaer y me impactó. Es muy probable que las personas exitosas se consideren afortunadas. Ven los contratiempos como oportunidades para hacer mejoras y tienden a compartir sus éxitos (suerte) con las personas que los rodean: las personas afortunadas traen más suerte. *
Las personas que se ven desafortunadas tienen más probabilidades de ser una manzana podrida en su equipo.
* En este contexto, la Suerte debe leerse como una oportunidad de reunión de preparación , no como un trébol de cuatro hojas.
fuente
El que siempre funcionó para mí ...
"Cuéntame sobre tus proyectos anteriores" .
Y luego use sus respuestas como un punto de partida para preguntarles sobre su papel en los proyectos y por qué tomaron ciertas decisiones. En lugar de hacer la entrevista en los SAT, solo tengo una conversación con ellos. Eso siempre ha sido más que suficiente para juzgar si el desarrollador era adecuado para un puesto.
Solo una vez me contrataron para un trabajo donde ya sabía el idioma que se usaba, por lo que las preguntas específicas de idioma no tienen mucho valor para mí. Personalmente, no me interesan mucho las curiosidades sintácticas ( ¿cómo harías un dulce de algodón mientras estás atrapado en un corral lleno de cebras hambrientas? ) Y tengo preguntas, así que nunca hago ese tipo de preguntas.
fuente
Solo estoy buscando realmente una cosa: un intento serio de responderla. La única respuesta incorrecta es reír y decirle al entrevistador que es la pregunta de entrevista más cliché del mundo. (No voté contratar).
Realmente es una configuración para mi pregunta favorita de todos los tiempos:
Funciona mejor si realmente dan una respuesta audaz. Raramente lo ven venir y esta es realmente una oportunidad para que alguien brille diciendo algo como "las horas aquí son mejores" o "mi carrera aquí durará más que la típica estrella de rock".
También mentí acerca de que no había una respuesta incorrecta a la primera pregunta. A menos que esté entrevistando para un trabajo soñado totalmente increíble, entonces el trabajo para el que están entrevistando es la respuesta incorrecta. Y si está entrevistando para el trabajo soñado y aún no lo tiene, debe preguntarse por qué no lo está solicitando.
fuente
Haciendo entrevistas en C #, me encanta preguntar, "¿Cómo manejas los errores en un método"? Si obtengo una respuesta decente a esa pregunta, pregunto "¿Cómo configuraría / manejaría el manejo de errores en una aplicación web?"
Siempre me sorprende la cantidad de desarrolladores que no tienen problemas con la primera pregunta y no tienen idea de la segunda. Incluso entrevisté a muchos que no podían describir cómo se manejaban los errores en su proyecto actual.
fuente
Algo como esto:
multiplique un valor por 7 sin usar
*,/y+operaciones. :)fuente
(x << 3) - x?x -(-x) - (-x) -(-x) - (-x) -(-x) - (-x)Similar al de David pero ligeramente diferente:
Eche un vistazo al código de producción real desordenado de una versión anterior que luego corregimos y mejoramos. Dime que hace. Dime dónde están los problemas (corrección y estilo). Dime cómo lo arreglarías y mejorarías.
Esto ayuda a distinguir a las personas que solo pueden escribir código nuevo y las personas que pueden hacer frente a la realidad de las bases de código heredadas.
fuente
Hace muchos años me preguntaron la diferencia entre las expresiones regulares / a * / y / a *? /
Personalmente, tiendo a hacer algunas preguntas sobre la recursividad.
fuente
?Denota codicioso o cero o uno ? He visto ambas sintaxis.Me sorprende la cantidad de respuestas erróneas a esta pregunta:
¿Cómo buscarías un artículo en una lista sin ordenar?
fuente
Mi pregunta favorita es:
(Presumiblemente en una mezcla de Java / C # y pseudocódigo)
Usando contenedores no exóticos, diseñe una clase que se comporte como un diccionario que sea lo más eficiente posible, que también le permita enumerar las claves no en orden "aleatorio" sino en el orden en que estas claves se agregaron al diccionario ya que fue creado por primera vez.
fuente