Para los trabajos de desarrollo de aplicaciones SQL y C #, los entrevistadores suelen hacer preguntas sobre los recorridos de árbol, gráfico y lista enlazada utilizando C y punteros puros. En los 3 años que he pasado en mi trabajo, nunca he tenido que
encontrar la ruta al primer nodo a la derecha de un nodo dado que es un múltiplo del nodo dado
por ejemplo
Puedo ver que estas habilidades pueden usarse en trabajos en los que necesita escribir compiladores, controladores y trabajar en el núcleo del sistema operativo. Aparte de esos, ¿dónde más se usan estas habilidades?
Respuestas:
Lea algunas de las respuestas de Joel a continuación.
Especialmente tenga en cuenta algo como Schmiel el pintor. En el trabajo, es posible que nunca tenga que volver a escribir una lista vinculada, pero ciertamente debe saber cómo funciona, para evitar a Schmiel.
Básicamente, si vas al médico, querrás que ese médico haya estudiado anatomía. Aunque ella solo le está recetando un poco de antihistamínico, un médico habrá aprendido en la escuela de medicina que ciertos medicamentos son malos para las personas con 'fractios diamadabada crónica en el fémur inferior' o lo que sea. Este tipo de conocimiento profundo de TODO en esa especialidad a veces puede hacer la diferencia entre la vida y la muerte, y en la Tecnología de la Información entre la vida y la muerte del producto, o un trabajo.
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
http://www.joelonsoftware.com/articles/fog0000000319.html
"... pase al menos un semestre acercándose a la máquina o nunca podrá crear código eficiente en idiomas de nivel superior ..."
"... en lo que a mí respecta, estás programando en base a la superstición: un médico que no conoce la anatomía básica, distribuye recetas basadas en lo que el vendedor farmacéutico dijo que funcionaría".
http://www.joelonsoftware.com/articles/CollegeAdvice.html
fuente
Ellos no están. Muchas entrevistas son realizadas por personas que no saben cómo buscar desarrolladores hábiles , y no saben qué preguntas deberían o no deberían hacer.
La mayoría de los entrevistadores no hacen preguntas técnicas en absoluto, y están más concentrados en cosas sin sentido pero medibles , como la cantidad de proyectos en los que ha participado (más es mejor para esos entrevistadores) o el título universitario (más alto es mejor para ellos ) Están felices de contratar a una persona que perdió cinco años en la universidad sin aprender nada y luego pasó diez años haciendo docenas de sitios web de comercio electrónico, pero no contratará a una persona que abandonó la universidad después de unos años y estaba trabajando en algunos Grandes proyectos técnicamente desafiantes.
Hacer al menos preguntas teóricas es mejor que no hacer ninguna. Esto tiene el beneficio de verificar que la persona tiene suficiente conocimiento teórico y no es un programador que puede tener algunos años de experiencia con la programación, pero que realmente no comprende lo que está sucediendo bajo el capó. Los desarrolladores que no tienen este conocimiento teórico por lo general no conocen la diferencia entre una lista, una lista vinculada, una búsqueda o un conjunto de hash, y los usan indistintamente.
Buenas preguntas (técnicas), malas preguntas
Durante las entrevistas, puede encontrar preguntas que van desde muy buenas hasta extremadamente malas:
(Nocivo) "¿Cuál es la longitud en líneas del programa de trabajo más largo que ha escrito en ese idioma?"
Esta pregunta es claramente errónea. Ya expliqué por qué en otra respuesta . La compañía donde los entrevistadores hacen tales preguntas tiene grandes posibilidades de evaluar la productividad de los desarrolladores en LOC / mes. Si tengo que dar un consejo: no necesitas ese trabajo.
Este ejemplo es diferente de las cosas sin sentido pero medibles que he citado al comienzo de mi respuesta. Aquí, el entrevistador también muestra que ni siquiera tiene la comprensión más básica de las métricas al elegir una que sea conocida por ser dañina.
(Malo) "¿Quién es Dennis Ritchie?"
Tener al menos algo de cultura es de hecho muy útil, pero hacer esas preguntas pierde el punto. Si la compañía busca desarrolladores talentosos que puedan manejar proyectos de desarrollo de software y escribir código, el hecho de que no conozcan el nombre de la persona que creó C y Unix no debería importar demasiado.
(Bien) "¿Cuáles son las nuevas características de .NET 4.5?"
Esta pregunta es mucho más interesante que la de Dennis Ritchie. Si el candidato no puede hablar sobre nuevas características en .NET 4.5, ¿por qué se hace llamar desarrollador C #? La falta de tal conocimiento:
Muestra que la persona puede no estar realmente interesada ni en el lenguaje de programación ni en la comunidad .NET,
Indica que la persona puede carecer de algunos conocimientos cruciales sobre las características de C # / .NET que otros desarrolladores usan si no a diario, al menos con frecuencia.
Vea también la respuesta de Jerry Coffin que contiene un análisis más detallado de este tipo de preguntas.
(Promedio) "¿Cuál es más rápido, SSD o RAM?"
Esto puede ser útil y muestra si la persona tiene suficiente conocimiento de hardware, pero aún así, un candidato que no puede responder a esta pregunta no debe ser rechazado.
(Promedio) "¿Cómo se implementan la pila y la cola?"
Este es el tipo de preguntas de las que habla. Son teóricos, tal vez incluso demasiado teóricos, pero saber lo que sucede debajo del capó puede ayudar a escribir un mejor código.
No rechazaría a un candidato que no pueda responder esta pregunta, pero comprobaré con más cuidado si realmente sabe las cosas, por ejemplo, haciendo una pregunta relacionada pero menos teórica:
(Bien) "¿Cómo puedes caminar a través de un árbol sin usar la recursividad?"
Si el candidato responde a esta pregunta, hablando sobre FILO / FIFO y sobre los beneficios y las desventajas de usar una pila versus una recursividad para el recorrido del árbol, en realidad no importa que no haya podido responder la pregunta anterior.
Hacer esta pregunta también es una buena manera de detectar candidatos que pasaron años haciendo su título de CS, pero que no tienen experiencia en el campo.
¿Cómo hacer buenas preguntas técnicas?
El comentario de kojiro es interesante y merece una respuesta más larga:
Encontrar buenas preguntas puede ser un desafío, especialmente cuando contrata a su primer desarrollador o cuando contrata a un desarrollador que se espera que sea más hábil que todos los desarrolladores que realmente trabajan en la empresa.
Aquí hay tres consejos que pueden ayudar:
Encuentra un amigo / compañero de trabajo que creemos que es experto y pedir lo que hacer las revisiones. Esto requiere mucha confianza, pero puede beneficiar mucho a su empresa.
Busque un consultor que crea que es experto y pídale que lo ayude o haga la parte técnica de la entrevista.
Escriba "preguntas de la entrevista" en Google. Funciona bastante bien y generalmente explica posibles respuestas. Ejemplo:
Python : esas diez preguntas parecen bastante buenas. Quizás sean un poco básicos, pero ayudarán a filtrar el 95% de los candidatos que no desea contratar de todos modos.
SQL por Dave Pinal, excelente como siempre.
C # : un poco demasiado básico, pero nuevamente, filtrarán el 95% de los candidatos,
JavaScript : las preguntas son más abiertas, lo que puede no ser bueno para las preguntas técnicas si desea que la entrevista sea breve y tenga más tiempo para las preguntas no técnicas abiertas. La lista todavía ayuda a filtrar fácilmente a los candidatos que no entienden los conceptos básicos en JavaScript.
El inconveniente de este enfoque es que el candidato puede usar la misma técnica para entrenar para la entrevista. Si revisó todas las preguntas del primer sitio web que encontró en Google, puede obtener una buena puntuación, sin tener las habilidades requeridas.
¹ Hay algunos desarrolladores que no podrán explicar qué es un árbol B (aparte de que es "alguna estructura de datos"), pero aún pueden desarrollarse correctamente.
fuente
Según mi experiencia en mi empresa, donde hice muchas entrevistas, hay muchas posibilidades de que la persona entrevistada no tenga idea de cómo hacerlo correctamente. Así que prepararon un conjunto de preguntas técnicas y calcularon un puntaje de eso y lo convirtieron en su currículum. Sin embargo, esto tiene muchos inconvenientes y no debe hacerse por los siguientes motivos:
Pides conocimiento puntual. Si el programador nunca ha hecho algo en esa área, podría ser un excelente compañero de trabajo, pero simplemente no sabe esa respuesta en particular. Por el contrario: si alguien se preparó para la entrevista y encontró la respuesta a esa pregunta en particular en la red, obtendrá la respuesta correcta, pero esa persona podría no tener idea sobre el tema real.
La gente está nerviosa en las entrevistas de trabajo. El cerebro tiene esta gran característica para cerrar muchas áreas de nivel superior (como la lógica) si está en pánico, lo que significa: si está nervioso, es posible que no brinde la calidad de las respuestas que lo haría en una situación cotidiana. Algunas personas pueden lidiar con una situación estresante como una entrevista, muchas no pueden.
Con una sola respuesta correcta, prueba la habilidad de esa persona para encontrar esa respuesta en particular. Esta es una de las muchas habilidades que necesita un compañero de trabajo, pero no es la única que se requiere. Por lo tanto, una o dos de esas preguntas deberían ser suficientes para evaluar esa área de conocimiento, y luego se deberían consultar otras habilidades. Una entrevista que solo contiene preguntas para resolver problemas evalúa la misma habilidad una y otra vez.
¿Cuáles son buenas preguntas de tareas de programación?
Las famosas preguntas "¿Puedes escribir un programa corto?" Tienen el gran problema de que la mayoría de los programadores no pueden escribir una sola línea de código sin que su IDE les ayude. Pero eso no es un problema en el día a día, porque el programador siempre tiene su IDE que lo ayuda. Entonces, preguntar cosas como "Encontrar el error", "Escribir 50 líneas de código que sí ..." o incluso preguntas simples deben tenerse en cuenta, que el solicitante no tiene sus herramientas (IDE, Google) disponibles.
Por ejemplo, puedo responderle básicamente cualquier pregunta dentro de 1 minuto si tengo Google ayudándome, pero sin conexión a Internet, parezco indefenso. Llamo a eso memoria subcontratada y, en lugar de obstaculizarme, me ayuda mucho a concentrarme en lo que es realmente importante: comprender la mecánica subyacente, porque todo lo demás se puede buscar. Pero no me pregunte sobre los detalles de ninguna API aleatoria, porque no los conozco, tengo Google para eso.
Dicho esto, una buena pregunta de tarea de programación no debe centrarse en conocer API o habilidades especiales de codificación a menos que sea un requisito absoluto para el trabajo. Se puede obtener conocimiento, por lo que es mejor descubrir qué tan buena es esa persona para obtener conocimiento que preguntar qué es lo que ya sabe.
Una buena pregunta para una tarea de programación debe ser corta, simple, capaz de codificarse en todos los idiomas con solo unas pocas líneas de código y, especialmente, debe informarle lo más posible sobre cómo trabaja la persona y encuentra las respuestas. Ejemplo:
Lo primero que cualquier solicitante debe preguntar en este punto es: "Lo siento ... ¿puede explicar la tarea?". Porque ningún programador ha recibido una descripción clara sobre qué hacer. Esto es seguido por la explicación, que el código en las preguntas debe hacer un desplazamiento hacia la izquierda del contenido de la matriz con el desbordamiento que se agrega a la derecha.
Esta tarea es tan simple que cualquier persona que se haya graduado de cualquier forma de nivel de programación debería poder responder correctamente. Esto tiene en cuenta que el programador tiene que trabajar sin sus herramientas y que estar nervioso reduce la capacidad de pensar lógicamente. Sin embargo, todavía le dice cómo las personas resuelven los problemas solo por la forma en que está formulada la pregunta y por la forma en que las personas la abordan, simplemente porque un desplazamiento a la izquierda está en contra del instinto común de 'izquierda a derecha' y obliga a las personas a pensar por un segundo.
Hay muchas respuestas posibles a esta pregunta, por lo que echar un vistazo de cerca a la forma en que se desarrolla el código es la parte importante, no si la solución realmente funciona. ¿El solicitante prueba nulo? ¿Cómo se almacena el desbordamiento? ¿Se utiliza un bucle o un conjunto de memoria? ¿Cómo verifica el solicitante la corrección del código? Esta simple pregunta te dice una biografía completa sobre cómo funciona esa persona.
¿Cuáles son buenas preguntas de conocimiento general?
Las buenas preguntas son fáciles de responder, permiten una gran cantidad de respuestas (llamadas 'preguntas abiertas') y le permiten aprender tanto como sea posible sobre el solicitante en el poco tiempo que tenga.
Ejemplos:
Esta es una pregunta de nivel de entrada, que le da al solicitante una oportunidad justa de rescatar en este momento si no sabe nada sobre el tema que se le preguntó. Un "no" en este punto es mejor que atormentarlo con varias preguntas más con las que él / ella tiene que responder: "Lo siento, no sé nada de eso".
Además, le dice, en primer lugar, qué otros idiomas conoce esa persona, además, aprende qué tan interesada está esa persona para obtener una visión más amplia del mundo de la programación, o si tiene a alguien con solo un lenguaje singular (y, por lo tanto, características / técnicas ) vista.
Esta es una pregunta abierta que permite muchas respuestas, por lo que el solicitante tiene una buena oportunidad de encontrar al menos tres. Pedir los tres primeros (opinión personal) no solo limita las posibles respuestas, sino que también obliga al solicitante a ordenar según la prioridad. Aún así es (o debería ser) fácil de responder.
Esta es una pregunta simple que pone a prueba muchos conocimientos profundos sobre diferentes lenguajes de programación. ¿Cuán profundo es realmente el conocimiento de esos temas? De esas respuestas puede decir mucho sobre el conocimiento y la comprensión real de la mecánica subyacente de los lenguajes de programación. Cuánto gastó esa persona con los detalles sucios, o si él / ella es solo alguien que vincula varias funciones API sin tener una idea real de lo que sucede debajo de ellas.
Este concepto de preguntas de nivel de entrada seguido de preguntas simples de conocimiento en profundidad también se puede utilizar para la mayoría de los otros temas. Siempre en este esquema: pregunta de rescate, pregunta de verificación, pregunta en profundidad. Otro ejemplo (de una entrevista Java):
Estas tres preguntas le dirán más que cualquier pregunta técnica lo que el solicitante realmente sabe sobre esos temas, mientras que es justo responder teniendo en cuenta el conocimiento de puntos y el nivel de estrés.
Entonces, la próxima vez que alguien le haga 20 preguntas de codificación seguidas, sabrá que básicamente no tiene idea de cómo entrevistar a alguien adecuadamente. ;)
fuente
Advertencia: esto está escrito como (una especie de) comentario sobre la respuesta de @ MainMa, pero 1) es demasiado largo para caber en un comentario, y 2) Creo que agrega una perspectiva algo diferente sobre las preguntas constructivas, por lo que es una respuesta real en sí misma .
En su respuesta, @MainMa clasifica "¿Cuáles son las nuevas características de .NET 4.5?" como una "buena" pregunta
Siento disentir. Como lo expresó, diría que esta es una pregunta bastante mediocre en el mejor de los casos. Una buena pregunta sería más como: "¿En qué se diferencia el código que escribe hoy del código que escribió hace N años?" (para un valor de N menor que los años de experiencia enumerados en el currículum, preferiblemente alrededor de 3 a 5).
Tal como lo expresó, la pregunta es sobre la memorización. ¿Este candidato ha memorizado la lista de características por completo? Por derecho, el que cita la lista de Microsoft con mayor precisión debería ser el ganador.
Lo que debe preocuparte es su programación. ¿Cómo ha afectado esto a su código? ¿Cuál de estas características tiene que realmente usan ? Más importante aún, ¿muestra un buen juicio sobre cuándo usar qué nuevas funciones y cuándo las anteriores son suficientes?
El solo hecho de poder decir "LINQ" prácticamente no le dice nada útil sobre el candidato. Poder decir: "LINQ ha ayudado a hacer que mi código sea mucho más compacto y legible porque puedo expresar los conceptos X, Y y Z de manera limpia y directa, donde anteriormente tuve que saltar a través de los siguientes aros en llamas para hacer esas cosas". (o algo similar) le dice mucho sobre el candidato, qué tipo de código escribe, su criterio, flexibilidad, etc. También le brinda muchas más oportunidades para preguntas de seguimiento sobre cómo esta persona piensa sobre los problemas, escribe el código, piensa sobre el código, etc. Finalmente, le da una idea mucho mejor de si este es un candidato que realmente tiene N años de experiencia, o alguien que tiene un año de experiencia, N repetidas veces.
Resumen: poder citar una lista de características de hace unos años es inútil, y le dice poco sobre el candidato que probablemente sea de utilidad real. Es probable que el progreso del candidato como programador sea mucho más interesante, por lo que es mucho mejor preguntar sobre eso más directamente.
fuente
La realidad es que la mayoría de las tareas cotidianas que la mayoría de los desarrolladores realizan en su vida profesional son triviales; Eso significa que algunas de las preguntas que enfrenta en una entrevista de trabajo podrían nunca enfrentarse en realidad, pero eso no significa que no tenga sentido hacer esas preguntas.
Digamos que hay un puesto abierto en su empresa y actualmente está entrevistando a personas. Ya tienes 20-30 desarrolladores en la cola. Entonces, ¿cómo elegirías al mejor candidato para ese puesto? Digamos que la tarea más difícil que tienen que hacer en ese trabajo es abrir un archivo del sistema de archivos, leer los datos línea por línea, modificarlo ligeramente y volver a colocarlo en el archivo original.
¿Vas a preguntarles cómo abrirías un archivo? Apuesto a que no puedes ver una gran diferencia entre las respuestas. Por lo tanto, debe encontrar una solución para distinguir entre los desarrolladores que solo saben cómo abrir un archivo y aquellos que pueden desarrollar una aplicación en tiempo real. Incluso aunque no desee que creen una aplicación de este tipo, desea contratar al mejor candidato.
Como cualquier otra cosa en nuestra vida, hay algunos puntos que te das cuenta de que necesitas ir y aprender más. Si no sabes qué es una lista vinculada, para mí como programador, eso significa literalmente que realmente no has llegado a ese punto en tu vida profesional para sentir que necesitas ir y aprender esa cosa específica. ¿Por qué? Simplemente porque nunca participó en un proyecto lo suficientemente grande como para exigirle que mejore sus habilidades hasta ese nivel. Si está en un nivel de entrada, podría decir que realmente no tengo ninguna experiencia laboral para este trabajo específico, pero aún si lo sabe, eso significa que está lo suficientemente motivado como para ponerse en el corte por encima del promedio al menos.
fuente
Las habilidades necesarias para realizar estas tareas rara vez son importantes. Las habilidades demostradas en el enfoque para responder la pregunta y en el diálogo posterior son el punto central.
Cuando entrevisto a los desarrolladores, busco (a) inteligente (b) hace las cosas (c) encajará. Se requiere un nivel básico de conocimiento técnico para cumplir cualquier función, que debe ir con la voluntad de aprender y adquirir nuevos habilidades. La entrevista trata sobre marcar esas casillas.
Mi preferencia es leer el código escrito por un solicitante. No me gustan las preguntas de entrevistas enlatadas, pero proporcionan algo de qué hablar en ausencia de código. Prefiero preguntar sobre RAII o IOC o la implementación de IDisposable en lugar de listas y colecciones, pero cualquier cosa servirá siempre que podamos hacerlo lo suficientemente técnico .
El peor temor del entrevistador es contratar a alguien que en realidad no sabe mucho sobre codificación. Tienes que hablar de algo más que experiencia laboral para eliminar las falsificaciones.
fuente
Estas preguntas son para descartar personas que no pueden programar. A veces, las personas que no pueden programar pero que conocen muchas curiosidades solicitan trabajos de desarrollo, y hacer que escriban algo que sea útil y no trivial lleva demasiado tiempo para una entrevista.
fuente
¿Qué tal escribir motores de búsqueda, servidores web, navegadores web, procesadores de texto, hojas de cálculo, editores de imágenes, programas de dibujo, servidores de bases de datos, bioinformática, programas comerciales, juegos, simuladores de física, y así sucesivamente?
Le concederé que la mayoría de los trabajos de software implican extraer datos de una base de datos, colocarlos en una pantalla, editarlos, eliminarlos de la pantalla y volver a colocarlos en una base de datos. Sin embargo, incluso entonces, es posible que eventualmente se encuentre con una aplicación donde las restricciones no pueden ser satisfechas por las características integradas de una plataforma. En ese momento, puede darse por vencido o acceder a su caja de herramientas de algoritmos y estructuras de datos y tomar una decisión para resolver el problema.
fuente
Los objetos teóricos se usan por conveniencia porque se supone que usted sabe de qué se trata una implementación promedio de árbol / gráfico / lista, por lo tanto, sabe cómo resolver un problema transversal aleatorio, pero estas preguntas no se refieren en absoluto a los objetos teóricos.
Se trata de poder trabajar con un modelo abstracto, comprender un problema abstracto y resolverlo con un algoritmo de cualquier tipo. Esto es pura habilidad de desarrollo allí, así que seguro cuenta. Es por eso que esta pregunta tiene sentido, no porque se supone que son situaciones precisas de la vida real.
fuente