De principiante a desarrollador de Rust: plan de preparación para la entrevista

Rust: un lenguaje que te hace pensar de otra manera

Has decidido conquistar Rust. Excelente. No es solo otro lenguaje, es un desafío. Rust rompe los esquemas a los que estamos acostumbrados en Python, JavaScript o incluso C++. Te obliga a pensar en la memoria, la seguridad y la concurrencia a un nuevo nivel.

Una entrevista de Rust no es un examen de sintaxis. Es una prueba de cómo piensas. Los entrevistadores quieren ver que entiendes la filosofía del lenguaje: ownership, borrowing, lifetimes. En este artículo analizaremos temas y preguntas reales que te harán, y mostraremos ejemplos de código que te ayudarán a superar la entrevista.

¿Listo? Vamos allá.

1. Ownership (Propiedad) — el fundamento sin el cual no puedes avanzar

El primer y más importante bloque. Si no entiendes ownership, no entiendes Rust. En la entrevista, seguramente te pedirán que expliques cómo funciona la transferencia de propiedad y que escribas código que lo demuestre.

Reglas clave de ownership:

\n
• Cada valor en Rust tiene exactamente un propietario.
\n
• Cuando el propietario sale del ámbito, el valor se elimina.
\n
• La propiedad puede transferirse (move) o prestarse temporalmente (borrow).
\n

Ejemplo: ¿qué imprime este código?

fn main() {\n    let s1 = String::from("hello");\n    let s2 = s1;\n    println!("{}", s1); // ¡Error!\n}

Respuesta correcta: error de compilación. s1 se movió a s2, y s1 ya no es válido. El entrevistador quiere escuchar que entiendes la semántica de movimiento (move semantics) y por qué Rust es tan estricto con esto.

2. Borrowing y referencias (Borrowing & References)

Después de ownership, viene borrowing. ¿Cómo tomar una referencia sin quitar la propiedad? Y lo más importante: cómo no violar las reglas del compilador.

Reglas de borrowing:

\n
• Puede haber cualquier cantidad de referencias inmutables (&T).
\n
• Solo puede haber una referencia mutable (&mut T).
\n
• No se puede tener &T y &mut T al mismo tiempo sobre el mismo valor.
\n

Ejemplo: encuentra el error

fn main() {\n    let mut s = String::from("hello");\n    let r1 = &s;\n    let r2 = &mut s;\n    println!("{} {}", r1, r2);\n}

Error: creamos una referencia inmutable r1 y luego una mutable r2. El compilador no lo permitirá. Explicación: esto es una protección contra condiciones de carrera (data races) en tiempo de compilación.

3. Lifetimes (Tiempos de vida) — el tema que asusta a todos

Los lifetimes no son magia. Son anotaciones que ayudan al compilador a entender cuánto tiempo las referencias siguen siendo válidas. En la entrevista, te pedirán que expliques para qué sirven y que escribas una función con parámetros de lifetime explícitos.

Pregunta típica:

Escribe una función que devuelva la cadena más larga de dos. ¿Cómo especificarías los lifetimes?

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {\n    if x.len() > y.len() { x } else { y }\n}

Aquí 'a es un lifetime común que garantiza que la referencia devuelta será válida mientras ambas referencias de entrada sean válidas. El entrevistador valorará si mencionas la elisión de lifetime (lifetime elision) — cuando Rust deduce los lifetimes por sí mismo en casos simples.

4. Enums y Pattern Matching — la potencia de Rust

Rust no tiene null. En su lugar, tiene Option<T> y Result<T, E>. En la entrevista, te pedirán que escribas manejo de errores usando match.

Ejemplo: división segura

fn safe_divide(a: f64, b: f64) -> Option<f64> {\n    if b == 0.0 { None } else { Some(a / b) }\n}\n\nfn main() {\n    match safe_divide(10.0, 0.0) {\n        Some(result) => println!("Result: {}", result),\n        None => println!("Cannot divide by zero"),\n    }\n}

Muestra