Code Refactoring Interview Preparation Guide
Essential Reading Materials
Code refactoring interviews for DevOps and SRE positions focus on your ability to improve existing code while maintaining system reliability and operational excellence. Unlike traditional software development roles, these interviews emphasize infrastructure-as-code, automation scripts, and system reliability concerns.
Nowadays companies prefer code refactoring and debugging excercises more over leetcode style interview preparations.
Assessment Criteria
You'll be evaluated on these key areas (this list is not exhaustive):
Behavior Preservation: Do you maintain existing functionality while improving the code's design?
Incremental Approach: Do you refactor in small, reversible steps rather than making sweeping changes?
Code Analysis: Can you identify code smells and design flaws ? More importantly, can you articulate why something is problematic?
Testing Strategy: Do you write or propose tests before or after refactoring, and can you justify your approach?
Technical Communication: Can you justify each refactoring step and name any design patterns you're applying?
Balanced Engineering: Are you improving the code without over-engineering solutions?
Prioritization: Can you identify and focus on the most significant pain points?
Interview Strategy
Prepare for extensive "why" questions. Interviewers will challenge your naming choices, approach selection, and implementation decisions. Quality interviewers will engage in healthy discussions about trade-offs between your proposed changes and alternative approaches.
Remember: you're being evaluated on your thinking process and communication skills as much as (or more than) your adherence to "clean code" principles.
The Refactoring Recipe
1. Start with Behavior Preservation
Before making any changes, ensure you understand the current behavior and have mechanisms to verify it remains intact.
Can you identify and focus on the most significant pain points? It usually the long functions, repeated code or too much commented code blocks
2. Identify and Name Problems
Explicitly identify code smells and design problems. Don't just fix issues—articulate what makes them problematic and propose specific solutions.
3. Narrate Your Changes
Vocalize your thought process throughout the refactoring. Practice this by working through exercises while explaining your reasoning aloud.
4. Refactor in Phases
Make incremental improvements rather than attempting comprehensive rewrites. Each phase should leave the code in a working state.
5. Know When to Stop
Recognize when you've achieved sufficient improvement without over-engineering the solution.
Tips for prioritizing code smells
In 30-45 minutes you won’t be able to refactor entire code. So, work on prioritizing code smells.
Observe codebase for Long functions, Code Duplication : This should be in your priority list
If you see scattered attribute for something , it’s a sign to conver it into a class eg. In following example you can create two `Player` class object instead of passing variables around.
def __init__(self, player1_name, player2_name): self.player1_name = player1_name self.player2_name = player2_name self.p1points = 0 self.p2points = 0 ## Better: def __init__(self, player1_name, player2_name): sefl.player1 = Player(player1_name, 0) sefl.player1 = Player(player2_name, 0)Replace hard-code strings by `enum`
Condense if-else conditions
Comments: When you see comment, remove it or use it to create a method name for wrapping lines below it. If you need a coment ot explain what a block of code does, try extract method.
if the method is already extracted but you still need a comment to explain what it does, use Rename method.
Convert long-parameters list into object
Code Smells Reference
This collection of code smell descriptions serves as a reference for learning and technical coaching. While these descriptions are original, many names derive from Martin Fowler's "Refactoring" 2nd Edition.
For comprehensive information about code smells, consult Martin Fowler's article "Code Smells" and the Wikipedia entry on the topic.
Complete Code Smells List
Alternative Classes with Different Interfaces: Similar classes that serve the same purpose but have different method signatures
Bumpy Road: Code with irregular patterns that make it difficult to follow
Comments: Excessive or outdated comments that indicate unclear code
Data Class: Classes that only hold data without meaningful behavior
Data Clumps: Groups of data items that frequently appear together
Deep Nesting: Code with excessive levels of indentation and conditional blocks
Divergent Change: A class that changes for multiple unrelated reasons
Duplicated Code: Identical or nearly identical code segments in multiple locations
Feature Envy: A method that seems more interested in another class than its own
Global Data: Mutable data accessible from anywhere in the codebase
Insider Trading: Classes that know too much about each other's internal details
Large Class: A class that has grown too large and tries to do too much
Lazy Element: Program elements that don't contribute enough to justify their existence
Long Function: Functions that have grown beyond reasonable length and complexity
Long Parameter List: Functions that require too many parameters
Loops: Traditional loops that could be replaced with more expressive alternatives
Message Chains: Long chains of method calls to navigate object relationships
Middle Man: A class that delegates most of its work to other classes
Mutable Data: Data that can be changed in ways that cause problems
Mysterious Name: Names that don't clearly communicate their purpose
Paragraph of Code: Code blocks that should be extracted into separate methods
Primitive Obsession: Overuse of primitive data types instead of small objects
Refused Bequest: Subclasses that don't use inherited functionality
Repeated Switches: Similar switch statements scattered throughout the code
Shotgun Surgery: Making changes requires modifying many different classes
Speculative Generality: Code designed for future needs that may never materialize
Temporary Field: Instance variables that are only set in certain circumstances
Variable with Long Scope: Variables that remain accessible longer than necessary
Practice Exercises
The Gilded Rose Refactoring Kata is an excellent starting point
Additional Exercise Collections
Refactoring-focused katas: https://kata-log.rocks/refactoring
General coding dojo exercises: https://codingdojo.org/kata/
More katas: https://github.com/orgs/Practice-Katas/repositories
Learning Resources
Video Content
Emily Bache on Youtube - Creator of Gilded Rose
4 Steps to Ace a Coding Interview Challenge | Advice from Refactoring Kata Expert
Smooth Python OO design and coding success | Parrot Refactoring Kata
Safe Refactoring with Martin Fowler's Classic Example | Java Demo
Deeply Nested Complex Conditional Code | Safe Transformations & Refactoring
Gilding the Rose: Refactoring-Driven Development - Kevlin Henney - ACCU 2023
Gilded Rose Refactoring by Andrew Burgess : My favorite video đŸ¤©
Python refactoring exercise "GildedRose" : It’s over refactoring much but you can take some good take aways out of it in python
Books and Articles
Working-Effectively-Legacy-Michael-Feathers : which is good but may be out of scope for just interview prep.
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)
https://philippe.bourgau.net/a-coding-dojo-exercises-plan-towards-refactoring-legacy-code/
Final Advice
Approach refactoring interviews with strong opinions held loosely. Be prepared to discuss trade-offs and alternative approaches. Your ability to think critically about code design and communicate your reasoning clearly will set you apart from candidates who simply memorize refactoring techniques.
Also, since interview will be 45 minutes long at max, so please practice refactoring excercise on coderpad or hackerrank to develop muscle memory and speed.