PracHub
QuestionsLearningGuidesInterview Prep
|Home/Software Engineering Fundamentals/Google

Plan a Safe Repository-Wide Identifier Migration

Last updated: Jul 18, 2026

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.

  • hard
  • Google
  • Software Engineering Fundamentals
  • Software Engineer

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?

Quick Answer: 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.

Related Interview Questions

  • Deduplicate and Order Batch and Streaming Logs - Google (medium)
  • Build a Custom CompletableFuture: Async Primitive and Parallel Array Processing - Google (medium)
  • Find the Most Frequent IP Addresses in a File Too Large for Memory - Google (medium)
  • Process Sharded Login Logs - Google (medium)
|Home/Software Engineering Fundamentals/Google

Plan a Safe Repository-Wide Identifier Migration

Google logo
Google
Apr 16, 2026, 12:00 AM
hardSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals
1
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...

Browse More Questions

More Software Engineering Fundamentals•More Google•More Software Engineer•Google Software Engineer•Google Software Engineering Fundamentals•Software Engineer Software Engineering Fundamentals

Write your answer

Your first approved answer each day earns 20 XP.

Sign in to write your answer.
PracHub

Master your tech interviews with 8,500+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.