Sigo fallando manos en parte de la entrevista, ¿sugerencias? [cerrado]

Entonces tengo un par de software / sitio en mi cartera. Ganan dinero pero no mucho.

Así que decidí obtener algo de experiencia laboral, principalmente aplicando a puestos de desarrollo junior Java / PHP.

El problema es que contesto todas las preguntas técnicas correctamente y programamos hacer una "prueba" de codificación, la fase final de la entrevista. Nunca puedo relajarme y pensar demasiado y terminar haciendo la prueba muy lentamente. O a veces simplemente golpeo un bloque y me resulta muy difícil pensar de pie.

No entiendo esto porque otras cosas que había escrito resolvían problemas mucho más complejos, mientras que la "Prueba" en realidad es brutalmente simple, como escribir y probar palíndromo.

Otras veces, me harán una prueba lógica con flujos a operaciones matemáticas y nuevamente no podré hacerlo en el tiempo que me asignen.

Sé que puedo escribir software / sitios web vendibles que pueden generar pequeños ingresos y encontrar formas de resolver problemas, pero tengo grandes dificultades con simples pruebas de codificación en entrevistas.

¿Alguna sugerencia?

Sigue asistiendo a entrevistas. Eventualmente encontrará un lugar que le hará preguntas más adecuadas a sus puntos fuertes. También se sentirá mejor y más cómodo con las entrevistas, lo que solo puede ayudar. Míralo como un juego, porque eso es realmente lo que es. Sigue jugando y eventualmente ganarás.

Esto es muy comun. La mayoría de los programadores pueden programar efectivamente cuando están en su zona de confort. Por ejemplo, solo puedo trabajar en Ubuntu, con vim, si no tengo ese espacio de trabajo no tendré ganas de programar. También requiero , en cierta medida, Google para la investigación.

Estoy seguro de que ha desarrollado una zona de confort para la programación. Recomendaría acostumbrarse al entorno en el que alguien está detrás de usted esperando que se complete su código. La mejor manera de acostumbrarse es continuar yendo a la entrevista.

Puede pensar que no tiene mucho impacto, y podría no tenerlo. Pero para algunos de nosotros, la programación con música o sin ella, usando un IDE o un simple editor de texto, usando una silla de madera o sentado en un sofá, una habitación oscura o una habitación luminosa ... hacen una gran diferencia en nuestro desarrollo velocidad.

Tenga en cuenta que, una vez que obtiene el trabajo, generalmente puede crear su propia zona de confort en el espacio de oficina que le brindan.

EDITAR : Esta pregunta me recuerda a un vendedor, preguntando cómo sentirse cómodo y mejor en llamadas en frío. La mejor respuesta es seguir haciendo llamadas en frío y reflexionar sobre cada llamada. Después de un tiempo, el vendedor mejora sus habilidades y su comodidad. Creo que el programador no es diferente cuando asiste a las entrevistas, después de todo, el punto principal es venderse al entrevistador

Esta es solo mi sugerencia, ¿por qué no intentar ser emprendedor? Puede haber muchas personas que enfrentan el problema similar. Si puede escribir sitios web para obtener pequeños ingresos, entonces seguramente puede ganar mucho dinero con ellos.

Ya has identificado cuál es tu problema: resolver problemas bajo presión (es decir, cuando alguien te está mirando). ¿Es porque carece de confianza o no tiene suficiente experiencia o agrieta bajo presión?

Ir a muchas entrevistas para obtener algo de experiencia y práctica puede ser una buena idea, pero también puede producir contra-efectos. Los fracasos constantes en las entrevistas pueden sacudir aún más su confianza, así que tenga cuidado.

Te sugiero que pruebes la programación entre pares para que te sientas cómodo para resolver problemas cuando alguien te esté mirando. Además, trate de descubrir qué es lo que le impide ser efectivo bajo presión (es el estrés de las pruebas en sí, el estrés de trabajar bajo estrecha supervisión, el estrés de trabajar bajo un límite de tiempo específico, etc.).

Parece que te ahogas bajo presión. Como debe hacer los ejemplos cronometrados como parte del proceso de la entrevista, tendrá que aprender a superar esto. Esto se trata de manejar el miedo, no de la habilidad de programación.

Una opción sería practicar escribir problemas de muestra y cronometrarse. Una vez que sepa que puede hacerlo en menos de diez minutos, puede temer que se le tome menos tiempo.

Otra opción sería idear una técnica para calmar su miedo y utilizarla para liberarse. Aprender una técnica de meditación podría ayudarte. O memorice la letanía contra el miedo (de Dune ). Aprenda algún tipo de truco para eliminar su respuesta al miedo.

Estoy bastante sorprendido de que nadie haya preguntado esto todavía, pero ¿cómo estás abordando las tareas de programación ?

Si simplemente está saltando al código, entonces es probable que se pierda y termine cometiendo errores simples y poniéndose nervioso. Dé un paso a la vez:

1. Reúna los requisitos : ¿Qué es exactamente lo que le pregunta su entrevistador? Asegúrese de que haya cero preguntas en el aire antes de la codificación. Por ejemplo, si se enfrenta con la antigua pregunta "isPalindrome", pregunte cosas como "¿y si la cadena tiene caracteres especiales?" o "¿las cadenas de longitud impar como 'ada' cuentan como palíndromos?". Usted necesita saber la forma de aclarar los requisitos antes de diseñar un algoritmo.
2. Diseñe su algoritmo : divídalo en secciones lógicas si tiene sentido. Hable sobre eso ... Tal vez escriba un pseudocódigo si está haciendo pizarra. Guíe a su entrevistador a través de sus pasos. Intente ejecutarlo con algunas entradas diferentes (tanto válidas como no válidas) para asegurarse de obtener los resultados deseados.
3. Ahora comience a codificar : en este punto, debe tener mucha confianza en lo que está a punto de escribir. Esencialmente, deberías seguir los movimientos con cualquier idioma con el que estés familiarizado. En este punto, realmente no importa si hay errores sintácticos, ya que los entrevistadores que valen un centavo perdonarán a los que estén en una sesión de pizarra (si le dan una PC / IDE para resolver el problema, esa es una historia diferente).

Realmente, cuando se abordan problemas de codificación, un entrevistador no busca tanto código excelente ... Es más para ver cómo se aborda un problema determinado. Zambullirse directamente en el código es algo malo, punto.

También encontrará que a medida que habla sobre el problema (recopilación de requisitos y diseño), se sentirá un poco más cómodo y será menos probable que cometa errores tontos durante la parte de codificación.

Proyecto euler

Me parece que estás reprobando la prueba de fizzbuz . Mente que adormece algoritmos simples que generalmente no tienen ningún propósito práctico, excepto identificar si comprende los conceptos básicos de la programación.

Repasa tus conceptos básicos

Lo que recomendaría es que repases tus conceptos básicos.

http://projecteuler.net/

Regístrese y comience a practicar, descubrirá que al seguir esos ejemplos obtendrá una comprensión más profunda de los conceptos básicos de programación. Creo que encontrarás una pregunta de palíndromo junto con secuencias de fibonacci y otros conceptos matemáticos (suena familiar).

Solicite comentarios en o después de la entrevista. ¿Qué les gustó? ¿Qué no les gustó? Puede que te sorprendan las respuestas.

Diferentes personas buscan diferentes cosas, por supuesto, pero la forma de tratar de resolver un problema suele ser más importante que escribir una solución 100% correcta. Tal vez te preocupes por todas las cosas equivocadas.

La mejor manera de mejorar en algo es practicar. Intente escribir una lista de problemas cortos. Luego, para cada elemento de la lista, escriba un pequeño programa que resuelva el problema. Comience con problemas muy fáciles, como FizzBuzz , y aumente la dificultad a medida que avanza. ¿Puedes resolver los problemas que has visto en entrevistas anteriores? ¿Encuentra la subcadena más grande que tienen dos cadenas en común? Calcular la factorización prima de n !?

La idea no es aprender la solución a cada problema que pueda encontrar, sino darse un poco de práctica escribiendo programas pequeños rápidamente, y también descubrir dónde están sus puntos débiles para que pueda mejorar. Muchos problemas son fáciles de resolver con la estructura de datos correcta, pero de lo contrario son difíciles, así que asegúrese de tener una base sólida en las estructuras de datos.

Practique y encuentre a alguien que lo guíe a través de los conceptos básicos sobre cómo superarlo. Puede tomar varios intentos, pero podría ser sorprendente lo que se descubre si puede obtener algunos comentarios y practicar sobre esto. Una vez un reclutador me explicó cómo manejar un problema de pizarra una vez que parece ser similar a su problema aquí.

No estoy sugiriendo memorizar respuestas tanto como tener un anteproyecto de qué hacer cuando se da tal problema y cómo hablarlo. A qué se parece esto? ¿Has visto problemas similares? ¿Qué podrían dar algunos enfoques simples en términos de un algoritmo? Al menos esa es mi sugerencia para ti.

Es bastante común que los desarrolladores de software se quejen cuando se les pide que realicen una prueba de codificación o que escriban un pequeño fragmento de código en la entrevista. Como alguien ya ha mencionado, eso se debe a que la mayoría de nosotros solo podemos codificar cuando estamos en nuestra "zona de confort" y sentados en una habitación pequeña, rodeados de 2-5 entrevistadores, en realidad no agrega mucha comodidad.

La respuesta es triple:

• practicar y practicar más. intente durante un mes hacer 30-40 minutos de programación con papel y lápiz y se sorprenderá de lo fácil que sería. Mientras practica, pruebe el tipo de tareas de programación que espera que le pidan en las sesiones de codificación de entrevistas, por ejemplo, implemente un singleton, invierta una cadena, etc. Es aún más fácil con "leer ese fragmento de código basura y encontrar lo que está mal". "- intente imprimir y analizar estas impresiones durante dos semanas y mejorará enormemente esa habilidad.

• aprende a controlar tu miedo. Si crees que la prueba es demasiado difícil y solo puedes completar el 20%, haz ese 20%, no te preocupes por el resto. Puede ser que la prueba sea irracionalmente grande para el tiempo dado para hacerlo (por ejemplo, los chicos en la entrevista deberían darte 20 minutos para terminarla, pero necesitan terminar la entrevista en 5 minutos debido a una explosión de producción, etc.) . También es posible que otros candidatos solo hayan logrado completar el 10% de la prueba, por lo que al completar el 20% todavía estará por delante de otros candidatos.

• Cuando escriba un código en la entrevista, no se moleste en hacerlo perfecto en un primer paso. simplemente implemente un "camino feliz, también conocido como el escenario más común primero" y luego trate de manejar los errores. si se está agotando el tiempo, simplemente agregue una nota rápida en la parte inferior del bosquejo de la hoja, lo que habría hecho para mejorar el código si hubiera tenido más tiempo.

[tengo que correr, editaré / mejoraré mi respuesta más tarde]

Como muchas personas ya han dicho, la práctica es una de las cosas más importantes. Si ya ha solucionado un problema similar, podrá encontrar la solución rápidamente.

Si tiene dificultades para encontrar problemas para tratar de resolver por su cuenta, intente utilizar la búsqueda de Google para programar preguntas de entrevistas para su idioma o elección.

También puede recoger libros diseñados para enseñar cursos de CS de nivel inferior. La mayoría de estos libros están llenos de tareas de programación que son pequeñas y se pueden hacer rápidamente en casa. Se pueden usar para practicar.

También soy muy malo en las pruebas y siempre lo he sido. Por mi vida no pude entender por qué una clase de programación me dio pruebas para tomar con lápiz y papel. Nunca fui bueno en eso. Sin embargo, lo que hice fue explicar a los entrevistadores que tenía este problema y que lo sabía. También logré entrevistar a empresas que no me hicieron pruebas tontas.

Mi sugerencia es decirle a la compañía antes de entrar en la entrevista que no lo hará con ese tipo de pruebas, sin embargo, está contento con X. (Encuentra una alternativa que tenga sentido y te sientas cómodo haciéndolo). Por mi parte, les ofrecí enviarles el código, y una vez les sugerí que me dieran un programa simple para escribir, y lo llevaré conmigo al entrevista en 3 días.

Dependiendo de dónde esté buscando trabajo, esto puede o no funcionar para usted.