¿Cómo puedo mejorar en las preguntas de la entrevista de pizarra? [cerrado]

Me he sentado en entrevistas y noté una gran disparidad entre individuos de competencia similar para responder preguntas en una pizarra durante una entrevista.

En general, poder explicar claramente su pensamiento, escribir un código legible con el borrador seco, evitando largos momentos de silencio tendía a dar lugar a revisiones más favorables del candidato, aunque al final las respuestas fueron casi igualmente correctas.

¿Cómo se puede mejorar en las preguntas de la entrevista de pizarra? ¿Hay formas de estar mejor preparado?

Debe comprar una pizarra pequeña y practicar, practicar, practicar. Haga que sus amigos le hagan preguntas de un libro como Programación de entrevistas expuestas . Luego resuelva el problema y explíqueles sus procesos de pensamiento exactamente como lo haría en el trato real. Tu objetivo es no sonar frenético. Desea articular pensamientos claros. Incluso si no puede resolver el problema, muéstreles que su proceso de pensamiento es inteligente y está en el camino correcto.

Escribir respuestas en una pizarra no es intuitivo. Se necesita práctica. Solía ​​ser maestra en uno de esos programas de capacitación SAT, y pasamos horas entrenando escribiendo en la pizarra y explicando nuestros procesos de pensamiento. Al comienzo del programa, la mayoría de las personas tropezaron con sus palabras y escribieron con una letra horrible. Al final, parecíamos veteranos experimentados. No querrás parecerte a nosotros al principio del programa.

Moraleja de la historia: no vaya a su entrevista sin preparación. Resolver problemas en la pizarra es algo que debe practicar.

Hay tres preguntas que deben responderse cuando estás en una entrevista de pizarra:

1. ¿Puedes resolver el problema?
2. ¿Se puede comunicar claramente sobre el problema y la solución?
3. ¿Puede recibir comentarios de otros?

Entonces, la solución no es el punto, es cómo llegaste a la solución , y eso es lo que los entrevistadores te evaluarán.

¿Puedes mejorar en eso? Sí tu puedes:

La próxima vez que tenga que explicar algo con sus compañeros (otros estudiantes si está estudiando u otros compañeros de trabajo si está trabajando), haga lo siguiente:

1. Arrástrelos a la pizarra
2. Recoge la pluma y el borrador
3. Comience a explicar el problema.
4. ???
5. Lucro

Ah, y no te avergüences. Simplemente asuma que sus bocetos y su pseudocódigo apestarán de todos modos e improvisarán en su lugar. El objetivo es llegar a la respuesta junto con su compañero y estar siempre abierto a los comentarios de su compañero. Puntos de bonificación si puede resolver los problemas. Cuanto más lo haces, mejor lo haces. La práctica hace la perfección.

Aparte de escribir código; aprende a dibujar diagramas UML y a hablar sobre ellos. Se trata de cuadros, círculos y flechas, y los tipos que suele dibujar son diagramas de clase, diagramas de secuencia y (muy raramente) diagramas de casos de uso. Y en todos los demás casos, solo necesita dibujar cuadros, círculos y flechas.

Las pizarras no son solo para entrevistas

Esto puede parecer una noción radical, pero cuando le hago una pregunta a un candidato en la pizarra, estoy comparando mentalmente su respuesta con las últimas veces que un colega usó una pizarra para explicarme algo o pedirme ayuda. No es solo una prueba que se administrará en el momento de la entrevista, es una habilidad vital de comunicación diaria.

Entonces, ¿cómo me ayuda eso a prepararme para las preguntas de la pizarra cuando estoy siendo entrevistado? Lo trato como resolver un problema junto con un colega, en lugar de un examen universitario. Eso significa que presento mis ideas, y cuando necesito más información, pregunto. Si algo no parece correcto, lo hablo con el entrevistador hasta que esté satisfecho.

Si quieren que revierta una lista vinculada y no recuerda qué es una lista vinculada, pregunte. Si el resultado final es mejor, le daré mejores calificaciones que el tipo que sabe lo que una lista vinculada está fuera de su cabeza, pero que escribe un código pésimo para manipular uno. No es como si comenzaras el trabajo de alguna manera mágicamente conociendo todo nuestro código y otra información patentada, sin importar cuán experimentado seas un programador.

En mi opinión, las entrevistas no son algo para lo que puedas concentrarte, y si pudieras, distorsionaría la percepción de lo bueno que eres para el trabajo, y viceversa. Es bastante fácil saber cuándo alguien está recitando una respuesta que memorizó. Esa es una razón por la que intento a propósito empujar a los candidatos fuera de su zona de conocimiento. Quiero ver cómo reaccionan a las preguntas para las que no se han preparado.

Puede pensar que estoy loco, pero siento con tanta fuerza los beneficios de evaluar el proceso de pensamiento de alguien frente a su capacidad de memorización, que les dije a los entrevistadores cuando esencialmente regurgito una respuesta que he dado exactamente a la misma pregunta. en 3 entrevistas recientes, y pregunte si les gustaría elegir algo más desafiante. Siempre me piden que los "humorice" de todos modos, en caso de que esté faroleando, supongo, pero al menos están obteniendo una evaluación honesta de mis habilidades.

Me he sentado en entrevistas y noté una gran disparidad entre individuos de competencia similar para responder preguntas en una pizarra durante una entrevista. En general, poder explicar claramente su pensamiento, escribir un código legible con el borrador seco, evitando largos momentos de silencio tendía a dar lugar a revisiones más favorables del candidato, aunque al final las respuestas fueron igualmente correctas.

No recuerdo la última vez que trabajé individualmente cuando desarrollé software. Siempre tuve que coordinar mis actividades con otros, discutir mis decisiones de diseño e implementación y trabajar con otros para construir software. Demostrar habilidades de comunicación en una entrevista es una gran ventaja. Las entrevistas pueden ponerlo nervioso, pero también los plazos inminentes y la presión del trabajo.

También reiteraría mi comentario. Dada la naturaleza orientada al equipo de la ingeniería de software, debe considerar más que la competencia técnica. La capacidad de hablar y escribir, especialmente técnicamente, es importante para la mayoría de las posiciones. Evaluaría la competencia de alguien en todos los factores relevantes para el trabajo, no solo su capacidad para construir software.

¿Cuáles son algunas maneras en que uno puede mejorar en las preguntas de la entrevista de pizarra?

¿Hay formas de estar mejor preparado?

Puedo pensar en dos razones por las cuales alguien puede tener respuestas pobres a las preguntas de la pizarra: no tienen una buena comprensión de la información técnica o son un pobre orador / presentador. Por supuesto, siempre podría ser ambos.

La forma de mejorar depende del problema. La mejora técnica se produce leyendo, haciendo y haciendo preguntas (generalmente en ese orden). Las malas habilidades de presentación se obtienen a través de la práctica, aunque algunas personas son naturalmente buenas oradores, mientras que otras no. Creo que cualquiera puede desarrollar las habilidades de comunicación, pero la personalidad desempeñará un papel importante en lo bueno que alguien es en realidad.

¿Consejos sobre cómo proceder durante la entrevista?

Depende.

Más detalles siempre es bueno, incluso hasta el punto de "volcado cerebral" total para el entrevistador. Si no estaba dando suficiente información, los entrevistadores me pidieron que explicara algo con más detalle y, por lo general, me hicieron preguntas explícitas y concretas sobre mi diseño o código.

Pasar un par de minutos pensando en el problema de antemano, sin decir ni hacer nada, siempre es una buena idea. Puede usar este tiempo para hacer preguntas para aclarar lo que está buscando el entrevistador. Esto no solo le dará la oportunidad de darle al entrevistador exactamente lo que está buscando, sino que también le mostrará que puede pensar a través de múltiples posibilidades.

Pararse frente a otros y hacer una presentación es una habilidad que se puede aprender. Si eres débil en esto, te recomiendo unirte a tu capítulo local de Toastmasters . Practicará parte del "aquí hay un tema que nunca ha visto antes, ahora párese frente a extraños y explíquele" el estrés que encuentra durante las entrevistas, y especialmente la parte de la pizarra (si la hay).

Mientras que otros han cubierto los aspectos físicos (¡práctica!), Tocaré los aspectos mentales. Independientemente de la cantidad de práctica que haga, las entrevistas son un tipo diferente de entorno. No estarás solo o con tus amigos, estarás con alguien que nunca has conocido y que está tratando de juzgar tu habilidad.

Al practicar, siempre tenga en cuenta ese entorno. No tiene que halagarlos ni hacerles caso: su objetivo es mostrar su competencia y actitud. Habla con naturalidad y explica lo que está pasando en tu cabeza. Quieren ver cómo piensas, así que piensa en voz alta, habla, discute y haz que se involucren en tu mente.

Otro factor importante es el rebote. Los problemas de práctica siempre tienen soluciones: cuando se atasca, puede verificar el siguiente paso, escribirlo, comprenderlo y aprender. Pero su entrevistador no es un manual de soluciones. Te ayudarán, pero nadie dice "el siguiente paso es hacer x", y dicen "¿has pensado en y (que está relacionado con x)?" Practique sin referirse siempre al manual. Haga que un amigo le dé algunas sugerencias vagas pero relacionadas, e intente construir desde allí. Explica cómo su sugerencia te ayudó a resolver el problema. Muéstreles siempre cómo está pensando.

¡Espero eso ayude!

Hacer preguntas y evitar suposiciones es otro punto para algunas preguntas de pizarra. Lo que puede parecer, "Oye, he hecho algo así antes y aquí está la solución ..." es realmente una cuestión de ver si harías esas suposiciones y dispararías. No es que pretenda ser una pregunta capciosa o avergonzarlo, pero generalmente hay muchas pequeñas cosas que si golpea a alguna de ellas, se mostrará con bastante facilidad. Algunas áreas de ejemplo:

• ¿Qué tan específicos son los requisitos? ¿Estás seguro de cómo sería el resultado?
• ¿Qué métrica de complejidad es más importante, tiempo o espacio, y algunas operaciones merecen más consideraciones que otras?
• ¿Qué tan bien puedes explicar por qué tu solución es buena?
• ¿Podría dar un ejemplo o dos que muestren cómo funcionaría su solución teórica? Los casos de prueba aquí pueden ser interesantes para descubrir como si hubiera una entrada del usuario, dónde se valida y cómo se comunican los mensajes de error, etc.

Hay otras áreas, por supuesto, pero esas son las principales que consideraría al analizar cómo lo hice en una entrevista simulada.