Parse a string to integer in Go and Rust with errors

WHAT THIS TESTS: This question probes whether you understand two distinct philosophies of explicit error handling and can map each to correct syntax and caller behavior. Go uses multiple return values where the second element is an error interface, relying on programmer discipline to check it. Rust uses the Result enum to make failure a first-class type that the compiler forces you to acknowledge. The interviewer wants to see that you know the idioms, not just that both languages lack exceptions.

A GOOD ANSWER COVERS: First, the Go function signature should be something like func parseInt(s string) (int, error) and the implementation delegates to strconv.Atoi, returning its (int, error) tuple directly. Second, the Go caller must show the if err != nil pattern, for example v, err := parseInt("42") followed by a conditional return or log. Third, the Rust signature should be fn parse_int(s: &str) -> Result<i32, ParseIntError> and the body should call s.trim().parse::<i32>() which itself returns a Result. Fourth, the Rust caller must demonstrate pattern matching with match on Ok(value) and Err(e), or show propagation with the question-mark operator. It is also worth noting that Rust Result is marked must-use, so ignoring it produces a compiler warning, whereas Go depends purely on convention.

COMMON WRONG ANSWERS: One frequent mistake is inventing a tuple-based error type in Rust instead of using the standard Result enum. Another is suggesting panic or unwrap for normal parsing failures in Rust, which defeats the purpose of the type-safe error model. In Go, a red flag is proposing try-catch semantics or returning only an int and ignoring the error path entirely. Also, showing a Rust caller that does not branch on Ok and Err or use the question-mark operator signals shallow familiarity.

LIKELY FOLLOW-UPS: Expect the interviewer to ask which style scales better when composing many fallible operations. Rust's question-mark operator allows terse propagation through the call stack, while Go requires explicit if err != nil after each step. They may also ask about converting a Result to an Option, or how you would map or and_then over a Result to avoid nested match blocks. A senior candidate might bring up that Go multiple returns compile to efficient multi-value returns at the assembly level, while Rust Result is a tagged union with zero-cost abstraction guarantees.

ONE CONCRETE EXAMPLE: In Go, write func parseInt(s string) (int, error) { return strconv.Atoi(s) } and in main write v, err := parseInt("123"); if err != nil { log.Fatal(err) }; fmt.Println(v). In Rust, write fn parse_int(s: &str) -> Result<i32, ParseIntError> { s.parse::<i32>() } and in main write match parse_int("123") { Ok(v) => println!("{}", v), Err(e) => eprintln!("{}", e) };. These snippets demonstrate that both languages reject hidden control flow, but Rust encodes the contract in the type system while Go encodes it in naming and convention.