Plan a Safe Repository-Wide Identifier Migration

Read the full interview experience this question came from →

Quick Overview

Plan a repository-wide migration from snake case to lower camel case without breaking behavior or public contracts. Cover symbol-aware discovery, explicit exclusions, collision handling, independent validation, staged rollout, and rollback in a large codebase that may span multiple languages.

Plan a Safe Repository-Wide Identifier Migration

Company: Google

Role: Software Engineer

Category: Software Engineering Fundamentals

Difficulty: hard

Interview Round: Technical Screen

# Plan a Safe Repository-Wide Identifier Migration You have a very large repository whose internal variables and function names use snake case. A converter can produce lower camel case for one valid identifier, but the repository is too large for manual review. Design a migration that renames eligible identifiers while keeping the repository working. Some names belong to third-party libraries or generated code and must not change. Public interfaces may require compatibility. Tests and test-package identifiers may themselves be renamed, so simply running a rewritten test suite is not independent proof that behavior is unchanged. ### Constraints & Assumptions - The migration must be repeatable, reviewable in batches, and safe to pause or roll back. - String literals, serialized field names, configuration keys, reflection, and dynamic lookup may resemble identifiers without being ordinary symbol references. - More than one programming language or build target may exist; state the scope you support first. - The goal is semantic preservation, not a blind text replacement. ### Clarifying Questions to Ask - Which languages have reliable parsers and symbol-resolution tools in the repository? - What counts as a public contract: source API, binary API, wire format, configuration, or all of them? - Is generated code reproducible from a source schema? - What independent pre-migration artifacts or integration tests are available? ### What a Strong Answer Covers - Syntax- and symbol-aware discovery rather than global string substitution - Explicit inclusion and exclusion policy for owned, external, generated, and public names - Collision detection, compatibility strategy, and deterministic change manifests - Validation that is independent from the transformed tests - Staged rollout, ownership, observability, and rollback ### Follow-up Questions - How would you detect reflective calls that refer to an identifier by string? - What happens when two original names map to one camel-case name? - How can a public API migrate without breaking existing callers? - Which checks should block an automated batch?

Overview: Plan a repository-wide migration from snake case to lower camel case without breaking behavior or public contracts. Cover symbol-aware discovery, explicit exclusions, collision handling, independent validation, staged rollout, and rollback in a large codebase that may span multiple languages.

Read the full Google Software Engineer interview experience this question came from

|Home/Software Engineering Fundamentals/Google
Google logo
Google
Apr 16, 2026
hardSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
5
0

Plan a Safe Repository-Wide Identifier Migration

You have a very large repository whose internal variables and function names use snake case. A converter can produce lower camel case for one valid identifier, but the repository is too large for manual review. Design a migration that renames eligible identifiers while keeping the repository working.

Some names belong to third-party libraries or generated code and must not change. Public interfaces may require compatibility. Tests and test-package identifiers may themselves be renamed, so simply running a rewritten test suite is not independent proof that behavior is unchanged.

Constraints & Assumptions

  • The migration must be repeatable, reviewable in batches, and safe to pause or roll back.
  • String literals, serialized field names, configuration keys, reflection, and dynamic lookup may resemble identifiers without being ordinary symbol references.
  • More than one programming language or build target may exist; state the scope you support first.
  • The goal is semantic preservation, not a blind text replacement.

Clarifying Questions to Ask Guidance

  • Which languages have reliable parsers and symbol-resolution tools in the repository?
  • What counts as a public contract: source API, binary API, wire format, configuration, or all of them?
  • Is generated code reproducible from a source schema?
  • What independent pre-migration artifacts or integration tests are available?

What a Strong Answer Covers Guidance

  • Syntax- and symbol-aware discovery rather than global string substitution
  • Explicit inclusion and exclusion policy for owned, external, generated, and public names
  • Collision detection, compatibility strategy, and deterministic change manifests
  • Validation that is independent from the transformed tests
  • Staged rollout, ownership, observability, and rollback

Follow-up Questions Guidance

  • How would you detect reflective calls that refer to an identifier by string?
  • What happens when two original names map to one camel-case name?
  • How can a public API migrate without breaking existing callers?
  • Which checks should block an automated batch?
Loading comments...