Hola! 👋

En Videsk nos gustaría dar sugerencias y consejos a todos los desarrolladores y programadores, para que sus postulaciones puedan demostrar sus habilidades y potencial de mejor forma.

Estas sugerencias no aplican para postular a todas las empresas, ya que no todas privilegian los mismos puntos que nosotros y buscan cosas muy diferentes en los devs.

Sobre ti

Este es el punto más relevante para nosotros, por lejos. Aquí necesitamos que nos puedas contar de ti, sobre tus habilidades, metas laborales, qué esperas de ti en los siguientes 2 a 3 años o más. Para nosotros es importante generar relaciones a largo plazo, donde tú puedas crecer, obtener más experiencia y conocimientos cada día, pero para ello debemos hacer match con tus metas y nuestra visión de equipo. Es decir, remar para el mismo lado.

Muchas veces esto se va a complementar con entrevistas remotas, que habitualmente vienen posterior a una prueba técnica.

Es en estas entrevistas donde queremos conocerte, dejando de lado código y conocimiento profesional, solo una conversación natural. Ahí vemos si hacemos match o no.

Experiencias

Si eres de los que recién está buscando su primera experiencia laboral y piden experiencia laboral, haz exclamado, ¡Pero si justamente estoy buscando mi primera experiencia!. Bueno, esto aplica para los que si tienen experiencias laborales anteriores y los que no.

En Videsk, si suma tener experiencia, pero no es excluyente si no la tienes, de hecho, hemos contratado a devs que están actualmente en nuestro equipo que no tenían experiencia laboral pero con un perfil autodidacta muy destacable.

Y es allí donde nos vamos a centrar, qué haz hecho y qué puedes hacer, para que independiente si tienes o no experiencia laboral, puedas demostrar tus habilidades y conocimientos como profesional.

Esto también aplica cuando no tienes experiencia con alguna tecnología en particular, pero si haz trabajado antes. O estás migrando de perfil dev.

Qué haz hecho

Esto no tiene que ver en dónde haz trabajado! Si no mas bien con show me things!. Como por ejemplo, mostrar tu perfil de Github, Gitlab, Bitbucket, Codesandbox, etc. proyectos hosteados, cursos y tutoriales a los cuales les haz añadido tu esencia.

No se trata de una línea de tiempo con tus experiencias laborales, se trata de ver que cosas haz hecho en el tiempo para formarte tú como dev. Por ejemplo, si no cuentas con experiencia laboral, te sugerimos seguir un tutorial o curso que encuentres, pero recuerda que es una guía, debes añadirle de tu propia cosecha.

Los clásicos Pokédex, Rick and Morty API, Tic Tac Toe, dashboard de recetas, COVID API y dashboard, CI/CD actions, etc. solo piensa cuantos miles de otros devs tomaron ese curso, tutorial o bootcamp e hicieron exactamente lo mismo que tú. En simple, ve más allá que solo seguir al pie de la letra el tutorial o curso.

Si cuentas con más años de experiencia laboral, entonces será altamente esperable que tengas código de calidad y con mejores prácticas, proporcional a tu experiencia.

Dato freak! Casi el 60% de las postulaciones que recibimos tienen los mismos tutoriales o cursos, prácticamente idénticos.

Ten en cuenta esto! En una sola oferta laboral pueden llegar más de 200 devs, y el 60% (120 devs), tienen las mismas repos, cursos, etc. 1 línea de código puede hacer la diferencia (literal).

En nuestro caso, sí revisamos los repositorios con tu código, por lo tanto acá dejamos algunos consejos que deberías tener en cuenta en torno a lo que vayas a dejar público.

1. Si tienes un proyecto con frontend hostea en Github Pages, Vercel, Netlify, Cloudflare Pages, Gitpod, Storybook, etc., no solo dejes el código público. Al fin y al cabo frontend no es algo que se tiene que ver e interactuar? 😝
2. Si eres back-end enlaza tu código con Codesandbox, Glitch, Heroku, Gitpod, etc. permitirá probar rápidamente que es lo que haz hecho. O un README que explique que hace tu código.
3. Si eres DevOps, SysAdmin, etc. añade tu código Docker, Terraform, Bash, Ansible, YAML, etc. con algún README que explique de forma simple los patrones de diseño que utilizaste, beneficios y/o desventajas.
4. Si eres un DBA crea snippets de queries, pipelines, modelamiento, planes de contingencia, ficheros BI, planes ETL, aplicadas a un caso ficticio. Por ejemplo, si prefieres MongoDB utiliza herramientas como Mongo Playground para mostrar tus pipelines.

Y en general, independiente del cargo, existirán muchas formas tangibles de mostrar tu conocimiento, compártelo con el mundo. En resumen, Show me the code (or demo)!.

Todas las herramientas mencionadas anteriormente proporcionan una capa gratuita para hostear proyectos! No te preocupes por el dominio!

Tip: si eres frontend al menos deja un screenshot/gif de lo conseguido!

Tip 2: Añade en tu README o en los git message cuando estás aún trabajando en un repo.

Si trabajaste anteriormente, los repositorios de la empresa pueden ser privados, lo cual es muy probable. Por lo que antes de postular, tómate unos pocos días y construye algo simple en lo que tengas más habilidad, conocimiento y te motive.

Puedes hacer algo tan simple con un gist o extracto de código, pero que demuestre tu conocimiento base en data manipulation, sorting, parsing, loops, recursive function, array manipulation, pipelines, the best practices of _______, security concerns, deployments, CI/CD, etc, etc, etc. aplicado a algún caso de uso en concreto. Estas son las clásicas preguntas en todas las empresas, aunque la mayor parte de las veces en Videsk las ponemos a prueba 🤓.

Busca la forma en que tu código quede público y que se pueda probar, puede demostrar tus habilidades y conocimientos. Además, aprenderás en el camino.

Lo que nunca debe pasar, es postular y que cuando entremos a tu perfil nos topemos con esto:

Ojo! No es necesario que tu perfil de Github (u otro), esté lleno de repositorios, miles de estrellas, seguidores o el mapa de calor con mucha actividad. Pero si, al menos 1 repositorio que sientas que demuestra tus conocimientos, habilidades y/o experiencia al momento de postular.

A modo de ejemplo, son escasos los devs que en su descripción o CV, nos dejan un enlace a un proyecto que consideran que han vertido sus conocimientos hasta el momento y quieren que lo revisemos. Eso nos llama la atención, motivación propia!

Por eso en nuestro caso, hacemos pruebas técnicas para que sobre ese código podamos ver la esencia de cada dev.

Qué puedes hacer

En Videsk rara vez haremos entrevistas técnicas en vivo, ya que sentimos que la presión puede jugar muy en contra al principio, y darnos una errada percepción sobre ti.

Por eso preferimos pruebas técnicas que tienen plazos de envío, así estas cómodo, si quieres puedes "googlear", usar Stackoverflow, buscar en docs, ChatGPT, etc. lo que realmente nos importa es ver qué lógica aplicaste 🧠, si lees y entiendes bien las instrucciones. Sí, nos damos cuenta de los copy/paste...

Ojo, que pre-seleccionamos para pasar a la prueba, no todos llegan a esa etapa! Habitualmente es el 3%-13% del total que postuló.

Todas las pruebas que hacemos, analizan más que tu código, y solo algunos logran darse cuenta de ello. Añadimos algunos desafíos opcionales, que habitualmente nos indican quienes son los indicados, incluso si están incompletos o malos.

Si te interesa ver nuestras pruebas, están open source en nuestro Github:

Finalmente a casi todos los postulantes que hayan enviado su prueba les dejamos sugerencias, y si podemos, dejamos reviews en PRs con sugerencias o correcciones.

Esto nos motiva mucho, ya que si bien no contratamos a todos los postulantes, aprenden inclusive al no ser seleccionados 💪, lo cual valoran muchísimo! 🥰 Además, los tenemos en nuestro radar 👀.

Conclusiones

Postular no es fácil, y muchas veces pasa un largo periodo en donde logras quedar en algún empleo.

Recuerda que no tener experiencia laboral, o en alguna tecnología, no necesariamente es un excluyente, pero deberás demostrar con muchos más fundamentos tangibles porqué creer en ti.

Este último punto es muy relevante, ya que muchas veces los devs postulan al volumen y no a la calidad de la postulación. Evita responder por responder, si no te hace sentido no postules, evita respuestas cortas como "Sí", "No", "Talvez". Intenta fundamentar, siempre. Te debe nacer.

Si crees que no puedes demostrar al qué haz hecho y qué puedes hacer, prepárate mejor. Esto es como venderte tu mismo (los freelance los saben muy bien), no esperes a esa experiencia laboral/tecnológica, construyela tú mismo.

Finalmente aquí quisimos darte algunos consejos que pudiesen dar más chance de quedar, y por sobre todo cambiar tu forma de pensar al postular. Busca la manera de destacar con tangibilidad.

Éxito en tu próxima experiencia dev! 👏