¿Cómo manejas las preguntas basadas en el conocimiento en las entrevistas? [cerrado]

En las entrevistas técnicas que entrevistan a programadores experimentados, los entrevistadores hacen muchas preguntas basadas en el conocimiento. [p.ej. Me gusta cómo configurar esto y aquello en el xml]. Estas preguntas tienen exactamente una respuesta y es muy probable que un buen programador no sepa la respuesta (y, por lo tanto, sea rechazado). ¿Hay una buena manera de responder a estas preguntas? [Como decirle cortésmente al entrevistador que la respuesta está a solo una búsqueda en Google].

Creo que debería estar bien decirle al entrevistador que honestamente no sabes la respuesta, y luego proceder a decirle cómo lo averiguarías (como preguntar a los compañeros de trabajo, consultar el manual, buscar en la web, etc.) . Esto debería mostrarle al entrevistador que usted es ingenioso y adaptable a nuevas situaciones y está dispuesto a aprender, y también es honesto sobre admitir cuando no sabe en lugar de tratar de farolear y fallar. No he tenido esta experiencia personalmente, así que no estoy 100% seguro de cómo funcionaría, pero aceptaría ese tipo de respuesta si fuera el entrevistador. ¡Buena suerte!

Mi tipo de pregunta favorita para la entrevista ... Mi respuesta típica si no conozco la respuesta de la cabeza es decir lo mismo, pero luego proceder a describir cómo resolvería el problema.

Por ejemplo, "¿Cuál es la llamada API a Shazbut the Fuzzer?"

Respuesta , iría a los documentos de la API "Fuzzer" en línea y lo averiguaría. Para ser justos, no he usado "Fuzzer" pero he usado "Fubar" que hace lo mismo. Usamos Fubar en nuestro último proyecto debido a X, Y y Z.

Este tipo de enfoque demuestra una serie de cosas:

1. Tienes más que una comprensión casual del problema
2. Sabes cómo encontrar respuestas (Howard Hughes no sabía todas las respuestas sobre la aviación, pero tenía un equipo de personas que sí)
3. Entiende que hay alternativas y razones para elegir una sobre la otra.

Si yo fuera el entrevistador, me gustaría tener a alguien con el conocimiento más completo que alguien que pudiera decir la respuesta.

Si es una pregunta que no suena correcta, también lo mencionaría. A veces, obtienes personas que quieren engañarte, tal vez para ver si estás prestando atención o si vas a decir una respuesta obviamente incorrecta como si fueras la autoridad en ello. Usando la misma pregunta hipotética, podría tener una respuesta como esta: "Esta es la primera vez que oigo hablar de eso. Si no le importa, ¿dónde puedo encontrar más información al respecto?"

Esto le dice al entrevistador que no va a fingir que sabe algo que no sabe, pero que está dispuesto a aprender. Depende de usted tomarse el tiempo para buscar la API de Fuzzer por su cuenta.

Creo que es importante en una entrevista poder demostrar cómo manejas ser confrontado con los límites de tu conocimiento. Su empleador querrá poder volcar un documento de 200 páginas en una tecnología que no conoce y esperar que se convierta en el experto residente en ella.

Cuando me entrevisté para mi puesto actual, no había escrito ningún C ++ en los años transcurridos desde la universidad, y lo admití. Cuando alguien escribió class A : public Bcomo parte de una pregunta de la pizarra, no podía recordar cuál era la clase base y cuál se derivaba, pero después de preguntarle al entrevistador sobre la sintaxis, pude responder con éxito la pregunta basada en mi conocimiento de los conceptos subyacentes. y le ofrecieron el trabajo. Por otro lado, alguien que afirma haber estado programando en C ++ todos los días durante los últimos 5 años debería saber esa sintaxis en la parte superior de su cabeza.

Sin embargo, incluso alguien que usa un idioma en particular todo el tiempo, puede estar oxidado en ciertas áreas que no puede esperar, pero debería tener una buena razón para ello. Por ejemplo, hago programación incrustada, y no he escrito código para abrir o leer un archivo en mucho tiempo, u obtener información de un usuario, consultar una base de datos o dibujar una GUI. Eso no significa que no pueda volver a adquirir esas habilidades rápidamente, pero debería estar preparado para demostrar la capacidad de hacerlo, y no solo esperar que confíen en mi palabra.

Como otro ejemplo, en un trabajo anterior, toda nuestra memoria tenía que ser asignada estáticamente, para que sea fácil probar los requisitos máximos de RAM para una ultra confiabilidad. En la rara excepción no era factible, había que conseguir que un compañero lo firmara, y la memoria nunca podría liberarse. Fui muy bueno para evitar la asignación dinámica, pero eso no es lo mismo que ser bueno para hacerlo.

Si me hicieran una pregunta sobre esas áreas, admitiría que estaba oxidada y daría la razón, luego procedería a responder lo mejor que pudiera recordar, haciendo preguntas aclaratorias según sea necesario.

Soy ambivalente sobre ellos. A una parte de mí no le gusta lo triviales que son (" cuál es el tercer parámetro de la función Imprimir "), pero también reconozco que si alguien trabaja con una tecnología, con el tiempo la has visto tantas veces que lo sabes de memoria . Estoy bastante dispuesto a decir "No sé, lo buscaría en Google antes de molestar a mis compañeros de trabajo". Por otro lado, si responde todas las preguntas con la misma respuesta, da la impresión de que no conoce la tecnología y va a buscar en Google todo, incluido el código que supuestamente escribió.

Yo trabajo con .NET. Las primeras versiones del marco tenían más de 40,000 objetos diferentes. Nadie puede conocerlos a todos.

He tenido una o dos entrevistas como esta y puedo entender que puede hacerte sentir incómodo. Por lo general, cuando un empleador está tocando alguna tecnología que tengo en mi CV / Currículum Vitae que no he usado durante un buen año o dos.

Respondo dándoles la comprensión de la tecnología que preguntan y cómo se aplica, cuándo se aplica y cuándo no. En el aspecto técnico, haré todo lo posible para responder, incluso la mitad de la respuesta es útil para ellos, y les aseguro que sí, si estuviera en mi PC, Google ayudaría y que la respuesta técnica no es más que un minuto o dos para retrasar en continuar con el trabajo.

En general, creo que un entrevistador puede hacer suficientes preguntas para saber si tiene el calibre para el trabajo y cuánto riesgo tiene para ellos.

Sin embargo, si respondiste incorrectamente todas las preguntas técnicas, o si recibiste una pregunta muy obvia como, ¿cómo declaras que una variable en el lenguaje X es incorrecta, eso sería muy preocupante para ellos y sentirán que no tienen el tiempo para invertir en usted poniéndose al día o capacitándose en los fundamentos.

Me sucedió esto durante una entrevista telefónica en la que me presentaron una pregunta relacionada con una utilidad BASH que no había usado antes. Le expliqué que si bien no lo había usado antes, estaba seguro de que podría después de revisar Google o su página de manual.

Al ser una entrevista telefónica, el entrevistador me puso rápidamente en el lugar al preguntarme si estaba frente a una computadora y me pidió que hiciera eso. Unos momentos después pude dar una explicación clara de cómo podría usarse para resolver el problema presentado.

Poco tiempo después, me ofrecieron el trabajo.