¿Qué errores cometes al prepararte para codificar entrevistas?

No estoy seguro si estoy respondiendo la pregunta exactamente, pero intentaré escribir sobre los errores comunes que veo que los candidatos cometen al codificar entrevistas.

Suponiendo que uno haya traducido aproximadamente el flujo lógico del algoritmo a código, los errores más comunes ocurren alrededor del manejo inadecuado de casos extremos y el uso incorrecto de primitivas de codificación . Ejemplos:

  • ausencia de cheques nulos
  • casos base ausentes o inadecuados (por recursividad)
  • paso por valor vs paso por referencia (en código C / C ++)
  • errores fuera de uno e índice fuera de límites (como en contadores de bucle o variables y con índices de matriz)
  • Acceso conflictivo incorrecto de variables estáticas / globales (el estado cambia de forma impredecible).
  • valores de retorno incorrectos o casos en los que los valores de retorno pueden diferir a valores no deseados por el candidato, porque no todas las rutas se han codificado explícitamente.
  • y más…

Fuera de estos, los errores lógicos pueden estar presentes en los algoritmos mismos.

La mejor manera de combatir esto es construir ejemplos y recorrer su código rigurosamente para verificar que genera el resultado esperado. A veces, es posible que desee construir ejemplos para ver si puede romper deliberadamente su código.

Varios candidatos obtienen el enfoque correcto, pero introducen errores y errores en la etapa de codificación. No lo toman todo el camino para hacerlo apretado. Puede estar bien hacer esto, pero los entrevistadores esperarían que usted pueda identificarlos y corregirlos.

Para niveles más experimentados, los entrevistadores también pueden esperar que escriba un código limpio, utilizando módulos / interfaces bien separados, lógicamente simples, seguros para hilos, extensibles y comprobables.

La mayoría de las personas comete un error común, que es el exceso de confianza y la lógica de asalto directo. Al igual que en las empresas, la gente hoy en día generalmente hace preguntas nuevas.

Dejame darte un ejemplo :

  1. Pregunta: Algoritmo de cambio de moneda (cuando hay una fuente infinita de monedas) Devuelve varias formas de obtener el cambio de un dinero determinado.
  • Ahora, si ha entendido la recursividad, retroceda: puede crear una solución fácilmente:
  • Solución: return countofCE( C, m - 1, n ) + countofCE( C, m, nS[m-1] );
  • Si tiene fundamentos sólidos de DP, puede convertir la solución anterior en TopDown y Bottom-Up Solution fácilmente.
  • 2. Si la solución y el problema anteriores se entienden bien, puede crear la solución de un problema similar por su cuenta

    • Encuentre posibles soluciones al problema del cambio de monedas (cuando hay una fuente infinita de monedas)
    • Encuentre la posible solución cuando no hay una fuente infinita de monedas.
    • 0–1 Problema de Knap Sack
    • Encuentra la cantidad mínima de monedas que hacen un valor dado

    Entonces, mi punto es que la gente hace los problemas tradicionales de los libros de texto mientras son la base de su conocimiento, que debe entenderse correctamente y luego codificarse sabiamente, luego solo a usted le importa crear su propia lógica que lo ayudará a resolver los problemas de la vida real de la industria .

    Segundo error: la gente no se prepara sabiamente

    • Debe preparar la empresa sabiamente, ya que las expectativas de cada empresa y equipo son diferentes, por lo que el retoque final de los preparativos antes de ir a entrevistas tecnológicas debe ser sabio para la empresa.
    • Ejemplo: Amazon prefiere los mejores programadores que pueden pensar en todos los casos límite y los chicos de DS-A
    • Mientras que Microsoft toma a los mejores chicos de DS-A (con la mejor lógica y algo), pero le da poco peso a los casos límite en cuanto al código adecuado.

    Para más dudas, conéctese conmigo en LinkedIn o para aprender este pensamiento lógico, vaya a mi sitio Gohired.in

    Un gran error que veo que hacen los candidatos es que no resuelven un problema de codificación por sí mismos por completo. Muchos candidatos ven una pregunta de codificación en un sitio web o un libro, y buscan directamente la solución dada al final del libro o la buscan en Google. De esta manera, nunca desarrollará la capacidad de resolución de problemas, que es el criterio más importante para la selección en entrevistas reales.

    Entonces, cuando vea una pregunta, intente resolverla por su cuenta. Si se atasca, puede ver 1 o 2 líneas de la solución solo para obtener una pista. Entonces debe continuar resolviendo el problema por su cuenta. No debe preocuparse por el tiempo que lleva inicialmente.

    A medida que resuelva muchos problemas, el tiempo disminuirá enormemente y su confianza aumentará significativamente.

    Esto es solo una opinión, no tengo ningún estudio científico que respalde esto. 🙂

    Según mi experiencia, el mayor error que comete la gente al prepararse para una entrevista es no ser entrevistado. Estudian problemas y soluciones, pero no se han preparado para la actividad física real de pararse frente a alguien y tratar de resolver un problema de programación. Es muy diferente a escribir un programa y, para casi todos, es muy estresante.

    Si se está preparando para una entrevista, además de estudiar las estructuras de datos, etc., solicite a un amigo o amigos que le den una entrevista simulada. Póngase frente a una pizarra, haga que la otra persona se siente en una silla y le pregunte un problema de programación, y luego intente resolverlo. Intenta conseguir un entrevistador experimentado si es posible. Practicará la actividad física real de ser entrevistado. Estarás pensando de pie, explicando cosas, respondiendo preguntas, etc. Si no ha realizado muchas entrevistas, intente obtener al menos dos o tres sesiones de práctica antes de la entrevista real. Debe devolver el favor a la persona que lo entrevista.