Strconv Package
Fast recall
Quick revision
Core answer
Whether you understand Strconv Package beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
The string↔number boundary is strconv — parsing and formatting, always explicit:
n, err := strconv.Atoi("42") // string → int (error on bad input)
f, err := strconv.ParseFloat("3.14", 64) // string → float64
s := strconv.Itoa(7) // int → string (can't fail)Executed. Atoi on a bad string returns (0, error) — the comma-ok discipline.
Why Atoi and not a cast: Go conversions (float64(i), string(rune)) transform between representable forms; string→number is PARSING — the input can be invalid — so the API must answer 'did it work.' Hence (value, error).
The rest of the kit: ParseBool, ParseInt with base ("ff" in base 16), FormatFloat with verb ('f', 'e'), and the append-family (AppendInt onto []byte — allocation-free, what encoding/json uses internally).
The classic bug pair: Sprintf("%d") instead of Itoa (works, 3-5x slower); and string(n) instead of Itoa — string(65) is "A" (the RUNE 65), not "65" — the #1 beginner Go bug, which go vet flags.
Strconv Package
Direct Answer
strconv.Atoi("42") string→int (returns error); strconv.Itoa(7) int→string. NOT casting — parsing. ParseFloat, ParseBool, ParseInt(base) for the rest. The classic bug: string(42) is "*" (a RUNE), not "42".
Deep Dive & Architecture
Why this isn't a language cast — the categories: Go conversions (T(x)) transform between types whose REPRESENTATIONS are compatible (int→float64: widening; []byte↔string: encoding copy; named↔underlying: reinterpretation) — all compile-time-decidable. Parsing reads a TEXT FORM of unknown validity — "4x2" has no int value — so it's a function returning (value, error), not a conversion. Formatting writes a text form — can't fail for ints (Itoa).
The append-family and why it exists: strconv.AppendInt(buf, n, 10) formats onto an EXISTING []byte — no string allocation, reusable buffer. In hot paths (JSON encoders, loggers), the append-forms are why strconv shows up in every fast-formating library — encoding/json's own int encoder is AppendInt. The allocation chain of Itoa (format into temp → allocate string → copy) becomes one buffer write.
The string(n) trap, fully: string takes a rune (int32 code point) and yields its character — string(65) is "A", NOT "65". The beginner writes string(userCount) and gets a rune-jumble (42 becomes '*' — code point 42). go vet has a dedicated check for this, and the classic writeups call it one of Go's most common first-week bugs — silent wrong text, no error. The discipline: number→string is ALWAYS Itoa/Sprintf, never string().
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Strconv Package in a real project?
- How would you compare Strconv Package with an alternative?
- What is a common mistake when using Strconv Package?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.