Recientemente solicité trabajos de programación y creé una pequeña carpeta con ejemplos específicos que muestran mis conocimientos de programación y muestran cómo mi experiencia laboral ha ayudado a mi desarrollo.
Estas son preguntas que he recibido durante las sesiones de preguntas y respuestas con posibles empleadores:
"¿Puedes programar?"
"¿Qué tan bien puedes programar?"
"¿Estás familiarizado con?"
Respondo a la pregunta y sigo con algo similar a:
Además, también he preparado un portafolio con ejemplos claros, algunas pruebas en vivo y ejemplos de código que puedes usar para tener una mejor idea de mi habilidad. Si tiene alguna prueba, estaría más que dispuesto a hacérmela también".
Esto generalmente se encuentra con más preguntas y apatía general al ver los ejemplos que he hecho y/o la falta de pruebas reales de mi habilidad.
En resumen y sin rodeos, diría:
Si te estuviera entrevistando como programador, tampoco me gustaría ver tu portafolio.
(Nota fuera de tema pero relacionada: preferiría un empleador que le pida que escriba código como parte del proceso de entrevista).
Con mucho más detalle...
En primer lugar, ¿qué prueba su cartera? Muy poco, a un entrevistador. Un portafolio de código no es como un portafolio de obras de arte: no tendrá mucha belleza subjetiva; no será significativamente diferente a la cartera que producirían otros cien desarrolladores con habilidades similares. A menos que su código se presente como una serie de fragmentos de trabajo de 10 líneas, el entrevistador no podrá comprender su cartera de manera significativa durante la entrevista; mucho tiempo para transmitir. Finalmente, no hay ninguna indicación en un portafolio de cómo o dónde escribió este contenido, por lo que no se transmite ninguna habilidad que pueda tener o no: ¿fue un ejercicio de 10 minutos para usted o de 6 semanas? ¿Es un trabajo torturado? ¿O simplemente lo raspaste de los resultados de una búsqueda en Google? Un entrevistador no puede saber, por lo que el portafolio es inútil.
En segundo lugar, cuando quiero ver tu código, quiero tener definido el problema que estás resolviendo. Cuando entrevisto, les pido a las personas que resuelvan un problema de codificación simple en un período de tiempo razonablemente corto (generalmente menos de una hora). Al hacer eso, yo, como entrevistador, ya tengo una buena comprensión de qué salida espero, lo que hace que mi trabajo de analizar el resultado sea menos complejo. Significa que tengo un conjunto de puntos de discusión preparados previamente para hacer un seguimiento que me permitirán cuestionar más profundamente las habilidades del candidato ("¿y si necesitamos hacer que este método sea seguro para subprocesos?" o "¿y si le pido que escalar hasta un millón de usuarios?"). Esto también facilita la comparación de candidatos porque hay un desafío común que todos han completado en condiciones conocidas.
En tercer lugar, considere lo que el entrevistador está buscando. La mayoría de las veces, en una empresa con visión de futuro, no buscan evidencia de que puede escribir una estructura MVC perfecta, usar una biblioteca determinada o reducir un algoritmo complejo a tres líneas obtusas de sintaxis. Un entrevistador quiere saber si eres inteligente . Cuando entrevisto a personas, quiero saber si pueden tener una conversación significativa e inteligente sobre opciones de diseño/arquitectura, que tienen una buena comprensión de los fundamentos de la programación informática y que tienen un interés activo en ampliar su comprensión. No me importa cómo se ve su código porque, nueve de cada diez veces, se les pedirá (en mayor o menor medida) que cambiencómo se ve su código para adaptarse a los requisitos del equipo y la base de código en la que están siendo contratados. Además, si un desarrollador puede tener esas conversaciones inteligentes, sé que es capaz de aprender los patrones, las bibliotecas o los lenguajes que son relevantes para el proyecto al que se une. La mayoría de las veces, no lo sabrán todo ya.
En cuarto lugar, considere lo que sé. ¿Soy siquiera técnico? Muchas veces, al menos uno de sus entrevistadores no lo estará. Si lo soy, es posible que no conozca las bibliotecas que ha utilizado, o incluso el idioma que ha utilizado, o la plataforma en la que se ejecuta su código. Puede que no entienda el problema que intentas resolver. El problema que está tratando de resolver puede ser interesante, pero puede que no sea relevante para el código base en el que está aplicando para trabajar. Usted no puede ver eso, pero el entrevistador sí, y estructurará la entrevista a su gusto.
Como entrevistador, mi tiempo con usted es limitado y quiero tener una conversación que saque a relucir su inteligencia, comprensión, capacidad de aprendizaje y experiencia. Es mi responsabilidad como entrevistador obtener esa información de usted y podría, si es útil o está justificado, optar por solicitar una muestra de su trabajo para ayudar con ese proceso. La mayoría de las veces, sin embargo, elegiría que un candidato lo demuestre a través de la resolución verbal y práctica de problemas, no a través de un proyecto escrito previamente de su propia elección.
Como candidato, debe confiar en que el entrevistador conoce sus propios requisitos y cuál es la mejor manera de obtenerlos de usted. Empujar una cartera debajo de sus narices e insistir en que entienden su proyecto favorito en realidad solo demuestra que no respeta sus requisitos y no le hará ningún favor en la entrevista.
En primer lugar, es una buena idea mostrar un portafolio en una entrevista de programación, ya que lo distingue de la multitud. La única vez que esto puede no ser útil es si su trabajo anterior era algo muy genérico y realmente no tiene mucho impacto. Al mostrar un portafolio, asegúrese siempre de que no contenga trabajos confidenciales o privados, especialmente si muestra fragmentos de código.
Si bien estoy de acuerdo en que los fragmentos de código de un candidato o los elementos de una cartera podrían haberse copiado y pegado desde una búsqueda en Google, la mayoría de los empleadores pueden validar esto simplemente haciendo una verificación de referencia con el empleador anterior del candidato o haciendo preguntas de sondeo sobre el ejemplo y cómo funciona. . Los comentarios que he recibido de las entrevistas en las que he mostrado un portafolio generalmente siempre han sido muy positivos.
Nunca presione su cartera al empleador, si no está interesado en verlo, entonces acéptelo y continúe con la entrevista normalmente. Tener un portafolio contigo que nunca se muestra es mejor que no tener uno y luego necesitarlo (Una imagen vale más que mil palabras). Generalmente solía mencionar "¿Le gustaría ver mi cartera de programación?" hacia el final justo antes de que termine la entrevista. La mayoría de las veces, el empleador dirá "Adelante, echemos un vistazo rápido", mientras analizan sus ejemplos, dígales cómo funcionan y por qué los creó de esa manera (esto demuestra comprensión).
En mi opinión, la definición de un portafolio de programación es la siguiente: 1) Capturas de pantalla de su aplicación 2) Descripción de su aplicación y tecnologías utilizadas 3) Un ejemplo funcional de su aplicación (si es un sitio web o una aplicación móvil) 4) Fragmentos de código (No se debe mostrar si es confidencial o privado) 5) Blogs o documentos técnicos que respaldan estos proyectos
Mucha suerte y espero que te sirva este consejo.
En mi experiencia en ambos lados de la mesa de entrevistas nunca he ofrecido ni me han ofrecido un portafolio.
Dicho esto, creo que tener su perfil de github.com en algún lugar de su currículum sería valioso si ha contribuido al código abierto o tiene un trabajo de código abierto allí. Esto permite que un empleador potencial explore su trabajo en su tiempo libre.
También debe enumerar claramente en su currículum los sitios web públicos en los que ha trabajado y en qué capacidad. Esto podría resaltarse en algún lugar o en línea con su experiencia laboral.
Si insiste absolutamente en incluir ejemplos de código para mostrárselos a su empleador, tal vez debería considerar incluirlos en su currículum, junto con una explicación de para qué sirve cada ejemplo de código/qué problema resuelve cada ejemplo.
Esto último es necesario , porque la mayoría de los ejemplos de código no son intuitivos, incluso para un usuario versado, en cuanto a para qué sirven o qué logran. Póngalos en perspectiva para su empleador.
Si encuentra que la mayoría de los empleadores no solicitan un portafolio o una muestra de código, es posible que desee considerar no traer uno a menos que se lo solicite explícitamente: diferentes entrevistadores quieren cosas diferentes y pueden estar más interesados en usted personalmente que en el trabajo que tiene. he hecho en el pasado. También pueden preferir ver su habilidad sobre la marcha en lugar de ejemplos antiguos que pueden estar anticuados y completamente irrelevantes para sus necesidades.
Sin embargo, en general, es una mala idea tratar de redirigir la entrevista. Este proceso es para que descubran sobre ti, y si constantemente tratas de cambiar su enfoque donde no lo quieren, no dejará una buena impresión en absoluto.
CMW
Dodzi Dzakuma
bpromas
code
sí mismo, sino en lo que puedes hacer con él.Dodzi Dzakuma