Fallé ocho entrevistas de codificación seguidas, aunque practiqué. Me gradué con una licenciatura en ciencias de la computación el año pasado, pero mis habilidades de algoritmo y estructura de datos son débiles. ¿Debería repensar si soy adecuado para ser desarrollador? ¿Qué tengo que hacer?

Cuando estaba en mi tercer año de universidad, estaba tratando de obtener una pasantía de verano. Me estaba esforzando tanto que hice casi todo lo posible para ser pasante de cualquier empresa. Pasé meses en la preparación de estructuras de datos / algoritmos y rogué a cada amigo por una referencia interna. Sin embargo, lo único que obtuve fue rechazo, rechazo para todas las empresas que solicité, sin importar qué tan bien me desempeñé en las entrevistas.

Parecía que la única forma de aprender era a través de prueba y error. Cada vez que fallaba una entrevista, hacía todo lo posible para resumir lo que hice mal y cómo podría mejorar para la próxima. Esto realmente funcionó! En mi octava entrevista (o tal vez la novena), finalmente pude pasar por las entrevistas de una pequeña empresa, que fue realmente el punto de partida de mi futura carrera.

Si alguna vez me hubiera rendido como desarrollador, no habría podido trabajar para Google o Facebook más tarde. Volviendo a su pregunta, no veo ninguna razón por la que deba repensar si es adecuado para ser ingeniero de software a menos que no sea un apasionado en esta área. Lo que debe hacer es estar más preparado para las próximas entrevistas.

Puede marcar 5 cosas que hacer después de fallar una entrevista para más discusión sobre este tema. Básicamente, encuentra tus puntos débiles y haz tu mejor esfuerzo para mejorarlos. Haga un plan detallado sobre cómo mejorarse y sígalo. ¡Buena suerte!

Absolutamente no. El fracaso de 8 entrevistas no es indicativo de su futuro o incluso potencial actual como ingeniero de software. Lo único de lo que es indicativo es que estás aplicando a las posiciones equivocadas o necesitas mejorar tus habilidades de entrevista.

Lo único que sabemos es que no tiene sentido hacer más entrevistas sin cambiar una parte de la ecuación. Debe analizar esto científicamente, cambiar una variable de su técnica de entrevista y observar los resultados. ¿Lo haces más abajo en la tubería de la entrevista? ¿O empeora las cosas?

Primera pregunta si está entrevistando a los tipos de puestos correctos. Si eres un desarrollador de iOS y estás entrevistando para roles de Ruby on Rails que tienen un pequeño componente de iOS para un front end tonto, ¡eso podría ser un problema! Asegúrate de estar entrevistando para roles donde coincidas con el conjunto de habilidades.

El segundo es el análisis de por qué sus entrevistas van mal. Puede que tenga que adivinar aquí. O incluso mejor, trabaje con alguien que pueda hacer entrevistas simuladas con usted. Recomiendo revisar el sitio de CareerCup ya que tienen algunos profesionales que pueden hacer entrevistas simuladas con usted y brindarle comentarios.

En mi experiencia en entrevistas con ingenieros de software, los siguientes son problemas típicos:

– No coinciden las expectativas. La compañía espera que el candidato conozca la programación de Windows y de alguna manera un programador de Unix OpenGL está en la entrevista.

– Problemas de personalidad. A veces, un ingeniero puede parecer realmente fuerte técnicamente, pero está claro que su actitud no funcionaría bien con el equipo.

– No resolver las preguntas técnicas o de pizarra de manera suficiente. Esto podría no ser conocer las tecnologías o cómo resolver un problema durante una discusión técnica. O un desempeño por debajo de las expectativas para la parte de la pizarra, ya sea para resolver algoritmos, diseñar sistemas u otra cosa.

Afortunadamente, todos estos tienen solución y no significan que su título universitario se haya obtenido en vano. El último punto, que es el caso más probable, se puede solucionar mediante el estudio de libros de algoritmos, y un gran punto de partida es Cracking the Coding Interview (libro de 2011)

Mi consejo es buscar un entrenador para hacer una entrevista simulada. CareerCup es un buen punto de partida.

La idoneidad de ser un desarrollador se puede juzgar por respuestas simples de Sí / No a partir de lo siguiente:

  1. ¿Te frustras si no puedes completar una tarea?
  2. ¿Te gusta resolver problemas?
  3. ¿Te aburres muy fácilmente mientras intentas resolver un problema?
  4. ¿Has intentado de forma creativa (utilizando conocimientos que no son de libros) acelerar el rendimiento de un algoritmo? (olvide Big-O por un segundo, la mayoría de las personas ni siquiera recuerda los valores de notación, solo usa el rendimiento de un solo hilo calculado por milisegundos, cronometra desde el inicio hasta la finalización)
  5. ¿Te gusta la codificación? (¿Te convertiste en un programador por elección propia?)
  6. ¿Te gusta abrir cosas (gadgets) solo para ver cómo funciona? ¿La curiosidad te impulsa?
  7. ¿Odias las matemáticas? (no es un requisito, pero le dice cómo lidiar con los problemas fuera de su zona de confort)

Edición 3: sepa que las preguntas 1, 2 y 5 con un No como respuesta significarían que esta carrera no es para usted, porque esos puntos básicamente describen el día de la vida de un desarrollador. Tienes que trabajar para resolver un problema o completar una tarea.

Puede obtener una entrevista y luego puede obtener el trabajo. Pero si sus intenciones son fundamentalmente erróneas o si está viviendo una mentira, entonces debe detenerse y volver a pensar. No sobrevivirá incluso si obtiene el trabajo (8 u 80 fallas no importan). Si odias o no te gusta el 70% (5 de los puntos anteriores), reconsidera esta elección de carrera.

Edición 2 :

Así que también estoy agregando algunos pros y contras para el juicio a largo plazo de esta profesión para futuros futuros estudiantes.

Pro:

  • El usuario de Quora en los comentarios señaló que es una carrera bastante estable, incluso si eres mediocre, lo cual es cierto, y paga bien.
  • Habilidades muy portátiles, puede mover su conocimiento de una compañía a otra, independientemente de la ubicación (excepto si su programación está en el polo norte, en cuyo caso tiene problemas más grandes)
  • Curva de aprendizaje continuo: si eres un geek, esta es una gran carrera. Si la tecnología lo impulsa, no tiene que preocuparse aquí.
  • Una vez que se convierta en especialista, tendrá una gran demanda y las empresas estarían dispuestas a pagarle salarios más altos por su experiencia.
  • Resuelves problemas del mundo real.
  • Puede obtener buenas oportunidades de capacitación si la empresa valora el avance de las habilidades de los empleados, pero no todas las empresas pueden permitírselo.

Contras:

  • Una vez que creas que eres profesional en algo, solo te darás cuenta de que hay alguien mucho mejor que tú en Internet que comenzó 5-10 años antes.
  • Como cualquier trabajo de escritorio, ralentizará su metabolismo y / o lo hará cansado / perezoso bastante rápido, como resultado, su barriga también aumentará con su saldo bancario, pero esto es prominente en cualquier trabajo de escritorio, la única diferencia es que este trabajo mentalmente también lo agotará, ya que se requiere un alto grado de concentración y compromiso.
  • Si se frustra fácilmente o tiene problemas de manejo de la ira, alienará a las personas al sacarles su frustración, estos pueden ser colegas, amigos o familiares, conozco uno de cada uno en la misma profesión.
  • Problema de Outsourcing: Hay alguien que está dispuesto a trabajar por 1/4 de su salario en un país con un tipo de cambio más bajo.
  • Tendrá que seguir actualizando sus habilidades y estar al tanto de la tecnología si no quiere estancarse.
  • Burnout (psicología): largas horas, plazos ajustados y sin vida personal / social y estrés. La mayoría de los desarrolladores de software tienen que sacrificar su propio tiempo para cumplir con los plazos sin pago extra o horas extras. (25% o más trabajan en promedio (50-60 horas / semana), pero diría que los médicos tienen que hacer aún más porque están de guardia en caso de emergencia, afortunadamente el bloqueo del servidor web o la computadora personal no mata a las personas. )

Crédito: Me llevó 2.5 años de autoaprendizaje incluso después de tener un título en ingeniería de software para obtener el trabajo de desarrollador de juegos. Si crees que conseguir un trabajo es difícil, no tienes idea de a qué te enfrentas cuando estás realmente en él, ¿qué harás si odias tu trabajo después de 3 años en él? Saltar barco?

Edición 1: concéntrese en sus puntos fuertes en términos de lo que le gusta, no es demasiado tarde para cambiar de carrera, pero cuanto antes se dé cuenta, mejor. Cuando tengas 40 años y quieras saltar a una nueva carrera, será difícil.

Puedes entrenar a una persona para que codifique a través de la educación formal, no puedes hacer que piense como un ingeniero, sus fundamentos básicos de cómo funciona tu cerebro, no es tu culpa.

En términos simples, puedo enseñarte cómo tocar un instrumento musical, no puedo enseñarte cómo crear sinfonías.

Ocho es un número muy pequeño. Yo personalmente he fallado en muchas entrevistas. Cada entrevista es diferente y los entrevistadores tienen expectativas diferentes. Puede hacer estas cosas antes y después de la entrevista:

1) Lea la descripción del trabajo con mucho cuidado. Busque en línea sobre el puesto (p. Ej., Desarrollador de software: pueden hacer preguntas sobre el diseño de clase / DS / Algo, conocer muy bien cualquier lenguaje de programación)

2) Este es el punto más importante: aprende de tus errores anteriores. Una vez que reciba un rechazo, responda el reclutador diciendo que “Gracias por la oportunidad. Avíseme cuándo puedo volver a presentar una solicitud ”. Analiza cómo respondiste la pregunta. Busque la pregunta en línea y vea qué espera el empleador. Hable con sus amigos sobre la entrevista para que puedan darle una idea de la pregunta y la respuesta.

Estos son puntos generales. Hay varios factores más, como hacer los cambios necesarios en el currículum, solicitar los roles correctos, estudiar adecuadamente. Si eres débil en DS / Algo, practica LeetCode, lee CTCI. Haga esto todos los días durante unas horas, verá los cambios usted mismo.

Tienes suerte de recibir entrevistas, muchos no lo entienden. Siga aplicando y póngase en contacto con los reclutadores a través de LinkedIn. Cada entrevista te enseña algo. Aprende de esto, y continúa.

¡No te rindas y la mejor de las suertes!

Dudo que me hayas vencido amigo. He fallado alrededor de 20 entrevistas.

Tengo un historial bastante bueno, pero las compañías a las que me he postulado, la mitad estaban equivocadas, la otra mitad no entendían lo que querían. Al principio, he estado yendo a entrevistas aleatorias de la compañía, la mayoría de las compañías no me han interesado. Han estado buscando una persona que tenga un amplio conocimiento de “todo”, aunque sus soluciones internas simplemente no merecen a personas como yo, tal vez suene narcisista, pero este tipo de empresas sería un callejón sin salida para mí.

Pero luego tengo la oportunidad de entrar en entrevistas de grandes amigos como: Ericson, Amazon, Logentries, Wargaming, Tripadvisor. He fallado en todas partes porque no tenía idea de las estructuras de datos y no tenía un conocimiento tan profundo sobre los protocolos de red como se requería allí. Tengo toneladas de información sobre qué debo dominar para ingresar a esas empresas. He decidido optar por http://odesk.com ( http://odesk.com ) freelance. Y en realidad lo estoy haciendo bastante bien. También he decidido realizar algunos cursos de http://coursera.com ( http://coursera.com ) sobre estructuras de datos y teorías de redes. Y no me rendiré, hasta que me convierta en un profesional de descendencia en mi campo 🙂

He estado trabajando en Barclays y Dell anteriormente, he estado tocando grandes sistemas, desarrollando y soportando aplicaciones de escala masiva realizadas en miles de millones de diversas tecnologías. Y luego vas a cualquier empresa, y te niegan solo porque no conoces las estructuras de datos y, por ejemplo, cómo la rutina de protocolo de enlace SSL o cómo funciona DNS en detalles. Entonces, como amo la ingeniería de TI, definitivamente no me rendiré

Esto claramente parece que solo estás probando suerte.

si realmente analizara cada entrevista que tuvo y se preparó para su debilidad en esas entrevistas, tendría una posibilidad absoluta de despejar la mayor parte de la entrevista técnica.

Las entrevistas técnicas se basan principalmente en análisis, del 20 al 25% se basan en el conocimiento.

aquí estoy asumiendo que si está solicitando un puesto de programación sabrá al menos un lenguaje de programación en su núcleo, a pesar de poseer un lenguaje orientado a objetos (C ++ / Java …) un lenguaje de secuencias de comandos (Python es ampliamente utilizado y la mayoría poderoso entre lo que he usado) se recomienda. resistirá si tiene experiencia con un lenguaje de programación funcional (scala, Ocamal, Haskell) pero para este contexto, conocer un lenguaje de programación es lo suficientemente bueno.


hay muchos materiales en la web, si comienzas a referirte a todo en paralelo durante tu etapa inicial de preparación, hay más posibilidades de que pierdas tu confianza y no puedas despejar la entrevista sin eso.

Simplemente elija un libro / sitio web que sugeriría “descifrar la entrevista de codificación” por Gayle

establezca una fecha límite para terminar el libro, cito FINALIZAR el libro, (me tomó 2-3 horas en la mañana durante 4 semanas) no dé descansos entre días, si tiene que resolver un rompecabezas de programación en el ir. Esto se debe a que su cerebro está haciendo conexiones neurológicas sobre cómo resolver estos problemas y será más difícil comenzar de nuevo si interrumpe durante unos días.

Una vez que haya completado este libro, puede revisarlo una vez más solo para actualizar (solo elija problemas aleatorios y resuélvalos)

ahora debería tener una visión más amplia de los diferentes tipos de problemas y usar múltiples algoritmos para resolver un problema en particular.

Ahora ha terminado con su preparación, ya que el resto de los pasos son divertidos y divertidos … resuelva problemas de los sitios web a continuación todos los días si puede, pero sea continuo si puede, recuerde que ahora es divertido ya que sabe más y su cerebro se ha formado Las conexiones neurológicas y su confianza sigue aumentando cada vez que resuelve un rompecabezas de programación

HackerRank

Juez en línea de LeetCode

cree una cuenta de GitHub y codifique cada problema que resuelva (durante las primeras 4 semanas de “descifrar la entrevista de codificación” también)

conviértalo en una cuenta privada si aún no está seguro de la belleza de su codificación 🙂

espero que esto ayude.

Bueno, no pude borrar mucho más que solo 8 …

Primero fue Cisco. Día uno de colocaciones, 50 candidatos preseleccionados. Las entrevistas están sucediendo y yo sigo siendo entrevistado. Los candidatos fueron rechazados. Se llamaron otros adicionales y, sin embargo, insistí. Mi última entrevista para el día ocurrió después de las 9:00 p.m., y el entrevistador me preguntó, después de la entrevista, si era otra persona. Ese otro, luego fue entrevistado, y después de las 10:30 pm, no conseguí el trabajo.

Lo que siguió a continuación fue EMC2. y fue todo lo contrario. Después de ser entrevistado, descubrí que algunas otras personas consiguieron el trabajo.

Después de eso, llegó IBM, quien se dio cuenta de que no tenían suficientes entrevistadores.

Entonces Thorogood.

Seguido por NetApp, que fue cortés en darme una entrevista al final del día.

Luego me llamaron a Informatica para un proceso de entrevista, que comenzó bien, y desde allí fue cuesta abajo.

eBay vino y se fue, junto con TCS e Infosys.

Luego vino citi, seguido por el grande: Microsoft. Microsoft: ahora ese fue un ejemplo de una oportunidad perdida. Después de completar 3 rondas y media de entrevistas, una implosión repentina.

Entonces, aquí había 9 ubicaciones, diciendo NO, y es solo el semestre impar …

El siguiente fue Mercedes, dijo No porque era una compañía de automóviles, en lugar de un software central (Sí, existe tal cosa).

Después de eso, fue Azul, la primera prueba escrita que no pude borrar (porque no sabía sobre las marcas negativas en la prueba).

Lo que siguió fueron algunas entrevistas de algunas nuevas empresas, con las que no tuve mucho éxito, hasta mayo.

La primera semana de junio tuvo muchas entrevistas.

El lunes, fue la prueba escrita de Qualcomm, seguida de otra entrevista de inicio. Ninguno de los dos se convirtió.

El martes por la tarde fue la entrevista de doctorado en el Departamento de Informática y Automatización del IISc, que fue un desastre, especialmente porque estaba usando la mañana para revisarlo.

El miércoles por la mañana fue la entrevista de doctorado en el Supercomputer Education Research Center en IISc, que fue un poco mejor. El miércoles por la tarde fue una entrevista con una PSU, llamada CSTEP. Pronto recibí una oferta de CSTEP.

El jueves asistí a las entrevistas de Nokia y recibí una oferta al día siguiente. Después de la entrevista, tomé un autobús para ir a la entrevista de Qualcomm, solo para que me dijeran, después de llegar al lugar donde Qualcomm “ya no buscaría la candidatura de Sandeep Mathias”.

Entonces, si fallaste en 8 entrevistas seguidas, ve a la novena y la décima, y ​​todas las demás entrevistas que aparezcan.

Tengo experiencias similares en el pasado cuando buscaba un nuevo trabajo (perdí la cuenta de cuántos reprobé :-), y tampoco estoy recién graduado, pero con algunos años de experiencia en software y redes informáticas. Estaba en un punto casi rendirme y culparme por mi fracaso y ser un perdedor. Me sentí avergonzado de no poder responder esas preguntas (pero sorprendentemente podría hacerlo mejor una vez que volviera a casa. Creo que estaba muy nervioso y cansado durante las entrevistas).

De todos modos, después de cada entrevista documenté lo que preguntaron (tanto como pude recordarlo), escribí mis respuestas y descubrí las respuestas correctas que debía responder (en algún momento busqué en Google las preguntas y las respuestas). También me sumergí en releer mis viejos libros de texto.

Después de algunas entrevistas, pude ver surgir algunas preguntas y me ayudó mucho a responder las preguntas en las próximas entrevistas. También le pedí a mi compañero de trabajo externo que compartiera su experiencia al aterrizar en otra compañía (perdimos el trabajo al mismo tiempo debido a la bancarrota de la compañía).

A menos que sea un estelar ingeniero de software ordinario, creo que ocho veces fallar en la entrevista todavía está bien. La clave es no rendirse. Piense en esas entrevistas fallidas como entrenamiento para su próxima entrevista.

Esta es una pregunta difícil y depende de algunos detalles. Sin embargo, en lugar de preguntar por ellos, voy a asumir que en realidad eres bastante brillante. Voy a suponer que te encanta codificar.

Asumiré que tienes el potencial de ser un codificador increíble.

Voy a suponer, en la negociación, que la verdadera razón por la que fallas es que te pones nervioso durante las entrevistas. Que quizás no eres bueno para pensar rápidamente bajo presión.

En el mundo real, los ingenieros no tienen a alguien mirándolos y planteando este tipo de problemas, por lo que su fracaso durante las entrevistas tiene, quizás, poca influencia en su capacidad de ser un buen programador.

La realidad sigue en pie; no eres bueno en las entrevistas y necesitas compensarlo.

El consejo de practicar y estudiar no es malo. Pero si eso no funciona, entonces necesita una copia de seguridad. Dado que, como mencioné anteriormente, eres brillante, te encanta codificar, y podrías ser un codificador increíble, entonces digo: sal y codifica . No necesita una empresa o un trabajo que lo ayude a hacer eso. Ve a contribuir a proyectos de programación. Ve a comenzar el tuyo. Olvídate de las entrevistas por un tiempo y encuentra lo que realmente te apasiona / interesa en el mundo de la programación y ve a construir cosas.

Luego, cuando tenga algún código real y proyectos en su haber, en primer lugar, las personas acudirán a usted. En segundo lugar, puedes decir con confianza “mira, no soy bueno codificando bajo presión, ¡pero déjame mostrarte algunas de las cosas que he construido!”

Por supuesto, hay un corolario aquí: al trabajar en todos estos proyectos, probablemente ganará confianza y fluidez, y no es improbable que mejore en las entrevistas. Pero incluso si no lo hace, lo anterior sigue siendo una cosa convincente para poder decir.


La mejor de las suertes.

Es bastante normal en la industria del software ser rechazado en las entrevistas. La mayoría de las veces sucede porque muchos solicitantes han solicitado ese puesto. No sé si las entrevistas están más inclinadas hacia el rechazo o la selección de candidatos. No importa que ocurra :). Yo también he fallado en muchas entrevistas. Algunas veces es en ronda técnica, algunas veces en ronda de recursos humanos. Pero cada ronda le dará un conjunto diferente de preguntas. Si está siendo rechazado una y otra vez debido a las mismas preguntas, entonces debe buscar la respuesta adecuada. Si las preguntas son diferentes, debe averiguar dónde y en qué área debe trabajar duro y comenzar a prepararse para ellas.

Nada es difícil, un día recuperarás tu suerte y nada podrá detenerte para conseguir el trabajo de tus sueños. Alguien genial ha dicho que FAIL no es más que “Primer intento de aprendizaje”.

Sigue intentándolo, muy pronto obtendrás el trabajo de tus sueños. Todo lo mejor.

Cuando tuve que buscar trabajo, me tomó meses. Envío currículums y no recibo ninguna respuesta, ni siquiera una automática, “Recibimos su currículum, lo guardaremos en archivo …” Recibo algunas devoluciones de llamada que no llegan a ningún lado. Y eventualmente obtengo uno que va hasta una oferta de trabajo. No conseguir el trabajo solo 8 veces sería una gran victoria.

Si siente que bombardeó en la entrevista, necesita estudiar más sus algoritmos. Si no “obtiene” algoritmos, tal vez otra carrera … Estudie mucho la búsqueda binaria y la clasificación rápida. Vienen con frecuencia en entrevistas.

Si lo hiciste bien en la entrevista, había algo más. Al igual que otra persona aplicada que es claramente más inteligente que usted, o que habla inglés mejor, o se ve mejor en ropa para el entrevistador, o fue a la misma fraternidad que el entrevistador. A veces compites contra personas con más experiencia. A veces hay 1,000 candidatos y solo un trabajo. A veces no hay trabajo en absoluto, y el empleador solo está troleando, en caso de que Albert enloquezca Einstein.

Puede esperar no conseguir mucho el trabajo. Si te sientes frustrado y renuncias después de solo 8 intentos, entonces descubrirás que la competencia es bastante intensa incluso para los trabajos de hamburguesas.

Tal vez has puesto tus miras demasiado altas, en cuanto al trabajo. Hay empleadores distintos de Microsoft, Amazon, Google y Facebook. Estos muchachos pagan bien, pero tienen altos estándares correspondientes. Hay muchos empleadores más pequeños.

Otras respuestas en esta pregunta son de personas con experiencia en múltiples dominios. Son excelentes.

Solo por motivos de motivación, quiero que veas este perfil: Mohsin Ali

Ha dado más de 60 entrevistas.

Recibió ofertas de muchas compañías multinacionales. Repase sus respuestas en Quora, ha escrito muchas respuestas para la preparación relacionada con la entrevista.

También ha escrito una guía para programar entrevistas: Guía

Seguramente buscaré la motivación de él si fallo en las entrevistas.

Él ha demostrado que al entrevistar muchas veces obtendrá experiencia sobre qué tipo de preguntas hacen las empresas y con esa experiencia podemos mejorar nosotros mismos.

Algunas de sus respuestas:

  1. Veo que a los desarrolladores de 25 años se les ofrecen sueldos locos, como $ 150 – 200 k, en compañías como Google, Facebook, Apple, etc. ¿Cómo puedo ser altamente calificado para calificar para tales ofertas, si no tengo educación formal pero Soy un desarrollador web?
  2. ¿Cómo debo prepararme para las entrevistas de Google, Facebook y Microsoft con CLRS considerando que realmente no soy bueno en Data Structures?
  3. ¿Cuáles son buenas maneras de abordar un problema en una entrevista si nunca antes lo ha encontrado?

¡Mi respuesta breve es que no necesita pensar en cambiar su carrera e ir a la novena entrevista! Piense en cuántas empresas de tecnología hay en el área de la bahía, en los EE. UU. Y en el mundo, y simplemente falló en 8 entrevistas de codificación. En otras palabras, hay innumerables compañías que aún no ha probado, y mucho menos también puede comenzar su propio negocio.

Pero antes de ir a la novena entrevista, tengo algunos consejos para usted en términos de preparación de la entrevista.

1. Dedique un tiempo para resumir sus últimas 8 entrevistas.
Es extremadamente importante entender por qué fallaste en las últimas 8 entrevistas. Sin darse cuenta de la verdadera causa, es muy probable que falles en la próxima.

Como dijiste, tus habilidades de algoritmo y estructura de datos son débiles, lo que es muy posible que sea la razón. Pero creo que todavía es demasiado general porque la codificación de entrevistas para nuevos graduados generalmente se centra en la estructura de datos y el algoritmo, por lo que su resumen es como si fallara la entrevista porque no me preparé bien.

Así que déjame ayudarte a determinar la causa. La mayoría de las personas fallaron en la codificación de entrevistas debido a 2 razones. Primero, conceptualmente no están familiarizados / claros sobre la estructura de datos y el algoritmo. Segundo, no tienen suficiente práctica con las preguntas de la entrevista. Si la mayoría de las veces no pudo determinar qué estructura de datos usar, o si tiene problemas al analizar la complejidad de tiempo / espacio, o no comprende completamente los pros y los contras de cada estructura de datos (como comparar la lista vinculada con el árbol y cuándo para usar cada uno de ellos), diría que caes en la primera categoría y realmente deberías elegir tu libro de texto para comprender mejor estos conocimientos básicos.

Sin embargo, si tiene bastante claridad sobre cada estructura de datos y algoritmo, pero fue lento al resolver esas preguntas o no pudo llegar a la solución óptima, es probable que solo necesite más práctica. Cubriré esto en las siguientes secciones.

2. Estar familiarizado con las preguntas de codificación
Siempre debe dedicar suficiente tiempo a las preguntas de codificación. Hay muchos recursos en línea como leetcode.com, glassdoor.com y Cracking the Coding Interview. Aquí hay varias cosas a tener en cuenta:

  • Siempre es bueno practicar preguntas pasadas de entrevistas de la compañía. Es poco probable que se le haga la misma pregunta en una entrevista real, pero puede hacerse una idea sobre el estilo y el enfoque de esa empresa.
  • Intente anotar su solución en la pizarra o al menos en papel. Muchos candidatos pudieron saltar rápidamente a la solución de escritura, pero no pudieron escribir el código. Es muy diferente entre describir la solución y codificar la solución perfectamente.
  • Intenta hablar mientras piensas. Esto es bastante importante en una entrevista real, ya que debe seguir comunicándose con el entrevistador. Es posible que inicialmente te cueste concentrarte y esto requiere algo de práctica.

3. Tener una entrevista simulada
La entrevista técnica no solo evalúa su capacidad de codificación, sino una variedad de habilidades y habilidades como habilidades de comunicación, capacidad de análisis, etc. También muchas personas se sentirán nerviosas al resolver un problema cuando alguien esté mirando por encima del hombro. Es por eso que las personas pueden fallar con problemas que se pueden resolver fácilmente en casa. El punto clave es practicar con una persona real en lugar de usted mismo.

Mucha gente también quiere recibir comentarios de buena calidad de entrevistadores experimentados. Con eso en mente, trabajamos en la construcción de Gainlo – Entrevista simulada con profesionales, que permite a los candidatos realizar entrevistas simuladas con entrevistadores experimentados de las principales compañías como Google, Amazon, etc. y obtendremos comentarios reales para ayudarlos a mejorar. Creo que en su caso, algunos comentarios reales sobre su desempeño son muy importantes.

Conclusión
Fallar 8 entrevistas seguidas no es un gran problema ya que puede tener más entrevistas más tarde. El punto es realmente entender por qué fallaste en esas entrevistas y cómo preparar mejor tu próxima.

Estoy de acuerdo con la mayoría de las respuestas que ya están aquí, excepto la que te dijo que te des por vencido. 🙂

En lugar de avanzar hacia más entrevistas de codificación, le sugiero que encuentre otra forma (o algunas otras formas) de practicar y ser calificado, sin el estrés adicional de una entrevista de trabajo.

Publique una pregunta por separado en Quora solicitando sitios que brinden este servicio para sus idiomas de destino, algoritmos, marcos, etc.

Si lo haces mal, el problema es tu nivel de habilidad.

Siga tomando estas pruebas, luego use Pluralsight. com, Lynda. com, Books24x7 o lo que sea (más práctica de codificación) para aprender lo que necesita saber.

Solo dado el hecho aislado de que has fallado en 8 entrevistas de codificación, nosotros (amigos de Quora) no tenemos idea de si no sabes cómo programar o si simplemente colapsas bajo la presión de una entrevista de codificación.

Tenga en cuenta que la presión de una entrevista de codificación es MUCHO PEOR que la presión de un trabajo de programación. En el trabajo, siempre que no orines los pantalones, puedes seguir trabajando en un problema hasta que lo resuelvas.

Si comienza a tardar demasiado o está atascado, solicite ayuda (desbordamiento de pila o lo que sea). Si no tiene tiempo para StackOverflow, le pregunta a un compañero de trabajo.

Si le preguntas a tus compañeros de trabajo con tanta frecuencia que se molestan, o eres demasiado vago o no estás calificado para ese trabajo de programación específico.

¡Desarrolla tus habilidades en este entorno simulado hasta que estés feliz, orgulloso y listo para rockear!

Luego, o bien logrará la próxima entrevista de codificación, o sabrá que simplemente apesta.

Si falla otro, puede dirigir al entrevistador a todos los proyectos de código abierto en los que ha contribuido y los proyectos paralelos que ha publicado en GitHub.

¡Actúa y sigue adelante! 🙂

Espero que esto ayude,

Adán

Hubo un punto en el que estaba fallando entrevista tras entrevista, a pesar de que era (todavía lo soy) bastante bueno con algoritmos y DS, hasta el punto de que enseñé a mis amigos sobre esos temas. Aún así, no pude pasar ni siquiera las primeras rondas. Un consejo de mi profesor realmente me ayudó. Esperemos que también te ayude. No pienses en una entrevista como una entrevista. Piensa en ello como una conversación. Escucha atentamente cada palabra. No empiece a pensar cuál es la respuesta cuando el entrevistador todavía está explicando la pregunta. Luego, haga tantas preguntas como sea necesario para aclarar si tiene alguna duda sobre cuál es el requisito de la pregunta. Preguntas como “¿Puedo usar una estructura de datos adicional (como matriz, mapa, etc.) para resolver el problema?” , “¿Cuántos registros puede contener el archivo?” etc. te aclarará las cosas y también hará feliz al entrevistador, ya que espera que hagas preguntas. Una vez que los requisitos del problema estén absolutamente claros, es probable que obtenga la solución correcta. No tiene que ser rápido para dar la respuesta. Por lo general, le pido a mi entrevistador unos minutos para pensar. Durante esos pocos minutos, nadie está hablando. Pero está bien, pensar en la dirección correcta es importante. Cuando apliqué el consejo de mi profesor, conseguí un trabajo en la próxima entrevista. Y antes de eso, nunca había aclarado ni siquiera la entrevista telefónica. Historia verdadera. Espero eso ayude.
Mira el libro “Romper la entrevista de codificación”. Si practicas y entiendes los problemas dados allí, tendrás muchos menos problemas con tus algoritmos y DS.

Hay muchas personas que se han estrellado y quemado muchas entrevistas seguidas. Este hilo es un ejemplo invaluable:

Fallé una entrevista para una gran empresa y me siento roto. ¿Qué debo hacer para superar?

Entonces no, no deberías repensar en absoluto.

En mi caso, sigo un enfoque de arriba hacia abajo al revisar la documentación de iOS y comprender sus capacidades y el material. Miro los videos de WWDC, realizo ejercicios de programación y tomo muchas notas. Intento mantenerme al día con los diferentes patrones de diseño arquitectónico y de programación. Además, lidero un esfuerzo en el trabajo para continuar educando a mi equipo, completando pedidos de libros, leyendo capítulos y organizando debates.

Antes de obtener el primer trabajo, reprobé 18 entrevistas (si incluyo también una prueba escrita, entonces la lista es de más de 27 compañías). En los días de la universidad yo era un estudiante por debajo del promedio. Muchas veces perdí la confianza y tenía la impresión de que no podía conseguir un trabajo en desarrollo de software y también estaba preocupado por mi carrera. Pero era consciente de una cosa que, incluso si no soy tan bueno en mis temas técnicos como algoritmo, base de datos, etc. Soy bueno en los fundamentos y me gusta la programación. Seguí aprendiendo técnicas, codificando a través de blogs que participaban en sitios de preguntas y respuestas como Stackoverflow, etc.

Un día tuve la oportunidad de trabajar con una pequeña empresa y me uní a ella por unos pocos miles de rupias. Supongo que me desempeñé bien allí ya que ahora tengo un par de ofertas de trabajo de “ven y únete”.

Según mi experiencia, diría: “Elige lo que te gusta ser y trabaja duro para lograrlo, lo que puedes hacer solo si haces lo que te gusta hacer “.

Buena suerte.

Hola,

Lo primero es lo primero, déjame decirte que la situación que estás enfrentando no es nueva.

No todas las personas consiguen el trabajo en su primer intento, y si lo hicieron, no muchos se adhieren a él. En esta era de competencia feroz, todas y cada una de las entrevistas prueban mucha profundidad en el campo en la que esperan que el candidato sea competente. Después de todo, tienen que pagarle por su tiempo y todos los recursos que brindan, entonces la competencia seguramente será más dura a medida que más y más codificadores se sumen a esta competencia.

Hay una diferencia entre escribir software y pasar una entrevista. Escribir software requiere comprensión y la capacidad de crear código. Pero la preparación de la entrevista requiere práctica y conocimiento sobre relativamente pocos temas que se preguntan con frecuencia, subcontratados especialmente de sitios como GeeksforGeeks | Un portal informático para geeks. Entonces, incluso si no puede hacerlo bien en las entrevistas, no se desanime. Solo entienda que la entrevista es más un pasaporte para darle esa oportunidad, como la pantalla antes de que realmente consiga un papel en una película. El hecho de que pierdas algunas películas al principio no significa que no puedas actuar o que no puedas estar en películas. ¿Derecho?

En cambio, concéntrate en lo que te voy a decir ahora.


1. Trate cada entrevista como un banco de preguntas. Realmente no tienes que pensar si es un fracaso o un pase. Solo piense en esto como una prueba que simplemente le permite evaluarse a sí mismo y tómelo como se supone que debe ser. Comprenda las preguntas que se le hicieron, escríbalas, piense por qué no pudo hacer eso especialmente. la rama de la codificación con la que está relacionada, como la programación dinámica o la recursión, que sin una comprensión adecuada no se puede resolver fácilmente en una situación de presión.

2. Pasar la entrevista se trata más de exponerse a todas las preguntas que realmente se hacen. ¿Realmente has visitado el sitio web completo de GeeksForGeeks? No cierto? Haz eso primero. Significa que estará expuesto a todos los diferentes modelos en los que está presente una pregunta, el tipo de respuestas y el enfoque a seguir. Aprenda el enfoque en lugar de la respuesta de memoria. Luego, puede aplicar este enfoque incluso si surgen preguntas similares.

3. No todas las entrevistas y todas las empresas tienen entrevistas mucho más duras. Algunas compañías tienen rondas más fáciles por adelantado, ya que podrían tener una escasez de recursos en ese momento en particular o tener puestos urgentes que cubrir. Si no te decides, echarás de menos a estas empresas. Entonces, si la supervivencia es su prioridad, siga asistiendo a entrevistas y eventualmente aparecerá una de ellas.

4. Sé bueno en eso, toma una pizarra y comienza a codificar en la pizarra. Ponte cómodo con eso. Consulte buenos libros como Cracking Coding Interview por GayleMcDowell.

5. Código código código. No hay sustituto para esto.


Finalmente, simplemente no te rindas. Estás en el campo correcto, confía en mí. Hacer que cuente.



Averigua qué te equivocaste y hazlo bien.

Haga una lista de todo lo que necesita saber y luego revise metódicamente esa lista hasta que pueda manejar cada uno con confianza.

Además de solo estudiar, hacer sus propios programas, participar en un proyecto de código abierto, ofrecerse como voluntario para ayudar a un juego de kickstarter (muchos necesitan ayuda con la codificación). Haga algo (cualquier cosa) que lo haga contribuir a la codificación de algo que se publica.

Renunciar ahora será mucho más difícil que mejorar. ¿Realmente desea comenzar una carrera diferente y tener los mismos problemas (y más deuda) en unos pocos años? Puede cambiar de carrera, pero siempre trae consigo un problema importante: ¡USTED!

Las entrevistas de PS 8 no son nada. Hacer 500.

Si crees que eres adecuado para ello, sigue intentándolo. Trata de no concentrarte en las grandes empresas que parecen querer contratar minions con nada más que algoritmos y estructuras de datos que se abultan de sus cabezas, listos para la elección. Encuentra empresas más pequeñas. Encuentre empresas que no solo tengan un espíritu de mentoría sino que lo demuestren a través del emparejamiento de mentores de nuevas contrataciones.

Hace muchos años, las entrevistas eran más sobre cómo interactúas con los demás. Si no les gustabas, no conseguirías el trabajo. Si no te gustaron, no aceptaste la oferta.

Si sus habilidades son débiles, practicar antes de la entrevista no va a hacer nada positivo. Por el contrario, te pondrá más nervioso porque estarás pensando ” Acabo de leer esto … ¡ debería recordarlo!” Tal vez tenga un algoritmo débil y habilidades de estructura de datos. [Aparte: ¿qué demonios significa eso?!] ¿Qué otras habilidades tienes? ¿Qué tan bueno eres en estas otras habilidades?

¿Puedes leer [o escribir] un enunciado del problema y entenderlo? [es decir. requisitos]
¿Puedes construir una idea sobre cómo resolver el problema? [es decir. diseño]
¿Puedes leer el código de otras personas y entenderlo? [es decir. investigación de espacio de problemas para soluciones similares]
¿Puedes desarrollar un programa C * a partir de tu idea? [es decir. codificación]
¿Puede depurar su programa C y probar / probar que proporciona la respuesta correcta? [es decir. prueba / integración]
¿Puedes resumir tu solución a otros problemas? [es decir. sistemas]

* Escogí C porque en mi campo, saber que C es similar a conocer a Jesús. Siéntase libre de reemplazarlo con su idioma favorito.

Si puede hacer algo de lo anterior, tiene habilidades para las que le contrataría si estuviera buscando a alguien.

No te rindas Y no se concentre en los “fracasos”. Hay un trabajo por ahí.

La respuesta de Christopher Pow a ¿Los reclutadores de Google ofrecen entrevistas a personas que saben que funcionarán mal? Durante tres años seguidos, fui entrevistado y fracasé miserablemente. ¿Pueden los entrevistadores ver el desempeño pasado del candidato o cuántas veces han solicitado un trabajo?