Acá voy a escribir mi resumen de lo que para mí es muy valioso, NO lo hago para que te saltes el video, no. Míralo todo y más de una vez, por favor. 1. Para solucionar un problema debes saber qué es lo que pide la gente, un software nunca estará listo, siempre se puede mejorar. 3:12 2. Escribir el código es el último paso, antes de "resolverlo" en el teclado debes resolverlo en tu cabeza o en un papel. Tu capacidad de comprender qué se quiere y cómo puedes solucionarlo es clave, sea el nivel que tengas. 6:46 3. Comunica tus ideas, son potenciales soluciones, si ya hiciste algo o si no has hecho nada aún en programación, pero tienes conocimientos en otras cosas, opina, todo sirve en una lluvia de ideas. 8:08 4. Déjate ayudar, escucha feedback, pero no te dejes llevar por todo lo que te digan, ten criterio propio. Si sabes dos cositas más, sé humilde. 10:34 5. Por lo menos en la entrevista, habla de tu solución de lo que piensas lograr, mientras escribas código recuerda que todos, como tú, quieren que resuelvas el asunto, pero hasta el resolverlo pasa a segundo plano si demuestras que se pueden comunicar contigo mientras estás resolviendo, eso pasa en la vida real, así es que funciona. 12:48 6. Pregunta. Dicen por ahí que "es mejor ser ignorante por un minuto que serlo por toda la vida". Nadie nace sabiendo, nadie sabe lo que no sabe, no es como que en cierto nivel debes tener todas las respuestas, tal cosa no existe. 16:24 7. Acostúmbrate a escribir código limpio y claro. Por lo general, se trabaja en equipo, si nadie entiende tu código tendrás que estar explicándoselo, y si te pasa a ti, entonces todo se vuelve una pérdida de tiempo. Hay libros que te ayudan a escribir mejor código como el famoso "Clean Code". Además, siempre sé el mayor crítico de tu trabajo, como te dije al principio, siempre se puede mejorar lo que haces. 18:50 8. Bendito Síndrome del Impostor que nos recuerda que somos solo humanos que no lo sabemos todo. No tienes que demostrarle nada a nadie, solo haz lo mejor que puedas, estamos para resolver, no para saber todo. 21:17 9. Cometer errores está bien, antes de que algo sea perfecto debe ser imperfecto. Pero ojo, cometer errores está genial si es que aprendes de ellos. No se vale equivocarte 5 veces con lo mismo, sino aprendes. 22:50 10. Un desarrollador no escribe código, es solo una herramienta, un desarrollador da soluciones. Por eso no temas a la IA, mientras desarrolles tu capacidad resolutiva, todo estará bien. 25:41 Si llegaste hasta acá, bien por ti, eres de ese 1% que da el extra.
Buen dia. Estoy aprendiendo Desarrollo de Software. Han quitado de mi mente mitos y prejuicios acerca del mundo de IT en general. Creanme que he crecido con sus opiniones y nunca habia encontrado a alguien que dijera las cosas tan claras y transparentes. Hoy con tanto bootcamp que nos venden la idea de 3, 4 ó 6 meses son suficientes para volverse un experto. Tengo dificultades para consolidar mis conocimientos y aplicarlos, ¿qué consejo me darían para solidificarlos antes de iniciar a mi primer trabajo dentro de la industria? Saludos desde El Salvador
Muy Bueno, gracias por compartir sus conocimientos, entre por el apellido de Mariano (soy Simone también) y me encontré con un gran video, hace 40 años que participo de equipos de desarrollo y siempre le he dicho a mis circunstanciales colaboradores "antes de ponerte a hacer Magia, consúltame", lo que ustedes llaman con mas propiedad "Escalar el Problema".
Muy buena la entrevista, me inscribí a un curso de comunicación inmediatamente ya que entendí el valor y la importancia de la comunicación interpersonal, muchas gracias!
Excelente video para los que no nos animamos aún a entrar al mercado. Tengo bastantes conocimientos y estoy tratando de construir algunos proyectos para poder mostrar un poco para que empiecen a tenerme en cuenta. Los voy a empezar a seguir para ponerme a tono con lo que pide el mercado (Tengo 42 y soy de la vieja escuela y muchas cosas de hoy no las manejo). Saludos.
Lo que mencionan en la parte de evaluar candidatos es cierto, hace unos meses tuve el chance de tener una entrevista con Oracle, pasé a la técnica y la eché a perder totalmente justamente porque lo esperaban era antes de tirar código, explicar el problema para ver si lo había entendido y de ahí plantear una solución
Excelente entrevista para quienes estamos empezando y para quienes ya tienen experiencia, el como se vuelve un lider dentro de la empresa para quienes apenas estamos dando los primeros pasos
Vengo de trabajar en retail en el departamento de ventas , cara al público puro field y x tanto estudiado y trabajado unas excelentes formas de comunicación , negociación etc . Ahora estoy terminando una formación de desarrollo de aplicaciones multiplataforma y en unos meses saltaré al mercado laboral Si bien tengo cierto temor porque quizás no tengo la capacidad técnica que la experiencia y más estudio me irán dando no tengo ningún miedo y de hecho creo que mis habilidades de comunicación después de ver este vídeo me ayudarán a tener mejor chance para saber diferenciarme en una entrevista inicial , que ganas tengo de comprobarlo! ❤ mucha suerte a todos y que les vaya muy bien también , al final estamos juntos en este camino ❤
pues ya vas mejor que yo porque yo estoy en un estudio tecnico superior pero es justo lo inferior a la universidad asi que aprovecha y dale duro!@@saithomarvegacisneros4349
Yo recién entré a una empresa como Analista Desarrollador, Después me pasaron como Desarrollador Jr Llevo 7 meses trabajando Y a veces se me dificulta entender procesos ya que es un sistema demasiado robusto en cuanto a funcionalidad etc Yo como Junior podría dar de valor agregado: Sentido de urgencia, y no llevar siempre la contraria de las instrucciones que te dan, al igual que comunicar cuando estás atorado, ya que el tiempo vale 💲
Consejo. Crea diagramas de negocios o almenos un uml sequencial de los procesos que te explican. Ellos los apreciarán y tu tendrás una fuente fiable de dirección.
No sabia que Tony Stark hablaba español!... yo si decia que lo habia visto en algun lado jaja, no me maten por eso, buen video por cierto, nos ayuda un monto! muychas gracias!
Desde nuestro punto de vista es aquel que ya tiene una experiencia laboral trabajando en systemas funcionales a resolver un problema real por el cual alguien paga.
Yo soy analista de soporte , y me hacen desarrollar servicios windows , integraciones con apis como zoom , realizo la arquitectura y corrijo errores a las aplicaciones legacy ademas de ETL's con SSIS, programo en C# y Pyhton ademas tengo que proponer soluciones, creo que es hora de cambiar de empresa.
Cómo puedo saber donde estoy parado? Llevo 2 años programando solo, sin un equipo, haciendo crecer y manteniendo un sistema de escritorio desde cero, c#, sqlserver con interfaz HTML, Javascript, Bootstrap. Trato de aprender e implementar lo que se usa en la industria (SOLID, patrones de diseño, testing, arquitectura modular) pero al no tener nadie que vea lo que hago (a nivel codigo, diseño, etc), no tengo feedback o punto de comparación y me siento fuera de la industria
Minuto 5:35, comenta que un dev junior recien salido de universidad, bootcamp, etc viene con conceptos frescos de algoritmos o estructura de datos, y él como alguien experimentado todavia tiene que acordarse y es en eso lo que el dev junior puede darle valor. Wait, pero no es esto una contradiccion? Aqui él está declarando que algoritmos y estructura de datos No lo usa regularmente y es tanto asi que ni se acuerda. Y otra cosa, al comentar " vienen con conceptos frescos de algoritmos y estructura de datos", que yo sepa esos temas tienen mas de 20 años siendo lo mismo, no hay casi nada nuevo ahi.
El conocimiento técnico es necesario, por su puesto, pero escuchar a gente que ya está metida en la industria hace que me dé cuenta de lo importante que es la comunicación y las relaciones interpersonales dentro de una organización.
está bien preguntar y todo eso pero si uno puede terminar un requerimiento sin preguntar no lo veo nada malo al contrario terminas rápido tu requerimiento y te queda tiempo para apoyar al los demás del equipo para cerrar sus tareas.
Viernes 13 de Octubre: 10:00 am🇺🇸 USA (CST), 12:00 pm 🇦🇷 Argentina (GMT-3), 10:00 am 🇨🇴 Colombia (GMT-5) Pregúntame lo que quieras episodio 24 ¿Como hago para venderme en una entrevista de trabajo? En el vivo, respondo cualquier pregunta y también dedico los primeros minutos a responder ¿Como hago para venderme en una entrevista de trabajo?
Pero seria espectacular que cuando rechacen al ingeniero le digan: "Eres bueno, cuando hagas otra entrevista tecnica habla y pregunta durante el Living Code, ya que normalmente eso es lo que se hace el Live coding saber que tanto trabajas en equipo".
Yo me he capacitado mucho con cursos y demas y no he postulado en ningun lugar porque en todos lados piden de 1 a 3 años (minimo) de experiencia como Junior
Pero si eres junior yo creo que aporta con cosas básicas que te más tiempo de trabajar en algo más importante ósea te libras de responsabilidades mas sencilla y ahí es equipo, no sé si me explicó.
Aunque mas adelanta lo aclara, la definicion inicial de Senior es un poco sesgada porque aunque un buen senior esté en capacidad de encontrar los problemas, necesita o conocer muy bien la aplicacion o estar escuchando al equipo de soporte, y aun asi, el equipo de soporte es el que remite los problemas que identifica el usuario final. Asi que, el senior lo veo mas como mentor, arquitecto y alguien con experiencia en desarrollar bien las cosas para solucionar problemas y evitar que se propagen.
NO SE TOMEN ESTE VIDEO ENSERIO NI A ESTA GENTE, ES IMPOSIBLE, IMPOSIBLE ES INCLUSO HASTA RARO NO CONTRATAR A UNA PERSONA PORQUE NO COMUNICO BIEN EL LIVE CODING, POR QUE NO LO EXPLICO ... 1. Si no preguntas al entrevistador no te contratan. 2. Si haciendo el live coding preguntas probablemente pensaran que no sabes, tampoco te contratan. Si ven el conflicto? cuando vean un conflicto asi, huyan. Este tipo de cosas hacen aumentar la ansiedad, el burnout y el sindrome del impostor, es gente mala, con mucho ego HACIENDO ENTREVISTAS. Ser buen ingeniero es subjetivo, tiene muchas ramas, hay muchas cosas que se pueden saber y otras no, el pasar en una entrevista no requiere de esfuerzo, requiere de suerte, manipulación de ambos y de contactos y del desespero del entrevistador. OTRA COSA, nunca dan un feedback adecuado, es falso.
Desde mi punto de vista... que la persona que borra la base de datos de producción 3 veces es un problema, pero lo peor es creo que en algunos lugares no están dispuestos a ver que el protocolo de acciones o proceso que permite que eso pueda ocurrir... 😅 algunas veces estuve en empresas que durante los despliegues había mil maneras de meter la pata y se perdía mucho tiempo haciendo cosas a mano y se criticaba a aquellos que no lo hacían lo suficientemente rápido y otras en las que se intentaban automatizar todos los procesos repetitivos y se primaba el luego asegurarse o probar. Y bueno, "yatusabé"... competitividad con mal rollo elevado al infinito... síndrome del impostor en ciernes... gente callada... ambiente tóxico... Y ojo... porque alguna vez viví como el primer tipo de empresas intentaban aplicar lo segundo de una manera horrible no, lo siguiente. Supongo que se debía a que se pedían los cambios desde puestos de arriba porque vieron que otros lo hacían así o con tal o cual herramienta... y muchas veces no se dan cuenta que lo ideal es analizar bien que nos hace falta en cada caso y proyecto y no imponer cosas porque nos parecen mejores o a otros le han funcionado. La estandarización (como todo) tiene sus ventajas, pero también sus inconvenientes.
Tener el ecosistema correcto es fundamental para que las personas puedan desarrollarse exitosamente. Concuerdo que la mayoría de las veces el problema no es el problema sino el contexto más la estructura qué hay para el desempeño de las tareas.
Cómo les encanta las palabras y frases en ingles, quizás son demasiado vuelteros y todavía le meten el inglés para terminar de rematar la magia que le crean a todos los temas. Ganan haciendo fáciles las cosas che! Por favor el saber les debe facilitar el simplificar todos estos temas. Corten con la magia.
Menciona copilot y chatgpt y ya pienso que no tiene idea de lo que wue está hablando. Le vas a dar a un jr, que no sabe casi nada, la libretad de confiar en una herramienta que va a generar código que él no es capaz de determinar si es verdaderamente bueno?
No podés preguntarle a un JR en que te puede agregar valor, te estas burlando de esa persona, si el no sabe nada, recien empieza.. Su valor es la predisposición de aprender y la promesa de ayudar en algunas cosas.... Déjense de joder y de ser tan estrictos con las pruebas técnicas y las preguntas en las entrevistas que son un chiste las empresas IT en Latam.
@@Josue-cc9lb nada como la UNI y matemáticas o materias como física, fuera de allí a no ser que seas un genio vas a tener una formación muy muy limitada
@@HSebast419 Si tu sueño es hacer paginitas webs y aplicaciones moviles hasta que la ia te reemplace no, pero si quieres ser un verdadero ingeniero de software si necesitas matematicas
Mmmm.... creo que totalmente equivocado y acertado al mismo tiempo, muchas cosas que decís al comienzo no clasifican y diferencian a un Jr de un Senior... sino la experiencia en trabajo en equipo mas que otra cosa... mas de temas interpersonales que de código en si... lo siguiente también opino que equivocado y acertado... un Jr puede detectar una falla, y no saber como solucionarlo... por otro lado el ejemplo de que a un Jr le das el problema, le das la solución y esperas una ejecución y puede no saber llevarla a cabo a pesar de entender el problema y la solución... así como también hay algunos que tienen SRs de siglos (y he visto muchos) que aun así lo sacas de sus zonas de confort y no saben como hacer un código que sume 2+2 sin hacer una suma... y le das la misma tarea a uno que aprendió recién a encender la PC y te lo resuelve en 2 segundos aunque no sepa pasarlo a código o quizás si. Por ejemplo, me ha pasado que me pidan auditar una entrevista para el área de desarrollo y de rrhh siempre quieren patear a los que no tienen "experiencia laboral" y aun siendo su primer trabajo en IT saben más que un SR... y yo mismo he pedido varias veces que contraten muchos que no tenian "experiencia laboral" pero tenían mil proyectos hechos de 0 que eran geniales... y meses de trabajo y todo documentado... no tenían experiencia en lo laboral... pero si en código así también me ha pasado la inversa... entrevistar a un SR... y que hicieron 50 años de corrido FrontEnd... y solo sabían hacer HTML CSS y JS... a la antigüita ningun framework, o te dicen si se la base lo otro lo hago con los ojos cerrados... y cuando se topan con dificultades.... muchas veces son los primeros en salir corriendo de vuelta a su zona de confort... mientras que un JR se planta y sigue dándolo todo. PD.: de esos JR que he pedido contratar tengo la suerte de a día de hoy aun seguir trabajando con la mayoría y otros que se fueron y les va genial también después de muchos años.... así como también un par de SR que se rindieron a la primera y salieron corriendo y ahora están en trabajos que incluso se merecerían mínimo algo mejor Tema Universidad totalmente en desacuerdo, una persona autodidacta por ejemplo va a estar mil veces mas actualizado que alguien con un titulo... porque? simple lógica... para que el de la universidad aprenda, alguien le tiene que enseñar, para que ese le enseñe tuvo que aprender, y hasta que alguien es capaz de enseñar al menos "bien" algo... pasa tiempo, por lo cual en la universidad vas a ver algo que ya no se esta utilizando cuando te gradúes. y la experiencia es la diferencia a lo que preguntas... la experiencia no laboral.... sino la experiencia que haya adquirido de manera independiente (fuera del bootcamp, universidad o siendo autodidacta como decis..) la parte de la practica personal es mas importante que la experiencia laboral... por otro lado la comunicación no tiene nada que ver... en el equipo por ejemplo hay un chico con Autismo es muy difícil comunicarse con el, sin embargo, no utiliza IA ni nada y resuelve todo en un par de minutos...
Estás subvalorando a los Seniors, Mariano. Y para ambos, los actuales Seniors nos acostumbramos sólo a pedir información si no encontrábamos realmente la solución a una dificultad en sí. El estar preguntando constantemente causa el problema de "perezosidad" de cualquier programador. Considero que si se requiere exponer una solución, hay que hacerse cuando la solución ya está en ejecución. Hacer feedback instantáneo es como tener varios copilotos al mismo tiempo. Un buen programador es como un buen conductor; has probado conducir un automóvil con varios pasajeros diciéndote por dónde ir al mismo tiempo? Creo que con uno basta, y es el asistonto de código, en segunda instancia, la IA, y en tercero, trabajar con un humano cuando el diseño ya está planteado.
Nada se compara a despertar un domingo siendo Jr y descubrir esta joyita de canal ❤
Que bueno que te haya gustado! Gracias por el mensaje!
Continúa con muchos ánimos!
Acá voy a escribir mi resumen de lo que para mí es muy valioso, NO lo hago para que te saltes el video, no. Míralo todo y más de una vez, por favor.
1. Para solucionar un problema debes saber qué es lo que pide la gente, un software nunca estará listo, siempre se puede mejorar. 3:12
2. Escribir el código es el último paso, antes de "resolverlo" en el teclado debes resolverlo en tu cabeza o en un papel. Tu capacidad de comprender qué se quiere y cómo puedes solucionarlo es clave, sea el nivel que tengas. 6:46
3. Comunica tus ideas, son potenciales soluciones, si ya hiciste algo o si no has hecho nada aún en programación, pero tienes conocimientos en otras cosas, opina, todo sirve en una lluvia de ideas. 8:08
4. Déjate ayudar, escucha feedback, pero no te dejes llevar por todo lo que te digan, ten criterio propio. Si sabes dos cositas más, sé humilde. 10:34
5. Por lo menos en la entrevista, habla de tu solución de lo que piensas lograr, mientras escribas código recuerda que todos, como tú, quieren que resuelvas el asunto, pero hasta el resolverlo pasa a segundo plano si demuestras que se pueden comunicar contigo mientras estás resolviendo, eso pasa en la vida real, así es que funciona. 12:48
6. Pregunta. Dicen por ahí que "es mejor ser ignorante por un minuto que serlo por toda la vida". Nadie nace sabiendo, nadie sabe lo que no sabe, no es como que en cierto nivel debes tener todas las respuestas, tal cosa no existe. 16:24
7. Acostúmbrate a escribir código limpio y claro. Por lo general, se trabaja en equipo, si nadie entiende tu código tendrás que estar explicándoselo, y si te pasa a ti, entonces todo se vuelve una pérdida de tiempo. Hay libros que te ayudan a escribir mejor código como el famoso "Clean Code". Además, siempre sé el mayor crítico de tu trabajo, como te dije al principio, siempre se puede mejorar lo que haces. 18:50
8. Bendito Síndrome del Impostor que nos recuerda que somos solo humanos que no lo sabemos todo. No tienes que demostrarle nada a nadie, solo haz lo mejor que puedas, estamos para resolver, no para saber todo. 21:17
9. Cometer errores está bien, antes de que algo sea perfecto debe ser imperfecto. Pero ojo, cometer errores está genial si es que aprendes de ellos. No se vale equivocarte 5 veces con lo mismo, sino aprendes. 22:50
10. Un desarrollador no escribe código, es solo una herramienta, un desarrollador da soluciones. Por eso no temas a la IA, mientras desarrolles tu capacidad resolutiva, todo estará bien. 25:41
Si llegaste hasta acá, bien por ti, eres de ese 1% que da el extra.
Muchas gracias por tomarte el tiempo de hacer un resumen del video!
¡Muy bueno! Gracias por el contenido ¡Muy útil!
Gracias por tu comentario!
Excelente entrevista. Me llevo todo el conocimiento que pueda de esta. Saludos desde Valledupar-Colombia. Un suscriptor más. :)
Gracias Ivan! Saludos a Colombia!
un canal necesario gracias
Buen dia. Estoy aprendiendo Desarrollo de Software. Han quitado de mi mente mitos y prejuicios acerca del mundo de IT en general. Creanme que he crecido con sus opiniones y nunca habia encontrado a alguien que dijera las cosas tan claras y transparentes. Hoy con tanto bootcamp que nos venden la idea de 3, 4 ó 6 meses son suficientes para volverse un experto.
Tengo dificultades para consolidar mis conocimientos y aplicarlos, ¿qué consejo me darían para solidificarlos antes de iniciar a mi primer trabajo dentro de la industria? Saludos desde El Salvador
Muy Bueno, gracias por compartir sus conocimientos, entre por el apellido de Mariano (soy Simone también) y me encontré con un gran video, hace 40 años que participo de equipos de desarrollo y siempre le he dicho a mis circunstanciales colaboradores "antes de ponerte a hacer Magia, consúltame", lo que ustedes llaman con mas propiedad "Escalar el Problema".
Gracias por dejarnos tu comentario Marcelo!
Muy buena la entrevista, me inscribí a un curso de comunicación inmediatamente ya que entendí el valor y la importancia de la comunicación interpersonal, muchas gracias!
La comunicacion es clave. Que bueno que te gusto la entrevista!
Excelente video para los que no nos animamos aún a entrar al mercado. Tengo bastantes conocimientos y estoy tratando de construir algunos proyectos para poder mostrar un poco para que empiecen a tenerme en cuenta. Los voy a empezar a seguir para ponerme a tono con lo que pide el mercado (Tengo 42 y soy de la vieja escuela y muchas cosas de hoy no las manejo). Saludos.
Exitos! hay que animarse y darle para adelante.
tremendo contenido como siempre Pitcheers!!!
Muchas gracias!
05/07/2024 Explosiva información, gracias! Suscripto desde ya!
Estudiante de Desarrollo de Software en: ITU
Universidad de Cuyo Mendoza.
Que bueno que sirvio!
Que buen contenido. Muy bueno para las personas que estamos en buscar de nuestro primer trabajo. Sigan así
Muchas gracias!
Gracias por la información.
A la orden
Lo que mencionan en la parte de evaluar candidatos es cierto, hace unos meses tuve el chance de tener una entrevista con Oracle, pasé a la técnica y la eché a perder totalmente justamente porque lo esperaban era antes de tirar código, explicar el problema para ver si lo había entendido y de ahí plantear una solución
Gracias por compartir tu experiencia!
Muy buena entrevista y contenido! Nuevo suscriptor
Muchas gracias por sumarte!
Excelente entrevista para quienes estamos empezando y para quienes ya tienen experiencia, el como se vuelve un lider dentro de la empresa para quienes apenas estamos dando los primeros pasos
Muchas gracias! Que bueno que ayude tanto.
Gracias por el vídeo
Estoy estudiando Análisis y Desarrollo de Software y está info es muy importante para mí aprendizaje 😃
Que bueno que ayuda. Muchas gracias por el mensaje!
Muy buen canal ! Tome su like y suscripccion
Muchas gracias!
Excelente entrevista, muy instructiva!
Que bueno que gusto. Muchas gracias!
buena entrevista, estoy en la carrera de ingeniería en software y me gustó bastante el contenido
Que bueno que te gusto! Gracias por el mensaje!
Excelente la entrevista! Gracias por este aporte.
Con mucho gusto!
Gracias por este aporte. Me resulta muy útil.
Genial! Con mucho gusto!
Excelente la entrevista!
Que bueno que gusto!
Vengo de trabajar en retail en el departamento de ventas , cara al público puro field y x tanto estudiado y trabajado unas excelentes formas de comunicación , negociación etc . Ahora estoy terminando una formación de desarrollo de aplicaciones multiplataforma y en unos meses saltaré al mercado laboral
Si bien tengo cierto temor porque quizás no tengo la capacidad técnica que la experiencia y más estudio me irán dando no tengo ningún miedo y de hecho creo que mis habilidades de comunicación después de ver este vídeo me ayudarán a tener mejor chance para saber diferenciarme en una entrevista inicial , que ganas tengo de comprobarlo! ❤ mucha suerte a todos y que les vaya muy bien también , al final estamos juntos en este camino ❤
Exitos en este nuevo camino!
Yo también estoy en el área de ventas!! Ya me falta poco para terminar la universidad y la idea es tirarle desarrollo multiplataforma con flutter!
Como junior te ayuda mucho eso. Si mostrás ganas de aprender y tenes buena comunicación, la entrevista puede salir buena aunque falles el ejercicio.
pues ya vas mejor que yo porque yo estoy en un estudio tecnico superior pero es justo lo inferior a la universidad asi que aprovecha y dale duro!@@saithomarvegacisneros4349
muchas gracias por el animo! a ver si todo sale bien les iré contando@@king-manu2758
Yo recién entré a una empresa como Analista Desarrollador, Después me pasaron como Desarrollador Jr
Llevo 7 meses trabajando
Y a veces se me dificulta entender procesos ya que es un sistema demasiado robusto en cuanto a funcionalidad etc
Yo como Junior podría dar de valor agregado: Sentido de urgencia, y no llevar siempre la contraria de las instrucciones que te dan, al igual que comunicar cuando estás atorado, ya que el tiempo vale 💲
100% todo lo que decis. Querer escuchar y aprender ya es muchisimo valor.
Consejo. Crea diagramas de negocios o almenos un uml sequencial de los procesos que te explican. Ellos los apreciarán y tu tendrás una fuente fiable de dirección.
gran aporte
Que bueno que sirve,
No sabia que Tony Stark hablaba español!... yo si decia que lo habia visto en algun lado jaja, no me maten por eso, buen video por cierto, nos ayuda un monto! muychas gracias!
jaja. Que bueno que ayuda el video!
Amazing 🔥🔥
Me gusto la charla muy informativa, un jr advance en que categoría entraría?
Desde nuestro punto de vista es aquel que ya tiene una experiencia laboral trabajando en systemas funcionales a resolver un problema real por el cual alguien paga.
Thanks!
Welcome!
Yo soy analista de soporte , y me hacen desarrollar servicios windows , integraciones con apis como zoom , realizo la arquitectura y corrijo errores a las aplicaciones legacy ademas de ETL's con SSIS, programo en C# y Pyhton ademas tengo que proponer soluciones, creo que es hora de cambiar de empresa.
Siempre es bueno salir a ver cuanto uno vale en el mercado en vida real.
Y los manager? tanto como Scrum Master o Project Manager o Product Owner?
Ya vamos a hacer un video para estos roles! Gracias por el comentario.
Tengo quince años y llevo mas de un año aprendiendo programación.
Vas a llegar muy bien preparado!
Me cambiaste el chip. Yo creia que las cosas eras distintas. Gracias.
💪🙂
Cómo puedo saber donde estoy parado? Llevo 2 años programando solo, sin un equipo, haciendo crecer y manteniendo un sistema de escritorio desde cero, c#, sqlserver con interfaz HTML, Javascript, Bootstrap. Trato de aprender e implementar lo que se usa en la industria (SOLID, patrones de diseño, testing, arquitectura modular) pero al no tener nadie que vea lo que hago (a nivel codigo, diseño, etc), no tengo feedback o punto de comparación y me siento fuera de la industria
Minuto 5:35, comenta que un dev junior recien salido de universidad, bootcamp, etc viene con conceptos frescos de algoritmos o estructura de datos, y él como alguien experimentado todavia tiene que acordarse y es en eso lo que el dev junior puede darle valor. Wait, pero no es esto una contradiccion? Aqui él está declarando que algoritmos y estructura de datos No lo usa regularmente y es tanto asi que ni se acuerda.
Y otra cosa, al comentar " vienen con conceptos frescos de algoritmos y estructura de datos", que yo sepa esos temas tienen mas de 20 años siendo lo mismo, no hay casi nada nuevo ahi.
Gracias por tu mensaje! Cual es tu opinion sobre tener conocimiento de algoritmos y estructura de datos? Es necesario para un junior?
El conocimiento técnico es necesario, por su puesto, pero escuchar a gente que ya está metida en la industria hace que me dé cuenta de lo importante que es la comunicación y las relaciones interpersonales dentro de una organización.
Exacto! El conocimiento tecnico es la base. Las habilidades de comunicacion es lo que te potencia.
interesante... a m me gustaria trabajar en una fintech,,, pero vengo de seguros y me ha costado moverme de industria
Born Senior
Nadie es mejor wue nadie
Estoy de acuerdo. Hay que formar un equipo y cada persona es clave en su rol.
está bien preguntar y todo eso pero si uno puede terminar un requerimiento sin preguntar no lo veo nada malo al contrario terminas rápido tu requerimiento y te queda tiempo para apoyar al los demás del equipo para cerrar sus tareas.
Viernes 13 de Octubre: 10:00 am🇺🇸 USA (CST), 12:00 pm 🇦🇷 Argentina (GMT-3), 10:00 am 🇨🇴 Colombia (GMT-5)
Pregúntame lo que quieras episodio 24 ¿Como hago para venderme en una entrevista de trabajo?
En el vivo, respondo cualquier pregunta y también dedico los primeros minutos a responder ¿Como hago para venderme en una entrevista de trabajo?
Pero seria espectacular que cuando rechacen al ingeniero le digan:
"Eres bueno, cuando hagas otra entrevista tecnica habla y pregunta durante el Living Code, ya que normalmente eso es lo que se hace el Live coding saber que tanto trabajas en equipo".
Definitivamente de acuerdo. Hay que comunicar cual es el objetivo de la entrevista y como es el formato.
Yo me he capacitado mucho con cursos y demas y no he postulado en ningun lugar porque en todos lados piden de 1 a 3 años (minimo) de experiencia como Junior
Pero si eres junior yo creo que aporta con cosas básicas que te más tiempo de trabajar en algo más importante ósea te libras de responsabilidades mas sencilla y ahí es equipo, no sé si me explicó.
El trabajo en equipo es todo!
Aunque mas adelanta lo aclara, la definicion inicial de Senior es un poco sesgada porque aunque un buen senior esté en capacidad de encontrar los problemas, necesita o conocer muy bien la aplicacion o estar escuchando al equipo de soporte, y aun asi, el equipo de soporte es el que remite los problemas que identifica el usuario final. Asi que, el senior lo veo mas como mentor, arquitecto y alguien con experiencia en desarrollar bien las cosas para solucionar problemas y evitar que se propagen.
Muchas gracias por tu comentario Josue!
NO SE TOMEN ESTE VIDEO ENSERIO NI A ESTA GENTE, ES IMPOSIBLE, IMPOSIBLE ES INCLUSO HASTA RARO NO CONTRATAR A UNA PERSONA PORQUE NO COMUNICO BIEN EL LIVE CODING, POR QUE NO LO EXPLICO ...
1. Si no preguntas al entrevistador no te contratan.
2. Si haciendo el live coding preguntas probablemente pensaran que no sabes, tampoco te contratan.
Si ven el conflicto? cuando vean un conflicto asi, huyan. Este tipo de cosas hacen aumentar la ansiedad, el burnout y el sindrome del impostor, es gente mala, con mucho ego HACIENDO ENTREVISTAS.
Ser buen ingeniero es subjetivo, tiene muchas ramas, hay muchas cosas que se pueden saber y otras no, el pasar en una entrevista no requiere de esfuerzo, requiere de suerte, manipulación de ambos y de contactos y del desespero del entrevistador. OTRA COSA, nunca dan un feedback adecuado, es falso.
no sabia que era un senior 😀
Eso!
Desde mi punto de vista... que la persona que borra la base de datos de producción 3 veces es un problema, pero lo peor es creo que en algunos lugares no están dispuestos a ver que el protocolo de acciones o proceso que permite que eso pueda ocurrir... 😅 algunas veces estuve en empresas que durante los despliegues había mil maneras de meter la pata y se perdía mucho tiempo haciendo cosas a mano y se criticaba a aquellos que no lo hacían lo suficientemente rápido y otras en las que se intentaban automatizar todos los procesos repetitivos y se primaba el luego asegurarse o probar. Y bueno, "yatusabé"... competitividad con mal rollo elevado al infinito... síndrome del impostor en ciernes... gente callada... ambiente tóxico... Y ojo... porque alguna vez viví como el primer tipo de empresas intentaban aplicar lo segundo de una manera horrible no, lo siguiente. Supongo que se debía a que se pedían los cambios desde puestos de arriba porque vieron que otros lo hacían así o con tal o cual herramienta... y muchas veces no se dan cuenta que lo ideal es analizar bien que nos hace falta en cada caso y proyecto y no imponer cosas porque nos parecen mejores o a otros le han funcionado. La estandarización (como todo) tiene sus ventajas, pero también sus inconvenientes.
Tener el ecosistema correcto es fundamental para que las personas puedan desarrollarse exitosamente. Concuerdo que la mayoría de las veces el problema no es el problema sino el contexto más la estructura qué hay para el desempeño de las tareas.
habrá algo más allá del sr?
Cómo les encanta las palabras y frases en ingles, quizás son demasiado vuelteros y todavía le meten el inglés para terminar de rematar la magia que le crean a todos los temas.
Ganan haciendo fáciles las cosas che! Por favor el saber les debe facilitar el simplificar todos estos temas. Corten con la magia.
tal cual bro, u r right!
Ah, sos telemarketer....
ruclips.net/video/jkdXy6D8kCk/видео.html
🤣
Gran comercial!
Menciona copilot y chatgpt y ya pienso que no tiene idea de lo que wue está hablando.
Le vas a dar a un jr, que no sabe casi nada, la libretad de confiar en una herramienta que va a generar código que él no es capaz de determinar si es verdaderamente bueno?
que todavía tienen jale camaradas ggg...
esqueleto de nacho libre
No podés preguntarle a un JR en que te puede agregar valor, te estas burlando de esa persona, si el no sabe nada, recien empieza.. Su valor es la predisposición de aprender y la promesa de ayudar en algunas cosas.... Déjense de joder y de ser tan estrictos con las pruebas técnicas y las preguntas en las entrevistas que son un chiste las empresas IT en Latam.
Todo es problema y solución, nada que ver con seniority. Solo es ego.
Encontrar el problema correcto y la solucion correcta es todo!
Demostrado, estudien a sus entrevistadores y denles lo que quieren, así de fácil ingresan a trabajas a cualquier empresa 😅😅😅
vayan a la U y estudien mucha mate xd, es la forma real de desarrollar un pensamiento que gane al resto
Mientras mas se estudie, mejor.
Lo dices para desarrollar pensamiento abstracto ? , Si es así, se puede desarrollar de varias formas
@@Josue-cc9lb nada como la UNI y matemáticas o materias como física, fuera de allí a no ser que seas un genio vas a tener una formación muy muy limitada
pero no se necesita tantas mates para programar
@@HSebast419 Si tu sueño es hacer paginitas webs y aplicaciones moviles hasta que la ia te reemplace no, pero si quieres ser un verdadero ingeniero de software si necesitas matematicas
Mmmm.... creo que totalmente equivocado y acertado al mismo tiempo, muchas cosas que decís al comienzo no clasifican y diferencian a un Jr de un Senior... sino la experiencia en trabajo en equipo mas que otra cosa... mas de temas interpersonales que de código en si...
lo siguiente también opino que equivocado y acertado... un Jr puede detectar una falla, y no saber como solucionarlo... por otro lado el ejemplo de que a un Jr le das el problema, le das la solución y esperas una ejecución y puede no saber llevarla a cabo a pesar de entender el problema y la solución... así como también hay algunos que tienen SRs de siglos (y he visto muchos) que aun así lo sacas de sus zonas de confort y no saben como hacer un código que sume 2+2 sin hacer una suma... y le das la misma tarea a uno que aprendió recién a encender la PC y te lo resuelve en 2 segundos aunque no sepa pasarlo a código o quizás si.
Por ejemplo, me ha pasado que me pidan auditar una entrevista para el área de desarrollo y de rrhh siempre quieren patear a los que no tienen "experiencia laboral" y aun siendo su primer trabajo en IT saben más que un SR... y yo mismo he pedido varias veces que contraten muchos que no tenian "experiencia laboral" pero tenían mil proyectos hechos de 0 que eran geniales... y meses de trabajo y todo documentado... no tenían experiencia en lo laboral... pero si en código
así también me ha pasado la inversa... entrevistar a un SR... y que hicieron 50 años de corrido FrontEnd... y solo sabían hacer HTML CSS y JS... a la antigüita ningun framework, o te dicen si se la base lo otro lo hago con los ojos cerrados... y cuando se topan con dificultades.... muchas veces son los primeros en salir corriendo de vuelta a su zona de confort... mientras que un JR se planta y sigue dándolo todo.
PD.: de esos JR que he pedido contratar tengo la suerte de a día de hoy aun seguir trabajando con la mayoría y otros que se fueron y les va genial también después de muchos años....
así como también un par de SR que se rindieron a la primera y salieron corriendo y ahora están en trabajos que incluso se merecerían mínimo algo mejor
Tema Universidad totalmente en desacuerdo, una persona autodidacta por ejemplo va a estar mil veces mas actualizado que alguien con un titulo... porque?
simple lógica... para que el de la universidad aprenda, alguien le tiene que enseñar, para que ese le enseñe tuvo que aprender, y hasta que alguien es capaz de enseñar al menos "bien" algo... pasa tiempo, por lo cual en la universidad vas a ver algo que ya no se esta utilizando cuando te gradúes. y la experiencia es la diferencia a lo que preguntas... la experiencia no laboral.... sino la experiencia que haya adquirido de manera independiente (fuera del bootcamp, universidad o siendo autodidacta como decis..) la parte de la practica personal es mas importante que la experiencia laboral... por otro lado la comunicación no tiene nada que ver... en el equipo por ejemplo hay un chico con Autismo es muy difícil comunicarse con el, sin embargo, no utiliza IA ni nada y resuelve todo en un par de minutos...
Muchas gracias por analizar todos los puntos y dejarnos tus comentarios. Todo lo que agregaste es muy interesante y de valor.
Estás subvalorando a los Seniors, Mariano. Y para ambos, los actuales Seniors nos acostumbramos sólo a pedir información si no encontrábamos realmente la solución a una dificultad en sí. El estar preguntando constantemente causa el problema de "perezosidad" de cualquier programador. Considero que si se requiere exponer una solución, hay que hacerse cuando la solución ya está en ejecución. Hacer feedback instantáneo es como tener varios copilotos al mismo tiempo. Un buen programador es como un buen conductor; has probado conducir un automóvil con varios pasajeros diciéndote por dónde ir al mismo tiempo? Creo que con uno basta, y es el asistonto de código, en segunda instancia, la IA, y en tercero, trabajar con un humano cuando el diseño ya está planteado.
Infravalorando.