Preparándose para el Éxito: Guía de un Ingeniero de Frontend para la Diligencia Técnica

Rate this content
Bookmark
Slides

Imagina ser un caballero preparándose para un torneo de justas, pero tu caballo está más interesado en las pacas de heno de la feria que en tu duelo inminente. Eso es lo que a veces puede sentirse al preparar tu departamento de tecnología para una ronda de inversión o una salida. Esta charla proporciona una mirada en profundidad al papel de un ingeniero de frontend, especialmente trabajando con React, en la preparación de un departamento de tecnología para una ronda de inversión o una salida. A través de una lente única de diligencia técnica, la presentación descubre la importancia de las buenas prácticas, la arquitectura sólida, la documentación eficiente y más.

32 min
08 Dec, 2023

AI Generated Video Summary

La diligencia técnica es un examen exhaustivo que puede influir en el futuro de un producto o empresa, e implica analizar la arquitectura técnica, la base de código, la cultura del equipo y más. Los ingenieros de frontend juegan un papel crucial en el puente entre el diseño y la funcionalidad. La automatización, la infraestructura y la documentación son áreas clave en la diligencia técnica. Las mejores prácticas, el código limpio y las conexiones de mercado son importantes para la venta. La diligencia técnica requiere acceso a datos y medidas de seguridad, y las empresas pueden ser reacias a cooperar plenamente.

1. Introducción a la Due Diligencia Tecnológica

Short description:

Antes de sumergirnos en el mundo de la due diligence tecnológica, permíteme compartir un poco sobre quién soy y mi experiencia en ingeniería frontend. Nuestro papel en Tech Miners es guiar y elevar a las empresas a través de la due diligence tecnológica basada en datos. Nos familiarizaremos con los aspectos esenciales de la due diligence tecnológica y proporcionaremos ideas prácticas sobre cómo prepararse para el proceso.

Muy bien. Antes de sumergirnos en el mundo de la due diligence tecnológica, permíteme compartir un poco sobre quién soy y mi experiencia en el ámbito de la ingeniería frontend. Y no te preocupes, planeo mantener las cosas ligeras. Un agradable cambio de ritmo de las charlas más técnicas a las que podrías estar acostumbrado durante el Día de React en Berlín. Así que empecemos. Mi nombre es Armin. A lo largo de los años, he trabajado en varios proyectos, utilizando React extensivamente, y he visto de primera mano cómo las decisiones que tomamos como ingenieros frontend pueden dar forma a la trayectoria de un producto, equipo, o incluso de toda la empresa. Así que pasemos a la imagen más grande aquí. ¿Qué nos impulsa en Tech Miners y cómo sienta las bases para nuestra charla de hoy? En Tech Miners, nuestro papel no es solo evaluar, sino guiar y elevar. Nuestro enfoque único de la due diligence tecnológica es data-driven, profundizando en procesos, personas y tecnología. Hemos ayudado a innumerables empresas a prepararse para hitos significativos, desde rondas de inversión hasta salidas. Pero toda esta charla sobre la due diligence tecnológica podría hacerte preguntarte, ¿qué es realmente? Así que vamos a desmitificar eso. Nuestra presentación de hoy está estructurada en dos segmentos principales. Primero, nos familiarizaremos con los aspectos esenciales de la due diligence tecnológica, qué es y por qué es tan importante en nuestro papel, en nuestro campo. Después de eso, profundizaremos en algunas ideas prácticas sobre cómo podemos prepararnos de manera efectiva

2. Resumen de la Due Diligence Tecnológica

Short description:

Al final de nuestra charla, espero que comprendas mejor la due diligence tecnológica y tengas ideas para mejorar tu trabajo. La due diligence tecnológica es un examen exhaustivo que puede influir en el futuro de un producto o empresa. Es fundamental para los inversores entender la robustez y escalabilidad de la tecnología. El proceso implica analizar la arquitectura técnica, la base de código, la cultura del equipo, la escalabilidad del producto, la pila tecnológica, los activos tecnológicos, la gestión del producto, la hoja de ruta de desarrollo y la sección legal/PI. El resultado es un informe detallado que identifica fortalezas, debilidades, oportunidades y riesgos. Las señales de alerta indican problemas graves que pueden afectar las operaciones tecnológicas de una empresa y el éxito empresarial.

para tal proceso. Así que al final de nuestra charla, espero que no solo comprendas mejor la due diligence tecnológica, sino que también tengas algunas ideas sobre cómo mejorar tu trabajo, ya sea tu equipo o tu producto. Así que antes de empezar, quiero hacerte una pregunta aquí. Levanta la mano si ya estás familiarizado con lo que es la due diligence tecnológica. Bien, ¿cinco, seis quizás? Eso está bastante bien. Para eso estoy aquí. Así que no te preocupes. Lo esperaba. La verdad es que, en el acelerado mundo del desarrollo de software, ya seas parte de una startup ágil, ansiosa por su primera ronda de financiación, o un jugador clave en una empresa tecnológica bien establecida, considerándola una adquisición estratégica, el concepto de due diligence tecnológica es uno que es muy probable que encuentres en algún momento de tu career. Tenemos varias forms de due diligence, pero hoy nuestro foco está en TechDD, que nos involucra directamente como ingenieros de software.

Así que la due diligence tecnológica no es solo una casilla para marcar. Es un examen exhaustivo que puede influir en la dirección futura de un producto o de toda la empresa. Por supuesto, por otro lado, también es bastante crítico para los inversores, los stakeholders y los posibles compradores entender la robustez técnica, la scalability, y la prueba de futuro de la tecnología que sustenta la empresa que realmente les interesa. Un robusto, digamos, TechDD implica varios pasos clave, desde comenzar con una sesión de inicio para definir los alcances y objetivos, hasta el análisis exhaustivo de la architecture técnica y la base de código. El proceso se suele extender durante unas pocas semanas para asegurar un análisis en profundidad sin interrumpir significativamente las operaciones diarias de la empresa. Las áreas que se explorarán durante un TechDD son el equipo técnico, la cultura del equipo, de los cuales estamos aquí, la scalability del producto, la pila tecnológica, por supuesto, qué frameworks están usando, lenguajes, elección de herramientas. Los activos tecnológicos, que es básicamente donde obtenemos acceso a los data, obtenemos la mayor cantidad de data posible que podemos, y procesamos para extraer algunos insights. Gestión del producto, hoja de ruta de desarrollo del producto, quizás también incluso un análisis competitivo. Y por último, la sección legal y de PI, que podría ser bastante crítica para empresas quizás en el sector de la ciberseguridad o del seguro, digamos.

El resultado de un TechDD es un informe detallado que proporciona insights sobre la salud técnica de una empresa. Identifica fortalezas, debilidades, oportunidades de mejora, y riesgos potenciales. Los hallazgos son casi el elemento más importante de cualquier informe de TechDD. En este contexto, un hallazgo se refiere a una pieza de información significativa que se ha descubierto durante el proceso de TechDD. Cada hallazgo es impulsado por data y a menudo está respaldado por ayudas visuales como gráficos para una mejor comprensión. Miran diferentes cosas, como cuán serio es un problema, o si podría resolverse fácilmente. Este enfoque, por supuesto, nos ayuda a clasificar qué problemas son importantes y cuáles no, y a detectar cualquier preocupación importante o señales de alerta. Las señales de alerta en la due diligence tecnológica son esencialmente una combinación de problemas o hallazgos que señalan problemas potencialmente graves con la estrategia tecnológica de una empresa o su implementación. Las señales de alerta no son solo algunas alertas simples. Se evalúan en función de cuán fácilmente se pueden solucionar, la cantidad de esfuerzo y recursos necesarios para abordar el problema, y la duración estimada para resolver el problema. Aunque no es, diría yo, aunque no es relativamente frecuente que cualquier empresa que se someta a un TechDD tenga una señal de alerta, tener una señal de alerta es algo de lo que definitivamente hay que preocuparse, porque podrían afectar significativamente las operaciones tecnológicas de una empresa, y por extensión, su éxito empresarial. Ahora que hemos entendido el concepto de TechDD, te preguntarás, ¿dónde encajo yo, como ingeniero de software, en esta imagen?

3. Ingenieros de Front-end y Preparación para la TechDD

Short description:

Los ingenieros de front-end juegan un papel crucial en el puente entre el diseño y la funcionalidad. Para prepararse para la TechDD, familiarízate con el proceso y comprende la importancia de la infraestructura de código. Los ejemplos del mundo real proporcionarán información sobre problemas comunes. Recuerda que las señales de alerta y los hallazgos son relativos. Ahora, vamos a profundizar en el área crítica de las dependencias y las licencias, donde el código abierto no siempre significa uso sin restricciones. Comprender la licencia y el mantenimiento es esencial.

Así que vamos a desentrañar eso. Los ingenieros de front-end, como muchos de nosotros aquí, son el puente entre design y funcionalidad. Nuestro papel es fundamental, pero ¿cómo se entrelaza con la TechDD? Todos ustedes están como, como si ser un ingeniero de software ya no fuera como un paseo por el parque, codificación sin fin, mantenerse al día con la pila siempre cambiante, como estoy hablando de dos grandes lanzamientos de Next, supongo, cada seis meses, ¿verdad? Sí, ya estás familiarizado con eso. Pero no te preocupes. En realidad no necesitas hacer demasiado extra para estar preparado para una TechDD. Eso es, por supuesto, si ya estás haciendo las cosas bien. Así que vamos a la parte de cómo prepararse. La preparación es la clave del éxito en casi todos los empeños. En el ámbito de la TechDD, nuestra infraestructura de código sienta las bases. Los ejemplos que vamos a explorar en los próximos minutos son algunos de los problemas más significativos o comúnmente pasados por alto basados en nuestra experiencia de la TechDD del mundo real. Creo que este enfoque nos ayudará a obtener una mejor comprensión de cómo se ve esto en la práctica y cómo pueden impactar en el entorno tecnológico. Sin embargo, es crucial recordar que las señales de alerta y los hallazgos son altamente relativos. El mismo problema o hallazgo podría ser en la situación de una empresa un gran problema, un caso enorme, pero el mismo problema podría ser como nada realmente importante, por supuesto, de nuevo, basado en la situación de la empresa. Así que por eso cada situación exige una respuesta personalizada, considerando las características y necesidades únicas de la empresa. Así que vamos a prepararnos. La primera parte de la preparación para cualquier cosa es conocer la cosa en sí. Aquí tampoco hay excepción. Afortunadamente, ya estamos familiarizados con los aspectos esenciales de la TechDD, como sus pasos, objetivos y lo que busca. Así que el primer paso ya está hecho. No fue difícil, ¿verdad? Así que hasta aquí, un rápido resumen. Hacemos TechDD. Aprendes qué es TechDD. Ahora vamos a ver algunos ejemplos del mundo real de nuestras TechDDs, y eso nos ayudará a prepararnos mejor para tal proceso, o en general a mejorar en eso. Ahora, vamos a profundizar en nuestra primera sección, dependencias y licencias. Esta es un área crítica en la TechDD, especialmente para los productos SaaS. Lo importante aquí es recordar que open-source no siempre equivale a libre de usar sin ninguna restricción. Malinterpretar esto puede llevar a riesgos legales significativos y potencialmente convertirse en una señal de alerta por sí sola. Eso fue un poco de retraso. Muy bien. Así que no se trata sólo de usarlos. Se trata de entender la licencia, de llevar un seguimiento

4. Ejemplo de TechDD, Automatización y Documentación

Short description:

Considera un escenario en el que más del 40% de las dependencias de un proyecto requieren actualizaciones importantes. Este gráfico no solo señala posibles riesgos de seguridad, sino que también indica la necesidad de que el equipo de desarrollo mejore sus procesos de monitoreo y actualización. La elección de las licencias de código abierto requiere una cuidadosa consideración. Dirijamos nuestra atención a la automatización y la infraestructura. El monitoreo, la automatización de licencias y los ganchos pre-commit son cruciales. Se esperan deficiencias, pero los problemas insolubles en el futuro son una preocupación. Una documentación completa y accesible, especialmente el material de incorporación técnica, es esencial.

de sus actualizaciones, y conociendo su estado de mantenimiento. De hecho, vamos a tener un ejemplo aquí. Considera un escenario en el que más del 40% de las dependencias de un proyecto requieren actualizaciones importantes. ¿Qué nos dice este gráfico? Si lo ves, es como si este gráfico no solo señalara el potencial riesgo de security dentro de un producto, mientras tenemos como más del 40% de las bibliotecas que necesitan actualizaciones importantes, sino que también indica la necesidad de que el equipo de desarrollo mejore sus procesos de monitoreo y actualización. Además, la elección de ciertas licencias open-source requiere una cuidadosa consideración. Eso es porque usar algunas licencias sin una razón sólida puede ser arriesgado, afectando potencialmente las operaciones y cumplimientos del negocio. Así que nosotros vigilamos esa parte. Todos podríamos saber acerca de la licencia MIT, que usamos a diario, pero es definitivamente útil conocer algunas otras licencias open-source y sus implicaciones, Avanzando en nuestra serie de Cómo Prepararse para la Compra, ahora vamos a centrar nuestra atención en la automation y la infraestructura. El objetivo aquí es casi claro, como automatizar tanto como sea posible. Los beneficios de la automation en la tecnología son bien conocidos por todos nosotros. Eficiencia, consistencia, scalability. Sin embargo, hay ciertos aspectos que pueden levantar banderas rojas. Primero, hablemos sobre el monitoreo. ¿El enfoque de la empresa es reactivo o proactivo? ¿Tienen sistemas de mensajería en tiempo real en su lugar para notificarles inmediatamente de los problemas? Porque esto es, por supuesto, realmente crucial para las respuestas oportunas a los problemas, ¿verdad? Volviendo a las licencias, automatizar el monitoreo de licencias es definitivamente una jugada inteligente. Eso es porque las licencias no cambiarán, pero pueden cambiar durante el tiempo, y el cambio en realidad puede afectar nuestro producto realmente muy fuertemente. Así que tengamos eso en mente. Algunos puertos parecen podrían estar implementando ganchos pre-commit en los pipelines. Esto puede prevenir muchos problemas al asegurar que el código cumple con ciertos standards antes de que se fusione. Por último aquí, veo que es importante mencionar que en un proceso de tech D.D., algunas deficiencias son totalmente esperadas y aceptables, por supuesto dependiendo de la situación de la empresa. Pero lo que importa, no es no tener ningún problema. Es no tener problemas insolubles en el futuro. Curiosamente, si una startup parece demasiado perfecta, ella misma podría convertirse también en una bandera roja. Ahora vamos a cambiar nuestro enfoque a la documentation. Este viejo dicho captura perfectamente la importancia a menudo pasada por alto de una documentation completa y accesible en los procesos tecnológicos. ¿Cuántos de nosotros aquí preferimos escribir código que documentation? Manos arriba. Véase, todos estamos de acuerdo con eso. Esto a menudo lleva a un escenario en el que en las startups, la documentation puede ser casi inexistente, lo cual es aceptable en algunos casos. Pero sorprendentemente, incluso en empresas más grandes, no es raro en absoluto encontrar lagunas significativas en los documentos técnicos. Diría, uno de los tipos de documentación más críticos es el material de incorporación técnica. Considerando cuán frecuentemente las startups cambian sus equipos, es ideal que un documento de incorporación sea lo suficientemente completo para que un nuevo ingeniero pueda empezar a contribuir de manera significativa

5. Documentación, Frameworks y Calidad del Código

Short description:

Aunque herramientas como Google Drive y Google Docs tienen su lugar, se quedan cortas en términos de capacidad de búsqueda e indexación. La documentación debe ser centralizada para la accesibilidad y disponibilidad del conocimiento. La elección de frameworks y herramientas requiere decisiones informadas basadas en razones justificables y en la consideración de los costos de mantenimiento. La calidad del código depende de la consistencia, herramientas automatizadas como ESLint, y evitar valores y configuraciones codificados para la seguridad y mantenibilidad.

a un producto dentro del primer mes o dos. Una trampa común es el uso excesivo de herramientas generales como Google Docs para la documentación técnica. Aunque estas herramientas tienen su lugar, por supuesto, se quedan cortas en áreas como la capacidad de búsqueda e indexación. A menudo vemos documentos importantes dispersos en plataformas como Google Drive, Google Docs, lo que dificulta encontrar información cuando se necesita. Si nos preguntas sobre el enfoque ideal, cuando se trata de documentación, se trata de la accesibilidad del conocimiento y la disponibilidad del conocimiento. La documentación debe ser centralizada, asegurando que está ahí cuando la necesitamos. Asignar un propietario a cada documento puede definitivamente ayudar a mantener la responsabilidad y mantener la información actualizada. E incluso podemos integrar la creación de documentación en tu proceso de desarrollo. Quizás incluso ponerlo en tu definición de hecho en tus tickets e historias. Estoy bastante seguro de que sería un lugar perfecto para eso. A continuación, está la elección de frameworks y herramientas. Normalmente, la elección de frameworks o lenguajes no es en sí misma un gran problema, ya que la mayoría tienen soporte a largo plazo. Por ejemplo, incluso un lenguaje como COBO, aparentemente obsoleto, no es una bandera roja automática. Sin embargo, la razón detrás de la elección de dicha tecnología antigua es lo que importa. ¿Hay una razón justificable fuerte para su uso? O si está obsoleto, ¿hay un plan en marcha para migrar a tecnologías más modernas? Centremos nuestra atención en otro ejemplo en esta área. Imagina un caso en el que una empresa debe elegir entre el desarrollo de aplicaciones móviles nativas en comparación con soluciones híbridas como React Native. Si la empresa, en este caso, opta por la primera opción, debe estar respaldada por un razonamiento sólido considerando los costos de mantenimiento más altos del desarrollo de aplicaciones móviles nativas en comparación con las soluciones híbridas. Así que después de todo, más allá de simplemente elegir una biblioteca o un framework o un paquete, se trata de tomar decisiones informadas. En general, es mejor evitar reinventar la rueda y optar por frameworks ampliamente soportados y bien establecidos, a menos que haya una necesidad convincente de algo más vanguardista o antiguo, digamos. Bien, hemos llegado al último paso. En el último paso, vamos a centrar nuestra atención en la calidad del código en nuestra preparación para la diligencia debida. Un aspecto crítico de la calidad del código es asegurar la consistencia en todo el tablero. Aquí es donde herramientas automatizadas como ESLint se vuelven invaluables. Junto con Comethooks, estas herramientas ayudan a mantener un estilo de codificación consistente en todo el equipo, haciendo el código más legible y, por supuesto, más mantenible. A menudo nos encontramos con el problema de los valores y configuraciones codificados. Esto incluye casos como configuraciones codificadas específicas del cliente o secretos codificados dentro del código. Aunque es un problema muy común, lo vemos mucho, es uno que podría ser realmente, realmente fácilmente solucionado, pero a menudo se pasa por alto. Para el desarrollo de front-end, quizás nosotros, los ingenieros de front-end recordamos que cualquier secreto utilizado en dispositivos del lado del cliente puede suponer un riesgo de seguridad considerando que la mayoría de las aplicaciones de front-end se construyen y sirven en el lado del cliente. Por supuesto, hay algunas excepciones. Me encantan herramientas como Next.js, Remix, BigFan. Pero en general, si intentas mantener el secreto lo más lejos posible del lado del cliente, deberías estar seguro. Así que el foco aquí no es sólo escribir un buen código, sino escribir un código seguro, escalable

6. Diligencia Debida Técnica y Hallazgos

Short description:

Siempre recuerda la importancia de tomar la diligencia en serio. Diferencia entre las mejores prácticas de desarrollo de software y la diligencia debida técnica. La diligencia debida técnica asegura la robustez de las operaciones tecnológicas de una empresa. Las mejores prácticas contribuyen a un producto saludable. Los hallazgos en el informe están basados en datos, respaldados por gráficos y ejemplos. El hallazgo más extraño durante la diligencia debida técnica fue copiar y pegar jQuery en React.

y código mantenible. Y sólo para mantener las cosas en perspectiva, siempre recuerda este consejo. La próxima persona que lea tu código podría no ser un junior, sino un asesino en serie senior, y él sabe dónde vives. Con esta increíble noticia, hemos llegado al final de nuestro viaje. Espero que esta sesión te haya proporcionado una perspectiva clara sobre la importancia de tomar la diligencia y desenrollarla. Gracias por tu tiempo y atención. ¿Por dónde queremos empezar? Quizás diferenciemos entre las best practices de desarrollo de software y la diligencia debida. Por supuesto. ¿Dónde está la diferencia? Porque esto también podría ser como, hey, best practices para el desarrollo de software. Lo siento, no entendí tu pregunta. Quiero decir, todo eso también se aplica para un desarrollo de software general. Si yo no quiero preparar como una adquisición. Exactamente. Así que sí, todo lo que tiene que ver con la diligencia debida es como, quiero decir, cuando hacemos diligencia debida, porque queremos saber si una tecnología es robusta, que es, quiero decir, si las operaciones tecnológicas de una empresa son lo suficientemente robustas para invertir o adquirir o lo que sea. O incluso una diligencia debida podría ser un chequeo de salud. Sólo por ejemplo, un CEO o un CTO quiere saber si todo va bien dentro de su empresa, ¿verdad? Principalmente los CEOs. Y por supuesto, tener un producto saludable, quiero decir, las best practices están ahí para eso, ¿verdad? Y ese es todo el propósito de tener best practices. Y cuando escribes el informe, ¿cómo formulas realmente algunos hallazgos que tienes? ¿Dices, OK, bueno, la base de código parecía un poco extraña y no seguían las prácticas? Básicamente, bueno, diría que cada empresa hace la diligencia debida un poco diferente. Pero generalmente lo que hacemos es, como mencioné también en la charla, todos los hallazgos son impulsados por data. Así que tenemos como data adecuada o un caso adecuado para mostrar o ejemplos. Y generalmente vienen con algunos gráficos proporcionados por nuestras herramientas internas e increíbles ingenieros de data. Y si escribes el informe, ¿cuál es la cosa más extraña que encontraste durante la diligencia debida? Ah, esa es una buena pregunta. Primero que nada, necesito aclarar aquí que yo mismo no hago diligencia debida porque para poder hacerlo, necesitas tener realmente una gran experiencia detrás de ti. Correcto. Así que lo que hacemos en realidad, tenemos un increíble equipo de SCA que tiene más de 50 años de experiencia como CTO. Y ellos son realmente los líderes principales de cada diligencia debida, porque para poder, al mirar el gráfico o los data y los insights, ellos simplemente tienen una sensación intuitiva de si todo va bien o no. Así que definitivamente necesita un background realmente rico. Lo que yo hago en realidad, yo trabajo principalmente en las herramientas internas que tenemos e ingeniería. Pero definitivamente me enfrento a casos, diría quizás, no sé, algo que se me viene a la mente, copiar y pegar jQuery en tu React. Vale. Sólo recuerdo eso en este momento.

7. Proceso de Diligencia Debida Técnica y Mejores Prácticas

Short description:

La diligencia debida es altamente relativa e implica el análisis de datos, así como entrevistas en persona con ingenieros de software senior, líderes técnicos y gerentes. Las mejores prácticas para la diligencia debida técnica pueden variar dependiendo del mercado de nicho y la ubicación, pero es importante esforzarse por ser el mejor. En cuanto a la ubicación de la documentación, prioriza la accesibilidad y disponibilidad. La responsabilidad de impulsar la diligencia debida técnica dentro de una empresa puede recaer en los gerentes de ingeniería o CTOs, dependiendo de la situación de la empresa. Adquirir más experiencia en la diligencia debida técnica implica seguir las mejores prácticas e investigar la documentación y la automatización de la infraestructura.

Vale. Y si encuentras eso, ¿cómo respondes? ¿Intentas mejorar la situación con los clientes? Quiero decir, como mencioné, la diligencia debida es altamente relativa a la empresa, ¿verdad? No es solo que obtenemos acceso a data y los analizamos. También hay muchas entrevistas, como has visto en las diapositivas del proceso. Los SDAs tendrán, tienen entrevistas en persona con ingenieros de software senior, líderes técnicos, gerentes. Así que no es solo data lo que tenemos, pero si ven algo en los data y en la base de código, definitivamente lo discutirán en las entrevistas. Y si aún no están convencidos, por supuesto algo está mal. Sí. Y mencionaste que depende mucho de la empresa, pero ¿existe alguna práctica acordada para hacer esto y cuánto difieren? Diría que no realmente, porque es un mercado de nicho, ¿verdad? Quiero decir, no esperas, depende de dónde estés trabajando, cuál es tu mercado, pero no es un mercado realmente grande y por lo tanto tampoco hay muchos grandes jugadores ahí fuera. Pero intentamos hacer lo mejor, intentamos ser los mejores, al menos en Europa. Eso es bueno, siempre apunta a ser el mejor. Y tal vez podamos pasar a algunos ejemplos prácticos. Seguro. Como, ¿tenemos una guía sobre dónde colocar la documentation, qué debería permanecer en el repositorio y qué debería ir a alguna wiki de la empresa? Diría que es lo que mejor funcione para tu equipo y, de nuevo, los data deben ser accesibles y disponibles cuando los necesites. Creo que solo con estos dos puntos, todo debería estar bien. No importa realmente qué herramientas estés usando. Por supuesto, si es una, si es una herramienta que tiene, como, no sé, una gran curva de aprendizaje y todos tus equipos no pueden seguir el ritmo, eso es un problema. Pero en general, sí.

Sobre mantenerse al día con las cosas, como deberías impulsar las cosas técnicas de TV dentro de la empresa, debería ser como un gerente de ingeniería para asegurarse de que todo se sigue o debería ser los desarrolladores individuales? ¿Y cómo educas al resto de tu empresa sobre las best practices relacionadas con eso? También puedes leer la pregunta, porque no entendí tu pregunta. ¿Podrías elaborar más sobre eso? Sí. Entonces creo que muchos de nosotros nos preguntamos, ¿quién debería impulsar esto en la empresa? ¿Debería ser un esfuerzo de base de los ingenieros? ¿Quieres decir, la persona que es el primer punto de contacto en el proceso de diligencia debida técnica? Por lo general, son los CTOs. ¿Y el CTO debería asegurarse a largo plazo de que su empresa esté preparada para eso? En realidad, depende. Como si esperan recaudar algunos fondos en su futuro. Quiero decir, basado en su situación, como mencioné, de nuevo, todo es muy relativo aquí. Por eso los chicos super experimentados viven cada TD técnico con mucho background y estando en la industria durante, ya sabes, 10 o 20 años. Pero sí, en realidad, esa es la razón. Así que es altamente relativo. Pero de nuevo, si esperan algo así, podrían estar preparados. ¿Y cuál es la mejor manera de obtener más experiencia allí? ¿Si quieres avanzar en ese camino?

8. Venta de Mejores Prácticas y Privacidad de Datos

Short description:

Es importante seguir las mejores prácticas, tener un código limpio y priorizar las conexiones de mercado y la red de contactos. Las empresas a menudo se someten a diligencia técnica para asegurar la financiación. Herramientas de automatización como Dependabot y Sonar pueden ayudar con las verificaciones de licencias y el monitoreo. En términos de privacidad de datos, las empresas comparten la información necesaria para el proceso de diligencia debida, y se toman medidas para garantizar que los datos se utilicen de manera adecuada.

Quiero decir, no fue como si algo mágico estuviera sucediendo allí. Fueron todos los puntos que mencioné, puedes encontrarlos fácilmente si buscas como best practices sobre documentation o best practices sobre, no sé, automation de infraestructura. O básicamente, hay como toneladas de artículos ahí fuera sobre best practices. Y lo que acabo de mencionar en esta charla fue como los puntos con los que nos enfrentamos con frecuencia. Y no fue solo querer mencionar, porque también podemos sentirlo mejor. Pero en general, es seguir las best practices, tener un código limpio como estoy en esto, entre las cosas que todos conocemos como principios de ser un ingeniero de software, ¿verdad? Así que no es algo mágico lo que está sucediendo allí. Y ¿cómo venderías ese no mágico suceso a las personas no técnicas de la empresa para asegurarte de que están dispuestas a gastar en el negocio? Esa es una buena pregunta. Quiero decir, pensé que teníamos ingenieros aquí. Pero estoy bromeando. Básicamente, a veces, no sé si es correcto decir la mayoría de las veces o no. Pero esta conexión de mercado y la red de contactos es realmente importante. Y la mayoría de las veces tienes como un cliente, que tal vez es un VC que quiere invertir y una empresa objetivo, que quiere por ejemplo, en este caso, imagina que quiere recaudar algunos fondos. Así que la empresa objetivo no tiene otra opción si quiere el fondo, necesita someterse a diligencia técnica. ¿Y cómo nos eligen los VCs? Tal vez porque somos los mejores tal vez. Bueno, quiero decir, supongo que no hay otra opción entonces. Y supongo que acabas de decir que podría haber algunos desarrolladores en la audiencia. Creo que todos nosotros como desarrolladores, amamos la automation y las herramientas. Y definitivamente hay herramientas para hacer verificaciones de licencias y cosas así. ¿Tienes alguna recomendación allí? ¿Y también tienes alguna recomendación general de herramientas para rastrear tu propio?

Sí, de nuevo, si puedes buscar esas herramientas, hay muchas de ellas ahí fuera, puedes comparar y elegir la que se adapte a tu situación y que más se ajuste a tu empresa. Pero las cosas más famosas ahí fuera por ejemplo, dependabot tal vez es un, es un, es un bot que puedes integrar en tus flujos de trabajo de GitHub. Y simplemente verificará si tienes alguna dependencia desactualizada y simplemente creará un PR automatizado para que puedas revisarlo y fusionarlo. Haciendo las cosas mucho más fáciles, no necesitas siempre revisar todo. Y en cualquier lugar te dirá si por ejemplo, esta actualización tiene alguna corrección de alguna vulnerabilidad crítica de security o no, así que muchas buenas entradas allí. Podemos incluir otras herramientas como Sonar tal vez en tu, si ya estás al tanto de eso, en tus pipelines de desarrollo, también tiene toneladas de características, una de ellas podría ser el monitoreo. Vale, y terminemos con una última pregunta. Especialmente en la UE, la privacidad de los data es cada vez más y más importante. Y dijiste que en realidad analizas los data de las empresas en las que estás interesado. Entonces, ¿qué pueden compartir las empresas contigo? ¿Y cómo te aseguras de que esos data se utilicen solo para tu proceso? De nuevo, me gustaría mencionar que. Quiero decir, si una empresa por ejemplo, imagina un caso en el que tienes una empresa y quieres recaudar algunos fondos, recaudar fondos no es fácil, ¿verdad? Y si encuentras un VC y el VC quiere que te sometas a un Tech TD, y luego te encuentra, definitivamente te someterás a Tech TD. Así que es como, de alguna manera, la mayoría de las veces, es para lo mejor someterse

9. Acceso a Datos en la Diligencia Técnica

Short description:

Algunas empresas pueden dudar en cooperar plenamente, pero garantizamos la seguridad de los datos y el anonimato a través de acuerdos de confidencialidad y estrictas regulaciones europeas. En la diligencia técnica, buscamos acceder a la mayor cantidad de datos posible, incluyendo códigos fuente, sistemas de tickets, organigramas, y más. Los procesos automatizados nos ayudan a analizar grandes bases de código e identificar archivos importantes y lógica de negocio. Si tienes más preguntas, por favor, procede a la sesión de preguntas y respuestas con el ponente.

Diligencia Técnica. Y por lo tanto, tienen que cooperar. Y claro, algunas empresas, por ejemplo, no cooperan de la mejor manera. Quizás no quieren entregar algunos data críticos. Pero quiero decir, firmamos acuerdos de confidencialidad, todo es legal. No hay preocupación sobre fugas de data o algo así. Todo es anónimo. Quiero decir, vivimos en Europa, ¿verdad? Tenemos reglas estrictas al respecto. Pero en general, si hablamos sobre qué datos solemos tener acceso, en el mejor de los casos, diría todo lo posible, como acceso a todos los códigos fuente, cada proceso de códigos fuente. Y tenemos muchos diferentes procesos de ingeniería de data que pueden extraer algunos datos e insights increíbles. De los sistemas de tickets, hay insights valiosos escondidos en los sistemas de tickets. Podemos recopilar mucho conocimiento de eso. Y un organigrama tal vez la estructura salarial, básicamente todo puede estar en medio de un proceso de Diligencia Técnica. Además, los STA podrían pedir documentos significativos, tal vez de nuevo, para asegurarse de algo. Así que cualquier cosa sería, quiero decir, cuantos más data, mejor podemos. Bueno, eso es probablemente del siglo 25. Cuantos más data, mejor. Una última pregunta mía allí. Estás diciendo que también quieres el código fuente, pero ¿hasta qué punto realmente te adentras en líneas individuales en el analizador de código fuente? ¿Necesito estar pensando, tener miedo de que Amin venga y revise mi código fuente del lunes por la mañana? En realidad, quiero decir, a veces una empresa que va a hacer una Diligencia Técnica podría tener toneladas de repositorios, millones de líneas de código, y definitivamente no es muy eficiente revisar todos ellos, ¿verdad? Así que tenemos procesos automatizados como automatizar, en realidad estamos revisando códigos dentro de los procesos de data que tenemos, y recopilamos algunos insights como, por ejemplo, no sé cuánto detalle se me permite dar, pero por ejemplo, podemos entender tal vez qué archivo podría ser un hotspot tal vez, o en general incluso los STA. Quiero decir, si eres un tipo experimentado, podrías descubrir de alguna manera qué archivo es importante, cuál no lo es, cuál contiene alguna lógica de negocio importante, y echarle un vistazo. Eso revelaría tantas cosas.

Eso suena súper interesante, pero necesitamos cerrar aquí. Pero si tienes más preguntas, puedes ir a la sesión de preguntas y respuestas con el ponente ahora. Así que por favor, vuelve de nuevo.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2022React Summit 2022
27 min
Impact: Growing as an Engineer
Becoming a web engineer is not easy, but there are tons of resources out there to help you on your journey. But where do you go from there? What do you do to keep growing, and to keep expanding the value you bring to your company? In this talk we’ll look at the different kinds of impact you can have as a web engineer. We’ll walk through what it means to take on bigger, more complex projects, and how to scale yourself, and grow the community around you. By driving our own development we can all grow our impact, and in this talk, we’ll discuss how to go about this.
TechLead Conference 2023TechLead Conference 2023
25 min
On Becoming a Tech Lead
Tech lead sounds like a lot of work. And not the fun coding kind either. Why would you ever want that? What does it feel like when you get it?In this talk Swizec explains why he took the step towards technical leadership, how his priorities changed, and why it means he’s doing more engineering than ever. A whole new world where writing code is the easy part.
10 min
Emma Bostian: I landed my dream job by sharing my blogs on Twitter
Featured Article
Software engineer, lecturer, podcast host, author — is there something Emma Bostian hasn't done? She moved from America to Sweden, started working at Spotify, and took up a few challenges along the way. And now she has some career tips to share.

What led you to software engineering? 
I was raised in the ecosphere of tech because my dad is a software engineer at IBM, and my mom was a designer there, too. My dad always encouraged me to join STEM and take a look at computer science — however, I was convinced I wanted to be a medical doctor. In my first year of college, I declared a biology major and quickly realized I was not too fond of it. In my second semester, I switched to an actuarial science major where I took Introduction to Computer Science, and the rest is history. In my second year of college, I declared a computer science major and began my journey from there.
What is the most impactful thing you ever did to boost your career?
Writing blog posts and documenting my learning journey on Twitter has far been the best career boost. I wrote purely for myself to reference the things I learned over time, and I even utilized my design skills in Figma to create custom graphics depicting difficult concepts like CSS specificity. By sharing my blogs on Twitter and engaging with the people reading them, I was able to grow an audience extremely quickly. I began receiving conference speaking opportunities, podcast requests, and course invitations to teach with LinkedIn Learning and Frontend Masters.
Ultimately, I landed my job at Spotify through Twitter, too, when a friend and follower of mine asked if I would be interested in interviewing. Now I live in Stockholm working my dream job. It still blows my mind how tweeting about my blog led me to some of the most amazing career opportunities.
What would be your three tips for engineers to level up their career? 
First, be patient. I often see posts on Twitter or LinkedIn about developers who were promoted to a senior position after a year. And while this is wonderful, I think we forget that each company has a different standard for what constitutes a senior developer, and everyone's journey will be different.
Second, don't be afraid to ask questions. If you try your best to solve a problem or answer a question you have, but you can't figure it out after a reasonable amount of time, ask a team member or mentor for help.
And lastly, invest in the right resources for learning. When I started my journey, I didn't know which platforms worked for me to learn. Now, I have a few trusted platforms such as Frontend Masters, Free Code Camp, or Level Up Tutorials that I go to when I need to learn a new skill.
You're currently working as a software engineer at Spotify. What does a typical day of yours look like there?
I begin my day answering emails. Then we have a team breakfast and a standup remotely as we're all still remote at Spotify. After that, we might have a web tech sync with the other squads in our business unit. The day usually includes some form of pair or mob programming, depending on the work stream. 
My team always has Fika, a traditional Swedish coffee break, scheduled every afternoon. Every couple of Fridays, we have team games planned to release some stress. 
Also, I tend to have a lot of free time to focus, which is nice but makes for a boring answer to this question!
Do you have some rituals or tools that keep you focused and goal-oriented?
I'll admit that I've been struggling with staying motivated in the time of remote work. I've been remote with Spotify since onboarding a year ago, but my team is wonderful, and they help me when I'm down.
Apart from that, I use Todoist to keep track of my tasks, and, naturally, I listen to Spotify while working. But other than that, not really. Maybe I should adopt some new tools to keep me on track!
My current favorite Spotify playlist is Brand New Chill: https://open.spotify.com/playlist/37i9dQZF1DX6uQnoHESB3u?si=380263b3c853442e
I also love Chillout Daily: https://open.spotify.com/playlist/7ozIozDp260fjNOZy1yzRG?si=66d6c839ec9b458a
You wrote a book called De-coding the Technical Interview. What was the impulse to do it?
I wanted to give the community a manual of the essentials of computer science knowledge to ace the technical interviews. The book covers data structures like stacks, queues, or linked lists, tackles algorithms, and deals with systems design. You'll also learn about the interview process from start to finish, get tips on how to submit an amazing take-home project, or understand how to problem solve. You'll also gain knowledge on the frontend coding skills needed to excel at a frontend interview.

If you could stress one piece of advice on surviving a technical interview, which would it be?
Do not lie your way through an interview. If you don't know the answer to something, just admit it. There's no shame in admitting you don't know the answer to something. There is shame in faking it and pretending like you do know the answer.
What's the single best practice everyone who writes code should follow?
Remember that while you are technically writing code for computers, you're also writing it for humans. Your code should be readable and have as little complexity as possible without sacrificing accessibility or performance.
In addition to the book, you co-host the Ladybug Podcast. What inspired you to enter this field, and what are the podcast's main topics?
We talk about everything tech and career on the podcast, from Java and GraphQL to how to start a business and cross-cultural communication. The podcast is a way for me and my co-hosts to share our experiences in tech, having taken different paths. And I'm really glad for doing it — it has allowed me to meet so many incredible people, learn many new things, and support my dream of teaching.
What pieces of your work are you most proud of?
My technical interview book was a huge feat for me as well as my courses with LinkedIn Learning on building a tech resume. I enjoy creating things that help other people advance their careers, so I'm also proud of my courses with Frontend Masters on design systems and CSS.
***
Follow Emma on Twitter
14 min
Kent C. Dodds: Consume, build, and teach — and level up your career
Featured Article
Even though his bio offers quite a hefty reading, he only applied for one job in his career. The rest came along as he was building his name as a renowned speaker, teacher, and a prolific figure of the open-source community. How did Kent do it? “Commit to creating high-quality content,” he says.


What led you to programming?
I had a friend when I was a teenager who was really into it, and he tried to teach me. But I just couldn't get it — it didn't make any sense to me. So I never really thought I'd get into programming, but I liked computers a lot, and I ended up going to school for electrical engineering. 
Well, that didn't work because I'm not good at math. But right when I started the program, I got a job at a company uploading videos to YouTube and that sort of thing. The work was tedious, so I decided to write a computer program to automate lots of the work I was doing with the knowledge I had about programming. And that was the first spark of things for me to use programming to solve real-world problems. 
What is the most impactful thing you ever did to boost your career? 
Committing to creating high-quality content. That might sound obvious because I'm a full-time educator now, but I would not have gotten my job at PayPal if I hadn't been so active with my blog. In fact, lots of my jobs came out of me being involved in the community around meetups, conferences, or open-source projects. 
How do you choose topics for the content you create, be it for your blog or podcast?
I don't think too much about the content other people are creating. And I don't often consume it. My ideas come from the things that I'm working on, things that I'm learning myself, or — when I was working with a team of developers — the things that I had to remind people of in code reviews regularly. Anytime that I would have a code review comment that was pretty long to describe my position, that was an excellent opportunity for a blog post. Also, if people ask me about a topic regularly, I'll make a blog post rather than answer that question multiple times.


What would be your three tips for engineers to level up their career? 
The number one thing I tell people is to be a nice person. I know that sounds fluffy or silly, but it cannot be overstated. You will get so much further in your career and just in life in general if you're a nice person. That doesn't mean that you take people being jerks lying down, but how you interact with others is out of kindness. You could be the best engineer in the entire world, but if you're not a nice person, you will not reach your full potential or accomplish your goals, whatever they may be.
Second, it's just as important to decide what you are not going to learn as it is to decide what you are going to learn. You could jump into countless things — and there are successful people who are polyglot programmers, but I can't speak to that a whole lot. All I can tell you is that in my experience, focusing on specific things that I want to be truly good at has worked out great for my career. That doesn't mean that I closed myself off to other things. With my website rewrite, I have been doing a lot of dev ops-related work and a lot of back-end stuff that I've typically not been involved in. You want to keep your head up on what's going on outside of what you're doing so that you know what direction to go in when you come across problems you need to solve. However, finding a focus on what you want to be good at has helped me a lot. That way, you feel a little less stressed.
And the third one? 
Learn how to learn effectively. It's a three-step process: you consume, build, and teach. The consumption of newsletters and Twitter and whatever inspires you, but you don't want to spend too much time doing that — implementing it into actually building something matters. This happens naturally if you work at a company, but maybe you're not making the things you want to learn, so you may want to start a side project. The building phase is where you get experience, but you also want to solidify that experience. How? You start teaching. You don't necessarily have to teach it to people, it could be stuffed animals. The goal of the teaching is to retain in your mind what you've learned through the building process.
What are you working on right now? 
The big thing I'm working on right now is a rewrite of my website. It'll be much more than just a developer portfolio — I'll have user accounts, and there'll be fun things that you can do with it. And because it's more than just a website, I'm using Remix, a new cool framework in the React ecosystem. I'm also working on updating my material on TestingJavaScript.com and a TypeScript course as well. 
So, whatever I'm working on, it ends up resulting in lots of opportunities for content.


Do you have some rituals that keep you focused and goal-oriented? 
I have a notepad where I keep all of my notes of what I'm going to do for the day so that when I'm checking things off, I'm not distracted notifications. I've tried apps for that, and that does not work well for me. 
I also am a firm believer in inbox zero. I have my work inbox and my personal inbox, and I keep them both at zero. And I kind of use that as a to-do list. 
And if I'm not feeling excited about working for some reason, I will often hop on my Onewheel, which is an electric skateboard that only has one giant wheel in the middle. It's just a total blast, and I'll hop on that with my backpack and a charger, and I'll go to a Starbucks or a park just to declutter my mind.
What things in the React universe are you excited about right now?
React version 18 is coming out soon. The experimental version is out there, and it's fun to play with. I'm just really thrilled that it's no longer a concurrent mode but concurrent features that you can opt into. Cool things like that will enable React server components in the future. 
But the biggest thing I'm excited about is Remix. That's huge. It eliminates a lot of problems that are solved well other tools, but when I'm using Remix, I don't have those problems, so I don't need those clusters.
You already said that teaching is an integral part of the learning process, and you stand your word since you're also a full-time educator. What inspired you to enter this field?
I have been a teacher for as long as I can remember. I grew up in a church where you talk in front of your peers from a very young age, and my mom was an elementary school teacher, so teaching has just always been a part of me. 
I really just enjoy sharing what I'm learning with others. As far as teaching technical topics, I gave my first workshop when I was still a student at Brigham Young University. With my fellow, we taught how to use AngularJS, and I got Firebase to sponsor pizza so they would show up, and that was pretty fun.
Then I started teaching on the side at egghead.io right after I'd graduated. That was when I first got a paycheck for teaching. And I realized that teaching could be quite lucrative and support my family and me as a full-time endeavor. So I did it — I quit my job. I'm a very risk-averse person, so I'd done teaching as a side hustle for four years just to verify that I could make this work.
When TestingJavaScript was released, and I got that paycheck, I realized that I didn't need my PayPal salary anymore. I could just focus my daytime on teaching and give my evenings back to my family, which was a nice trait.


Apart from that, how has teaching impacted your career? 
Earlier I mentioned that pretty much all of my jobs came because I was perceived as an expert. After the first job, where I was an intern and then converted into full-time, I never applied to another. I worked for four different companies, and they wouldn't have recruited me if they didn't know who I was and what I was doing. My content is how they knew who I was — I just made it easy for them to find me. Teaching made that impact. It made my career. 
We talked about React and Remix. Are there any other open-source projects that you'd recommend keeping an eye on or contributing to?
I have some myself. React Testing Library is probably the biggest one that people are familiar with. And if React isn't your jam, then other framework versions of the testing library. 
React Query is also really popular. If you're using Remix, you don't need it, but if you're not, I strongly advise using React Query cause it's a stellar, fantastic library, and Tanner Linsley, the creator, is a stellar and fantastic person. 
What pieces of your work are you most proud of? 
Probably the biggest thing I've ever done is EpicReact.Dev. It has helped tens of thousands of people get really good at React, improve their careers and make the world a better place with the skills that they develop. My whole mission is to make the world a better place through quality software, and I feel like I've done that best with Epic React. 
There are things that I've built at other companies that are still in use, and I'm proud of those cause they've stood the test of time, at least these last few years. But of everything, I think Epic React has made the biggest impact.
***
Follow Kent on Twitter and listen to his favorite Spotify playlist
TechLead Conference 2023TechLead Conference 2023
36 min
Effective Communication for Engineers
Your communication skills affect your career prospects, the value you bring to your company, and the likelihood of your promotion. This session helps you communicate better in a variety of professional situations, including meetings, email messages, pitches, and presentations.
React Advanced Conference 2022React Advanced Conference 2022
24 min
A Career As Software Engineer
Typically I talk a lot about deeply technical concepts like TypeScript, type systems, (im)mutability, MobX, Immer etc. But this time it's going to be personal and I'll share lessons, good and bad, about growing as an engineer. I've been leading open source projects, short lived projects as a freelancer and I went through the transition of engineer to tech lead twice. Both at a young startup and at Meta. This talk will be about personal experiences, unpopular opinions and even actions, and anything else that might be counterintuitive. Join for some take-aways for anyone aiming at an engineering focused career. Probably I will be wrong about most things, so don’t miss the opportunity to follow up afterwards!

Workshops on related topic

React Summit 2022React Summit 2022
75 min
How To Design A Sustainable Freelance/Contracting Career + Speedcoding Challenge
WorkshopFree
Ready to kickstart your freelance career or just getting started on your freelance journey? You’re in the right spot. Learn from the world’s largest fully distributed workforce in the world.
The independent talent movement is the future of work. If you’re considering leaving full-time employment for a career as a freelancer, now is the time to find your successful space in the independent talent workforce. More people are working freelance today than ever before, with the freelance marketplace now contributing $1.2 trillion to the US economy. Some of the most in-demand roles for freelancers right now are senior developers with professional experience in React, Python, Blockchain, QA, and Node.js.
This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing/contracting career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
At the end of the workshop there will be a Q&A session with a Freelance Developer who can answer your questions and provide insights and tips into their own success.
During the Workshop break, we will be running a speed-coding challenge! At the end of the workshop, we will award a prize for the winner and display the leaderboard.
We will have you login to our portal and complete the challenge as fast as you can to earn points. Points are assigned based on difficulty and the speed at which you solve the tasks. In case you complete all tasks, you get extra points for the remaining time. You’ll see your score, ranking, and the leaderboard once you complete the challenge.
We will be giving away three Amazon Gift Cards ($200, $100, $75) for the top three winners.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Designing A Sustainable Freelance Career
WorkshopFree
Would you like to pursue your passions and have more control over your career? Would you like schedule and location flexibility and project variety? Would you like the stability of working full-time and getting paid consistently? Thousands of companies have embraced remote work and realize that they have access to a global talent pool. This is advantageous for anyone who has considered or is currently considering freelance work.>> Submit your interest on becoming a freelance engineer with Toptal and get a call with Talent Acquisition specialist <<

Freelancing is no longer an unstable career choice.

This workshop will help you design a sustainable and profitable full-time (or part-time) freelancing career. We will give you tools, tips, best practices, and help you avoid common pitfalls.
Table of contents

Module 1: Dispelling common myths about freelancing
Module 2: What does freelancing look like in 2021 and beyond
Module 3: Freelancing choices and what to look for (and what to avoid)
Module 4: Benefits of freelancing from a freelancer + case study
BREAK
Module 6: How to get started freelancing (experience, resume, preparation)
Module 7: Common paths to full-time freelancing
Module 8: Essentials: setting your rate and getting work
Module 9: Next steps: networking with peers, upskilling, changing the world
Module 10: Freelancer AMA
React Summit Remote Edition 2021React Summit Remote Edition 2021
121 min
Landing Your Next Developer Job
WorkshopFree
Renaud Bressant (Head of Product), Nathanael Lamellière (Head of Customer Success and Solution Engineer), Nouha Chhih (Developer Experience Manager) will be looking at the different developer jobs that you can accounter when looking for your next developer role. We'll be explaining the specifics of each role, to help you identify which one could be your next move. We'll also be sharing tips to help you navigate the recruitment process, based on the different roles we interviewed for as recruiters, but also as candidates. This will be more of an Ask Us Anything session, so don't hesitate to share your thoughts and questions during the session.