¿Se espera que escriba un código perfecto en su primer intento en entrevistas tecnológicas?

En Google, esperamos que todos escriban un código perfecto la primera vez sin dudarlo. Es por eso que, dentro de la empresa, nuestros teclados no tienen tecla de retroceso.

Más en serio, a la mayoría de los entrevistadores no les importará el tipo de resbalones que atraparía un IDE. Faltan casos límite … bueno, ese es el tipo de cosas que es bueno identificar antes que el entrevistador.

Parece que acabas de salir de una entrevista en la que te perdiste algunos casos extremos. Es difícil decir cuán condenatoria fue la omisión sin saber lo que eran, pero digámoslo de esta manera: si el entrevistador ya hubiera tomado una decisión sobre usted, no se habrían molestado en llamar su atención.

Como alguien que entrevistó a muchos ingenieros en Google, puedo contarles mi enfoque. Otros pueden hacerlo de manera diferente, pero Google capacita a todos para entrevistar adecuadamente.

Cuando le pido que escriba código en la pizarra, lo que más me interesa es su proceso de pensamiento. Por lo tanto, prefiero enormemente a las personas que intentan 1) comprender bien el problema y 2) desarrollar un algoritmo utilizando dibujos y ejemplos, prestando especial atención a los casos extremos. Solo cuando hablamos de todo eso, y ambos estamos de acuerdo con el algoritmo, un candidato debe comenzar a escribir el código. En ese momento, siempre pregunto cuál es su idioma favorito y les pido que lo usen. Si cometen un error de sintaxis, generalmente pregunto al respecto, pero realmente no me importa el error en sí. Lo que más me importa es cómo el candidato maneja la corrección. ¿Están a la defensiva? ¿Inseguro? ¿O seguro y colaborativo? Lo más importante, por supuesto, es si el código refleja el algoritmo que ellos / nosotros desarrollamos.

Si comienza a escribir su código, en lugar de desarrollar el algoritmo utilizando ejemplos, es probable que cometa errores. Estás omitiendo un paso importante: el desarrollo del algoritmo. Escribir código mientras piensa en el algoritmo mentalmente es innecesariamente difícil en un proceso de entrevista de alta presión.

Lo peor es cuando un candidato, al escuchar la pregunta, recurre a la pizarra y presenta un algoritmo perfecto, escribiéndolo secuencialmente. Sé que la persona había escuchado la pregunta antes, y no aprendí nada sobre sus habilidades. Mis notas en ese caso son literalmente “Pregunta inválida, sabía la respuesta”.

Si siento que el candidato no confía en su respuesta, incluso puedo arrojar un “error” para ver si tiene la confianza suficiente para estar en desacuerdo conmigo. Esto también podría suceder por un error honesto por parte del entrevistador, que no debería desviarte del camino, y deberías hacer frente a tu respuesta si sabes que tienes razón (y probarlo).

Para responder a su pregunta más directamente, sí faltan casos extremos es un problema. Significa que su proceso fue incorrecto, probablemente no intentó desarrollar el algoritmo utilizando ejemplos, y no tuvo especial cuidado en identificar y manejar casos extremos. Si ha sido ingeniero de software durante un tiempo, sabe cuántos errores son el resultado de casos límite omitidos y cuán importantes son.

En pocas palabras, debe impresionarme, no esperar salirse con la suya.

Su entrevistador tiene un interés personal en verlo triunfar: la contratación es un negocio costoso y que lleva mucho tiempo, después de todo. Le pedirán que corrija los errores, le pedirán que mire el problema desde otra dirección si está atrapado y, en general, lo guiarán si se desvía del problema que intentan resolver.

Así que hable sobre su solución como (y preferiblemente, antes) que escribe el código. No quiere darse cuenta de 15 minutos en que está abordando el problema completamente mal, o que ha cometido un error fatal en la estructura de su código.

Un candidato que comete errores y los corrige cuando se le solicita es mucho más probable que tenga éxito que uno que no explica sus pensamientos y bombardea la entrevista por completo.

Pero igualmente importante, escucha a tu entrevistador . Si te están diciendo algo, es por una razón. No ignore sus comentarios si cree que conoce la respuesta a un problema; es posible que esté resolviendo el problema incorrecto por completo.

Depende de en qué parte de la pirámide estás entrevistando?

Como la pregunta no se refiere a una empresa específica, mantendré mi respuesta sobre entrevistas tecnológicas en general. La figura de la pirámide anterior es un gráfico aproximado sobre el nivel de desafío en la programación de entrevistas en diferentes compañías tecnológicas. Como puede ver, cuanto más buscada es la empresa, como Facebook, Google, etc., más dura es la entrevista de programación.

La respuesta a su pregunta es sí y no: si está entrevistando en una empresa con una barra de entrevista baja, sí, no es gran cosa perder algunos casos extremos. He estado allí, hecho eso!

A medida que avanza en la pirámide, en las empresas con una barra de entrevista media, al menos se espera que encuentre sus propios errores siguiendo las sugerencias del entrevistador. ¡Escribir código libre de errores es un desafío silencioso y es demasiado pedir aquí!

Por último, más arriba en la pirámide, cuando entrevista a compañías como Google, Facebook, etc., sí, se espera que escriba un código libre de errores.

Entonces, ¿cómo escribir código libre de errores?

La capacidad de escribir código libre de errores en la pizarra, con alguien mirando por encima del hombro, bajo rígidas limitaciones de tiempo y presión mental, resulta que no es demasiado fácil.

Esta es una habilidad que solo se puede adquirir con la práctica. Esto se hace mejor practicando regularmente las preguntas de la entrevista de programación en la pizarra.
y también codificarlo y probarlo para varios casos de prueba.
Por ejemplo, escriba código para verificar si la matriz es un conjunto de enteros consecutivos.

  for (int i = 0; i 
  El error en este código puede no ser obvio cuando solo lo escribe en la pizarra, pero cuando intenta ejecutarlo, no solo detectará el error para este programa, sino que también estará atento a los casos extremos de la matriz. . 
 El rendimiento en la programación de entrevistas no se relaciona con el desempeño que desempeñas como ingeniero de software profesional o en la escuela. De hecho, he visto a muchos ingenieros de software con mucha experiencia luchar para escribir un código decente para preguntas básicas de entrevistas como 
  Divide esta cadena de números en una secuencia de números de 1 dígito y 2 dígitos sin cambiar su orden relativo.
 Entrada: 1234 
 Resultado: {1,2,34} {1,23, 4} {1,2,3,4} {12,34} {12,3,4}

  Por último, para más información sobre la preparación de mi entrevista, las publicaciones relacionadas se refieren a 
  Hackear la entrevista de programación - 1 por Ash Murthy en Rants Random 
  Respuesta del usuario de Quora a ¿Cómo puedo conseguir un trabajo en Facebook o Google en 6 meses?  Necesito un plan de trabajo conciso para construir un conjunto de habilidades lo suficientemente bueno.  ¿Debo unirme a alguna otra startup o construir mis propios proyectos / start-ups?  ¿Debería centrarme en practicar estructuras de datos y algoritmos? 
    

La práctica ayuda, pero solo si estás practicando las cosas correctas. Si no puede pintar, la clave para mejorar no es seguir practicando garabatos, sino descubrir cómo mejorar sus habilidades y practicar esas mejoras.

Esto puede parecer obvio, pero la razón por la cual su código no es perfecto es porque … * drumroll * … contiene fallas. Para piezas de código más grandes, los defectos más grandes generalmente se manifiestan en un diseño deficiente. Para los tipos de problemas que tiene que resolver durante una entrevista, los defectos más comunes son los casos límite y los errores ocasionales.

La mejor manera de evitar el caso límite y los problemas ocasionales es preguntarse “¿qué puede salir mal?” y “¿cómo podría romper este código?”. Siga haciéndose estas preguntas hasta que esté satisfecho de estar manejando cada problema potencial. Además, siempre es bueno recorrer algunos ejemplos de entradas para asegurarse de que su código esté haciendo lo que desea.

La famosa estadística es que solo el 10% de los programadores experimentados pueden implementar correctamente la búsqueda binaria cuando se les describe el algoritmo. Digamos que te enfrentas a este problema. ¿Qué cosas pueden salir mal?

– la matriz de entrada está vacía
– el elemento a buscar no está en la matriz
– la matriz de entrada no está ordenada (técnicamente puede suponer que está ordenada, pero nunca está de más preguntar)
– tiene un error único cuando cambia el subrango de la matriz que está buscando
– etc.

Si abordas estos problemas y analizas un par de ejemplos, hay muchas posibilidades de que estés en el 10% que resuelve el problema sin problemas.

Me entrevisté para Google y Amazon, no los busqué, se me acercaron en base a mi perfil de LinkedIn. Amazon me contactó en 2010 poco después de obtener mi maestría en informática. Cuando me entrevistaron entonces, fue comprar un teléfono al principio, porque vivo en Florida y me hicieron muchas preguntas teóricas sobre estructuras de datos y preguntas sobre O (n). Hubo algo de codificación durante la entrevista, pero no demasiada, cualquier codificación significativa que tuve que hacer lo hice sin conexión usando el IDE de mi elección y tuve tiempo para planificar y pensar. Debo haberlo hecho bien, ya que me llevaron a Seattle para una entrevista en persona, mi primera en un lugar de software de primer nivel, y las preguntas de la entrevista parecieron ir bien y fueron de naturaleza colaborativa. La mayoría de las preguntas nuevamente fueron más algorítmicas que la codificación directa. No conseguí el trabajo, me dijeron que todos los entrevistadores me querían, y la persona que iba a ser mi superior inmediata me entrevistó y parecía muy feliz, pero el gerente de contratación decidió no contratarme. Desde entonces, el advenimiento de las pruebas de detección se produjo cuando le hicieron una pregunta, nuevamente esto se hizo por teléfono, donde le piden que escriba una solución en la pantalla mientras la gente lo está mirando. Y siempre parecen decir que tiene que ser un código de calidad de producción. Algunas pruebas que he realizado requieren que sea compilable y que coincida con ciertos estándares de rendimiento que comprueban ejecutando el código. Lamentablemente, esas pruebas no proporcionan una experiencia IDE.
Amazon se me ha acercado al menos tres veces desde 2010 y se han dedicado a la codificación en pantalla y han colaborado mucho menos en las entrevistas telefónicas. Nunca he pasado la entrevista de proyección desde entonces con Amazon. Obviamente preferiría el primer método, la entrevista que utilizaron, especialmente con sus entrevistas telefónicas.
Cuando volví a entrevistarme con Google fue por teléfono, me dieron una lista de cosas que debía saber y un libro de algoritmos para leer o leer y conocer sobre árboles Black Red y temas avanzados como ese. También dijeron que habría algunas preguntas de codificación. Me sorprendió mucho cuando surgió la entrevista telefónica real. Lo único que pidieron fue codificar algún problema y, aunque tuve la idea correcta y casi correcta, tropecé con una parte. No me volvieron a llamar para una segunda entrevista. Si hubiera sabido que la parte de codificación era tan importante, podría haber practicado más codificación sin un IDE y depurador. Era la primera vez que intentaba eso.

Antes de escribir cualquier código, es importante asegurarse de tener una comprensión sólida de la pregunta y saber cómo se ve su solución.

Como entrevistador, me encanta cuando el candidato dibuja una imagen o un ejemplo, y luego me explica exactamente cómo funciona el algoritmo, con flechas y gestos o lo que sea necesario para comunicar la idea. Una vez que haya descubierto cómo funciona, el código debería fluir naturalmente.

Demasiados candidatos comenzarán con “umm, creo que necesito un bucle for”, y saltarán directamente a la codificación sin tener una visión clara de su juego final. Tienen que borrar y comenzar varias veces porque sus pensamientos están muy desorganizados.

Entonces comience organizando sus pensamientos, comuníquelos al entrevistador y solo entonces comience a escribir el código.

He concluido que tales pruebas tienen valor cero cuando el candidato tiene un código ya escrito que puede demostrar su talento en ingeniería (nota, no “programación”).

Ahora estoy comprometiendo un nuevo requisito para la empresa, en lugar de cualquier tipo de prueba de codificación en vivo o prueba de codificación escrita … Proporcionaré el código que escribí (ya sea a través de archivos o en github) y un enlace o enlaces a él en ejecución. Si eso es inaceptable para la compañía, entonces no son un lugar lo suficientemente bueno para que yo trabaje.

No evalúa a un carpintero pidiéndole que use un taladro, le pregunta por su trabajo terminado … la ingeniería es exactamente la misma.

Ejercicios de codificación en vivo: cómo NO contratar ingenieros potencialmente brillantes.

Debes intentar escribir código ejecutable, están tratando de probar qué tan bien puedes codificar. No lo ejecutarán en un IDE, pero lo buscarán para que escriba un código libre de errores. Si tiene errores por uno, probablemente se darán cuenta y le preguntarán qué problemas potenciales ve en su código. La única excepción es que puede inventar funciones para partes poco interesantes del problema.

Por ejemplo, si parte de su solución implica ordenar algo, puede suponer que tiene una función de sort(...) que hace lo que sea necesario.

Todo depende del entrevistador. No hay una respuesta correcta aquí

Algunas personas buscan atención al detalle. Quieren que consideres todos los casos de uso. Algunas personas buscan averiguar su proceso de pensamiento. Necesita hablar sobre el problema con estas personas. Algunas están tratando de “sondearlo”. Puede decir mucho sobre un programador por la forma en que escribe el código. Las personas que intentan leerlo generalmente comenzarán sin expectativas, y construirán su opinión sobre usted mientras escribe el código.

Me levanto con un pequeño truco: – Digo “Normalmente sigo los procesos TDD, así que primero escribo las pruebas antes de saltar al código. Esto asegura que no me pierda nada. En interés del tiempo, voy a salte al código, pero perdóneme si no cubro todos los casos “Si están prestando atención a los detalles o observando sus procesos de pensamiento, dicen” hmm, eso parece un buen enfoque “… y si olvido algo me da una “salida” conveniente “Oye, mira si hubiera usado mis procesos TDD normales, lo habría captado jaja” Si la persona te está probando, él / ella podría pedirte que escribas las pruebas también, y te da una oportunidad para brillar

Advertencia: HAGA esto solo si realmente está haciendo TDD. No puedes fingir hacer TDD en una entrevista

Lordy, espero que no. Como alguien que ha contratado bastante, incluso para programadores, no entiendo lo que se obtendría de una entrevista como esta. Por ejemplo, los codificadores que toman mucho tiempo para considerar soluciones, o que prueban varias cosas diferentes antes de decidirse por una solución final, entrevistarían mal; también podrían hacerlo aquellos que realmente están comprometidos con el uso de TDD para captar los casos extremos. Hay otras personas que deberían poder razonar a través de soluciones en pseudocódigo, pero trabajan en tantos idiomas que no pueden operar sin una referencia API útil, y el pseudocódigo no captará las peculiaridades del lenguaje. Todos estos programadores podrían ser igualmente brillantes, pero si los obligas a todos a seguir el mismo molde, terminarás con un equipo que es realmente muy bueno en una cosa y una mierda total en otra.

Pedimos a las personas sus nombres de usuario de Github y miramos sus repositorios. Creemos que es un mejor reflejo del trabajo que son capaces de producir. Hasta ahora nos ha funcionado muy bien: tenemos un equipo muy equilibrado lleno de miembros que aportan sus propias fortalezas a sus trabajos, y no tenemos egos inflados con los que lidiar. ¿Puedes hacer el trabajo a tu manera? ¿Es fácil llevarse bien con usted? Bueno. Estas contratado.

No, absolutamente no lo eres.

Es difícil escribir correctamente, y mucho menos código perfecto en el primer intento.

A través de miles de entrevistas técnicas que hemos realizado en Refdash, hemos visto que incluso los mejores ingenieros constantemente cometen pequeños errores, errores tipográficos, etc.

Aún así, tenga en cuenta que hay diferentes tipos de errores que puede cometer, algunos aceptables, otros, bueno, no tanto.

Hay tres niveles de errores:

1. Errores tipográficos : se perdió un punto y coma y no se compiló. No es gran cosa. Si un entrevistador le causa problemas por este tipo de error, piénselo dos veces si quiere trabajar para esa empresa.
2. Casos extremos perdidos : sucede a menudo durante las entrevistas. Algunos entrevistadores más estrictos pueden interpretar esto como su falta de atención al detalle. Por lo general, tendrás la oportunidad de arreglar esto.
3. Faltan partes de la lógica crítica : este es un problema. En algunos casos, el entrevistador le informará esto y le dará una segunda oportunidad. A veces, eso es todo, mejor suerte la próxima vez.

Cuando se trata de errores tipográficos , asegúrese de prestar atención durante las entrevistas. Como dije, los entrevistadores generalmente entenderán esto, simplemente no seas demasiado descuidado con tu código.

Para obtener esos casos límite , le sugiero que participe en algunos concursos de codificación en línea en sitios como codeforces.com. A esos tipos les encanta darte casos inesperados y difíciles que realmente te obligan a pensar en tu solución.

Si a menudo le faltan partes de la lógica crítica en las preguntas de la entrevista, asegúrese de repasar su conocimiento de los algoritmos. Elija un libro como CLRS y asegúrese de aprender todos los algoritmos clásicos, sus casos de uso y tiempos de ejecución. Luego haz muchos problemas de práctica, enfocándote en tus áreas débiles. Echa un vistazo a Refdash, donde puedes hacer entrevistas de práctica libre con ingenieros de las principales empresas.

Finalmente, haz muchas pruebas. Mientras practicas, las pruebas te ayudarán a ver si cometiste alguno de los errores antes mencionados. Y si prueba su código en una entrevista, demostrará que usted es un ingeniero que se preocupa por la exactitud de su código.

Solo un entrevistador novato te criticaría por la sintaxis, por lo que creo que los errores de sintaxis podrían no ser tu problema en sí mismo. Puede ser que el entrevistador piense que usted es demasiado dependiente del compilador y / o depurador y no entienda el lenguaje en un nivel fundamental.

Andreas Blixt es acertado con sus sugerencias (especialmente la última) y no agregaré nada, excepto que es posible que desee probar algunas competiciones en Top Coder ( http://www.topcoder.com/ ).

Ah, y cuando se trata de entrevistas tecnológicas, practica con un amigo, EN UNA PIZARRA. No comience a escribir código de inmediato, comience con el algoritmo, primero y escríbalo en inglés simple y asegúrese de que el entrevistador lo siga.

Desarrollando más sobre el primer punto de Andreas, considere hacer el código Katas.
Ejemplo súper genial en Vimeo: http://vimeo.com/8569257

Hay aproximadamente dos clases de problemas de programación: problemas de programación y problemas de diseño.

En general, sabrá una pregunta de diseño cuando sería más de 30 líneas para escribir, si mencionan la palabra “clase” o “jerarquía”, o si su tarea requiere que almacene el estado más allá de un retorno de su función llamada. Ejemplos de este tipo de preguntas son: cualquier cosa que involucre una GUI, implementar algún tipo de bloqueo sofisticado (tal vez un bloqueo de lector / escritor) o algo que responda a múltiples solicitudes.

En estos casos, la respuesta de Larry Maccherone es estelar.

Sin embargo, si se le pide que realice una tarea simple con entradas conocidas que podría describir en una oración (larga) o dos, no se lo evalúa en el diseño, se lo evalúa en código sin procesar. Ahora, algunos pueden estar en desacuerdo con este tipo de evaluación, pero si están buscando lo correcto, creo que estas preguntas son esenciales y muy reveladoras, y aunque no rechazaría a un candidato solo por fallar una pregunta como esta, lo haría tener dificultades para contratar uno sin al menos preguntar. La tarea nunca será lo suficientemente complicada como para necesitar pensar en el algoritmo. O será algo lo suficientemente simple que seguramente ya lo haya visto antes (lista enlazada), o será algo que se le ocurrió correctamente en forma de una pregunta de algoritmo.

Lo principal que están probando es obvio: ¿puedes producir el código correcto? Naturalmente, no pasará su tiempo allí escribiendo en una pizarra, ocultándolo y compilándolo, tendrá editores, resaltado de sintaxis, documentación API, compiladores, depuradores y toda la pandilla allí para ayudarlo. El entrevistador entiende esto y no espera que haga todo eso usted mismo. Esto me lleva a mi primera sugerencia:

Debe sentirse libre de tratar al entrevistador como su entorno de desarrollo . Hágales preguntas que normalmente usaría esas herramientas para responder. ¿No sabe qué argumentos toma una función? Pedir. ¿Olvidó la sintaxis para declarar una matriz de punteros? Pedir. Si el entrevistador sabe lo que está haciendo, al menos le dirá “sí” o “no” como lo haría un simple compilador, pero en la mayoría de los casos simplemente le dirá la respuesta (después de todo, google lo haría) , o decirle que asuma algo diferente por el momento. Una vez tuve un entrevistador que me dijo que asumiera que gettimeofday regresaba mucho tiempo, porque no recordaba ni le importaba lo que realmente hacía, y no quería pensar en eso más de lo que pensaba que haría.

Sin embargo, si usted es el único candidato de 10 ese día que conoce el orden correcto de los parámetros para escribir, y recuerda que no devuelve el número de bytes escritos, sino el número de elementos, se mantendrá por encima de esos otros 9 candidatos Si impresiona a su entrevistador de esta manera una vez, de repente será ese tipo que produce programas durante horas sin llegar una vez a los javadocs y distraerse jugando juegos flash durante media hora (en la fantasía de su entrevistador, eso es). Esto me lleva a mi próxima sugerencia:

Escriba lotes y lotes (y lotes y lotes) de código. La única forma de escribir el código correcto y hacer que parezca fácil es haberlo hecho ya cientos de veces. Hay innumerables libros, publicaciones de blog y tuits sobre las legendarias “10,000 horas para dominar”, y es cierto. Tal vez hay atajos (en el sentido de que tal vez P = NP), pero sabemos que si haces lo mismo con la frecuencia suficiente durante el tiempo suficiente, se vuelve natural. Así que solo practica mucho. Haga topcoder, implemente todos los problemas en el proyecto euler, vuelva a implementar un esquema en su idioma favorito, todos los viejos trucos. Elija viejos problemas de tarea y escriba el código (y pruébelo). No te detengas hasta tu entrevista. Cuando suceda, estará listo para aturdirlos con la facilidad con que hace que se vean sus trabajos.

Finalmente, llegamos a un punto sutil que buscan: ¿sabes lo que sabes? Es decir, ¿eres consciente de tus fallas? Esta es la vieja pregunta “cuál es tu mayor debilidad” en ropa nueva. No importa cuánto haya practicado, olvidará algo. Si lo ignoras y te atrapan más tarde, te has vuelto loco (piensa en “muggins” en la basura, si lo sabes). Sin embargo, si los golpeas al máximo, no pueden criticarte por eso más tarde, y parece que has hecho un trabajo perfecto. Por lo tanto:

Dígale a su entrevistador todo lo que está mal con su código. Haz esto mientras lo escribes. Si olvida algo, regrese al primer consejo anterior y pregúnteles directamente. Recuerde, no tiene que impresionarlos con cada línea que escriba, solo una o dos, siempre que el resto no lo deprima. Esos uno o dos sobresaldrán, así que cada dos veces, use a su entrevistador tanto como lo necesite. Luego (y esto es muy importante), una vez que haya terminado de escribirlo, si comienzan a señalar algo, deténgalo y diga “espera un minuto, solo quiero verificar lo que he hecho”. De esta manera, te ves profesional (mírame la revisión del código), y seguramente eliminarás algunas de las cosas negativas que tendrían que decir de otra manera.

TL; DR: Sí, se lo espera, pero incluso si pierde esos casos extremos, su proceso de pensamiento es más importante.

Me entrevistó una empresa llamada mentes aspirantes. Es una gran compañía con una extensa investigación en teorías de ML / NLP.

Ahora había una codificación escrita que borré. Entonces, el entrevistador me dio un problema algorítmico. Fue fácil pero escribí una solución incorrecta. Le entregué la sábana y me pidió que esperara y luego me llamaron.

Entrevistador: ¿Es correcta su solución?
Yo: No señor, lo resolví con DP, sin embargo, la solución correcta fue DFS.
I: un DP? Por este problema? ¿Puedes explicar cómo llegaste a esa solución?
M: explicó correctamente y señaló los errores y las deficiencias de mi algoritmo.
Yo: bastante justo. Digamos que nuevamente se le da la oportunidad de resolver ese problema. DFS que dices? Resuélvelo.
M: escribió el código. (Se perdió una condición).
I: ¿Su código es correcto ahora? No funcionará en un tipo de caso de prueba. ¿Puede volver a leer su solución y decir qué es?
M: Después de un tiempo (mierda). Sí señor. Señalé mi error y le dije la solución.
Yo: bien.

Luego pasó a preguntar otros problemas y soluciones y al final dijo “aunque hayas dado algunas soluciones incorrectas y algunas parcialmente correctas, te voy a seleccionar para la próxima ronda de entrevistas porque tienes un proceso de reflexión y te das cuenta de tus errores rápidamente y corregirlos y eso es lo que busco en un candidato “.

Fue más amable y fue mi primera entrevista, pero puedo decir que si eres talentoso y tienes un gran proceso de pensamiento y te validas y luego llegas a una conclusión, a nadie le importará si has escrito un código perfecto o no.

Para ellos ” ES LA INTENCIÓN QUE IMPORTA”

PD: – No conseguí el trabajo. Fui rechazado en la ronda final :).

Depende de la barra de contratación en una empresa en particular, pero consideremos las empresas de primer nivel.
Definitivamente, tiene que escribir el código correcto en términos de manejo de casos de esquina y, obviamente, sería mejor encontrar los errores usted mismo. Además, la sintaxis es importante, pero no necesariamente necesita recordar el nombre exacto del método, por ejemplo, presionar en lugar de agregar no debería ser un problema, solo informe al entrevistador que no recuerda el nombre exacto pero suponga que hace lo que usted quiere. creo que sí.
No está obligado a escribir el código 100% correcto al instante, lo que recomendaría es que una vez que haya terminado con un borrador, le dé una nota al entrevistador de que aún no ha terminado y necesita verificar que el código funciona como se esperaba. No tenga prisa, asegúrese de manejar bien los casos de esquina, incluso mejor cuando revisa el código que menciona que aquí evita NPE o índice de excepción o desbordamiento de rango. Proponga datos de entrada de muestra para su código y asegúrese de que el código produzca el resultado esperado.
Una vez que analice los ejemplos y verifique que todo está bien, puede decirle al entrevistador que ya terminó.
En este caso, demuestra que es muy cuidadoso y tiende a reducir la cantidad de errores en un código y también, mientras revisa el código, puede mencionar algunos detalles, como si utilizara esta estructura de datos o algoritmo debido a esto y aquello.

La sintaxis adecuada es al menos una consideración, porque muestra que realmente conoces al menos un lenguaje de programación.

Sin embargo, el pseudocódigo también es aceptable, siempre que pueda responder la pregunta.

Respuesta simple Piense en voz alta mientras escribe el código o responde para que el entrevistador conozca su proceso de pensamiento y cómo abordaría el problema que se le presenta. Eso debería ayudarte.

No hay sustituto para la práctica. Si escribe código con errores o tarda mucho tiempo en encontrar soluciones, solo necesita practicar escribir código más.

Los problemas de la División 2 en http://www.topcoder.com/tc están en el nivel de entrevista técnica.

Si realiza entre 20 y 30 salas de práctica div 2 en el área de topcoder, su nivel de codificación para las entrevistas debería mejorar drásticamente.