Rust en el equipo: qué exigir y qué enseñar al contratar

La incorporación a un proyecto Rust debe enseñar a un ingeniero a compilar, probar, explicar y modificar el código de tu proyecto con la revisión adecuada. Antes de exigir experiencia en Rust para un puesto, decide qué responsabilidades requieren conocimientos desde el primer día y cuáles puede enseñar tu equipo mediante trabajo supervisado. Refleja esa diferencia tanto en el puesto como en el plan de aprendizaje.

Un equipo puede equivocarse en ambos sentidos: descartar a un ingeniero capaz por no dominar una sintaxis que podría enseñarle. También puede contratar a alguien con ganas de aprender para un puesto en el que nadie tiene tiempo de revisar su trabajo. Un plan de incorporación te ayuda a detectar cuál de esas situaciones estás creando antes de que alguien acepte la oferta.

¿Qué significa para tu equipo el anuncio de Microsoft sobre Rust?

Adoptar un lenguaje también exige preparar todo lo que permite trabajar con él. El anuncio de una gran empresa es un motivo para examinar tu propio proceso de desarrollo, no para copiar sus requisitos de contratación.

En un artículo publicado el 10 de septiembre en la Rust Foundation, Victor Ciura, ingeniero principal de Microsoft, explicó el nivel interno Tier-1 de Rust en términos de herramientas de compilación y desarrollo, controles de calidad, integración con plataformas y mantenimiento en producción. También señaló que C++ sigue siendo predominante dentro de la empresa. Es una clasificación interna de Microsoft, no el sistema de niveles de plataformas de destino de Rust ni una orden de reescribir todos los proyectos. Rust Foundation: Rust es un lenguaje Tier-1 en Microsoft

Para una startup, la pregunta útil es más concreta: ¿qué debe saber hacer un ingeniero en el componente que quieres construir? Ampliar un servicio que ya funciona es un trabajo distinto de diseñar tu primera biblioteca de Rust y decidir cómo deberá utilizarla el resto del equipo.

El siguiente plan es una propuesta de gestión, no una conclusión respaldada por datos sobre resultados de contratación. Sirve para distinguir los conocimientos que se pueden enseñar de las responsabilidades que ya requieren experiencia. Adapta las tareas y las revisiones a tu sistema; completar estos ejemplos no demuestra que alguien esté preparado para asumir trabajo en producción.

Decide qué conocimientos de Rust necesitas desde el primer día

Fija los requisitos del puesto según el trabajo y la capacidad de revisión disponible. Empieza por un cambio real del que se haría cargo la nueva persona. Después, identifica dónde podría ayudar un revisor y dónde hace falta criterio propio y experiencia.

Para cada responsabilidad, anota qué ocurriría si se ejecutara mal. Cambiar el mensaje de error de un analizador, diseñar interfaces compartidas y mantener la comunicación entre lenguajes no deberían tener los mismos requisitos solo porque todo ello implique usar Rust.

Esta distinción puede orientar la conversación sobre el puesto:

Utiliza estas filas para debatir, no como categorías universales de puestos. Un título conocido puede ocultar responsabilidades muy distintas. Pide al responsable de contratación y al ingeniero que revisará el trabajo que acuerden cuál describe mejor el puesto.

El caso más difícil es un equipo sin nadie cualificado para revisar Rust. Asignar un curso no crea esa capacidad. Quizá necesites contratar a alguien con experiencia, contar con un revisor externo cualificado con funciones bien definidas o posponer el componente. Si el plan es «aprenderemos juntos», hay que responder quién aprobará el primer cambio importante.

A continuación, describe el puesto con honestidad. Si Rust se puede aprender una vez dentro, indícalo y explica el apoyo disponible. Si la persona tendrá que orientar a los demás desde el inicio, aclara qué decisiones asumirá. La guía de Kit para definir el perfil del candidato ideal ayuda a convertir esas responsabilidades en criterios observables antes de empezar las entrevistas.

Prepara un punto de partida que funcione para todos

Una guía de configuración útil termina con una tarea que funciona y una persona a la que recurrir. Documenta el entorno que realmente exige tu repositorio y pide a alguien que no conozca el proyecto que siga las instrucciones.

La documentación de rustup explica los archivos de configuración de herramientas y cómo consultar la configuración activa con rustup show. Algunas opciones pueden tener prioridad sobre el archivo del repositorio, así que su mera presencia no permite saber qué herramientas utiliza una persona. Compara el entorno activo con el que espera el proyecto. Manual de rustup: opciones con prioridad

El manifiesto de dependencias de Cargo y su archivo de bloqueo cumplen funciones distintas. El manifiesto describe las dependencias; el archivo de bloqueo registra las versiones resueltas. Eso ayuda a repetir la selección de dependencias, pero no garantiza bibliotecas del sistema idénticas, dependencias seguras ni una compilación reproducible bit a bit. Manual de Cargo: Cargo.toml y Cargo.lock

Las instrucciones de incorporación deben relacionar esos conceptos con el repositorio. Indica dónde se configuran las herramientas, qué programas necesita el equipo local, qué accesos hacen falta, desde qué directorio se trabaja y qué comando ejecuta una prueba pequeña que ya existe. Incluye la configuración local que deba obtenerse mediante vuestro procedimiento habitual de acceso. No des por hecho que la persona recién llegada sabe a qué compañero preguntar por lo que falta.

Describe el resultado esperado sin depender de una captura antigua del terminal. Nombra la prueba o el comportamiento que debe observar el ingeniero. Si el comando falla, señala la información de diagnóstico que permite distinguir una dependencia ausente de un fallo de la aplicación.

Asigna a alguien el mantenimiento de estas instrucciones cuando cambie la forma de trabajar. Un fallo de configuración puede indicar un defecto en la documentación, no falta de capacidad en una nueva incorporación. Anota el paso que falta mientras aún está claro y corrige la guía antes de que llegue la siguiente persona.

Por último, muestra dónde se ejecuta esa misma comprobación en la integración continua, o CI. Pide al ingeniero que localice un resultado reciente y explique qué comprueba. Así relacionará el comando local con el proceso de revisión del equipo, y la siguiente conversación podrá partir de una pregunta concreta: ¿qué pruebas esperaría ver un revisor junto a una propuesta de cambio?

Evalúa un cambio pequeño que puedas revisar de verdad

Utiliza una tarea acotada y criterios explícitos para hablar de cómo razona un ingeniero. Si el puesto admite a personas que están aprendiendo Rust, proporciona suficiente contexto para distinguir el desconocimiento del lenguaje de las capacidades que querías evaluar.

Imagina este ejercicio: un componente de Rust recibe un registro de entrada y devuelve el resultado del análisis. Cuando un campo tiene un formato incorrecto, genera un error poco útil. Pide al ingeniero que cambie ese comportamiento, añada una prueba de regresión y explique su decisión. Facilita un repositorio que compile y describe qué debería recibir el código que llama al componente.

Es un ejemplo adaptable, no un método validado para predecir el desempeño laboral. Elige una tarea pequeña que los revisores conozcan lo bastante bien como para debatir alternativas. No uses un ejercicio de selección para obtener trabajo de producción sin remunerar.

Redacta las instrucciones antes de invitar a nadie

Explica el comportamiento solicitado, qué queda fuera del ejercicio y cuánto esfuerzo esperas. Indica si se permite consultar documentación, buscar información, usar IA o hablar con un revisor. Pide a los candidatos que describan la ayuda relevante que hayan utilizado, para que la conversación posterior respete las condiciones que ofreciste.

Si el puesto admite a personas en aprendizaje, señala los puntos de entrada pertinentes y permite hacer preguntas. Aclara si valoras una implementación terminada, un intento parcial bien razonado o ambas cosas. Esas decisiones determinan a qué dedicará su tiempo el candidato. Deben figurar en las instrucciones, no quedar como expectativas ocultas de los revisores.

La documentación de Cargo explica que cargo test compila y ejecuta pruebas, incluidas las unitarias, de integración y de documentación, según las opciones y la configuración del proyecto. Pide al candidato que indique qué comprobaciones ejecutó y explique su alcance. Un resultado correcto solo aporta información sobre los comportamientos que comprueban esas pruebas. Manual de Cargo: cargo test

Contrasta las decisiones con los mismos criterios

El cuadro de evaluación del revisor puede ser breve:

• Comportamiento: ¿El cambio cumple el requisito indicado, incluida la entrada con formato incorrecto?
• Pruebas: ¿La prueba de regresión reproduce el fallo y deja claro el comportamiento esperado?
• Explicación: ¿El candidato puede describir el recorrido de los datos y justificar el tratamiento del error?
• Alcance: ¿Identifica los supuestos y el trabajo que ha dejado deliberadamente fuera del ejercicio?
• Revisión: ¿Puede valorar una objeción concreta y explicar si le hace cambiar de enfoque?

Anota una observación junto a cada criterio. «Explicó por qué el código que llama al componente necesita el nombre del campo» resulta más útil para decidir que «se comunica bien». Si un revisor quiere puntuar conocimientos avanzados de diseño en Rust, comprueba si realmente formaban parte del puesto anunciado.

Nuestra guía para estructurar ejercicios de código trata la experiencia del candidato durante el proceso. Distingue este ejercicio de la incorporación de un empleado: el candidato debe entender la evaluación que acepta, mientras que un empleado necesita tiempo y apoyo para aprender cómo funciona el sistema del equipo.

Enseña Rust a partir del código de tu proyecto

Combina el material de aprendizaje con un fragmento de código que el ingeniero pueda explicar a un revisor. Elige los conceptos necesarios para la siguiente contribución supervisada, en lugar de convertir el temario de un curso en una lista de requisitos para publicar cambios.

El libro de Rust describe la propiedad de los datos como un conjunto de reglas de gestión de memoria que comprueba el compilador. Explica los movimientos, los préstamos y lo que ocurre cuando un propietario sale de su ámbito. Esos conceptos permiten mantener una conversación precisa sobre los datos que pasan por tu componente. El libro de Rust: ¿Qué es la propiedad?

Por ejemplo, elige una función breve que devuelva datos al código que la llama. Pide al ingeniero que explique de dónde proceden los datos, quién es su propietario en cada paso y por qué la interfaz devuelve datos prestados o transfiere su propiedad. Comenta si una copia es intencionada y qué cambiaría al usar una alternativa. Acota el ejercicio lo suficiente para que el revisor pueda examinar el razonamiento, en lugar de limitarse a aprobar los cambios.

El equipo de Android de Google publica Comprehensive Rust, un curso gratuito que admite a personas sin conocimientos previos de Rust. Puedes seleccionar lecciones pertinentes para preparar esa conversación. Terminar un curso, o seguir su calendario, no demuestra que alguien esté preparado para hacerse cargo de tu componente en producción.

Esta es una posible secuencia de incorporación:

1. Compilar: Sigue la guía de configuración y localiza el resultado esperado de la prueba. Anota lo que las instrucciones no explicaban.
2. Explicar: Repasa con un revisor un recorrido de datos, una ruta de error y un límite de propiedad ya existentes.
3. Modificar: Presenta un cambio de comportamiento acotado, explica las pruebas y responde a la revisión.
4. Operar: Recorre el diagnóstico, la publicación y la reversión de cambios del componente real, con el alcance que exija el puesto.

Ajusta el ritmo al trabajo y al apoyo disponible. Un calendario puede servir para programar conversaciones, pero una fecha no demuestra que alguien pueda asumir una responsabilidad de forma segura.

En cada punto de control, anota brevemente lo observado y el apoyo que aún hace falta. «Puede modificar este analizador con revisión; aún no ha gestionado una publicación» ofrece contexto útil al siguiente revisor. Una etiqueta única como «formado en Rust» pierde esa distinción.

Permite también que el ingeniero cuestione el material. Si el ejercicio depende de una convención no documentada, actualiza la lección. Si la siguiente tarea exige un concepto que el curso no cubría, organiza una explicación específica antes de asignarla.

Define qué necesita la revisión de alguien con experiencia en Rust

Identifica los cambios que requieren criterio especializado antes de que una nueva incorporación tenga que abordarlos. El plan de revisión debe indicar quién puede aprobarlos y qué hacer cuando esa persona no está disponible.

El libro de Rust explica que las operaciones unsafe imponen obligaciones que debe cumplir quien programa. Un bloque unsafe no desactiva el comprobador de préstamos, y el libro recomienda mantener esos bloques pequeños y ofrecer abstracciones seguras. Que el código compile no significa que esas obligaciones estén cumplidas. El libro de Rust: Unsafe Rust

Localiza en tu componente el código unsafe y las interfaces con otros lenguajes. Documenta los supuestos que necesita examinar un revisor. No permitas que la primera contribución de alguien dependa, sin decirlo, de que esa persona certifique por sí sola una abstracción que aún no conoce.

Las preguntas de revisión deben ir más allá de la gestión de memoria. El ingeniero sigue teniendo que razonar sobre el comportamiento solicitado, las rutas de error, las reglas de acceso cuando correspondan y cómo llega un cambio a los usuarios. Las comprobaciones del lenguaje no determinan si la implementación cumple el requisito del producto.

Concreta qué está preparada para asumir cada persona. Puedes autorizar cambios supervisados en un módulo conocido y dejar el diseño de interfaces o las publicaciones a cargo de alguien experimentado. Registra ese alcance y revísalo después de observar más trabajo. No conviertas el resultado de un cuestionario en un permiso general para mantener cualquier parte del sistema.

Si el revisor necesario nunca tiene disponibilidad, ajusta la carga de trabajo o el plan de personal. Una cola de revisiones bloqueadas es un problema de capacidad que debe resolver quien dirige el equipo. Enviar otro curso a quien está aprendiendo no responde a la pregunta de quién revisará su siguiente cambio.

Conserva registros útiles de selección e incorporación en Kit

Los criterios de evaluación, los registros de aprendizaje y las decisiones de revisión técnica deben resultar claros para quien los consulte después. Responden a preguntas distintas, aunque se refieran al mismo lenguaje.

Las etapas de contratación de Kit permiten definir criterios de puntuación con nombres, descripciones, pesos y escalas. Los revisores pueden registrar puntuaciones y comentarios, y los ejercicios de código admiten plantillas de GitHub e instrucciones escritas. Estas funciones permiten organizar la selección en torno a los criterios elegidos. No demuestran que una implementación entregada sea correcta sin la revisión adecuada.

Para la formación de empleados, Kit Training permite crear cursos con diapositivas, cuestionarios y declaraciones, además de gestionar invitaciones, registros de progreso y recordatorios. Los programas de listas de comprobación permiten editar puntos de control, añadir instrucciones por plataforma y recibir pruebas documentales. Tú aportas el material de Rust y decides qué debe documentar una confirmación de configuración; Kit no incluye un temario de Rust ni verifica automáticamente la competencia para programar.

Un registro de finalización indica que se han completado los pasos de aprendizaje configurados. Deja explícito el criterio técnico: quién revisó el trabajo, qué observó y qué responsabilidad puede asumir el ingeniero a continuación. Terminar un curso no sustituye esa conversación.

Antes de exigir Rust en una oferta de empleo, acuerda cuál será la primera contribución, quién la revisará y qué experiencia necesita realmente el puesto. Después, adapta las instrucciones de selección y el material de incorporación a esa decisión. Tendrás un plan concreto que comentar con un candidato y con un nuevo compañero.