Code Smells & Refactoring

Intermediate · 16 min read · Low-Level Design, Concurrency & Code Craft

Recognising smells and removing them with small, safe, named refactorings — with a verified worked example.

Two interview situations need this lesson. In some rounds you're handed existing code and asked to "review and improve it". In every machine-coding round, the interviewer adds a requirement late and watches how you change your own code.

The vocabulary comes from Martin Fowler's Refactoring. Using the names ("this is feature envy; I'll move the method") signals experience and makes your reasoning easy to follow.

The smells that matter most in LLD code

Not every smell must be fixed. Smells are prompts to look closer — sometimes a 30-line method is the clearest form.

A worked example: one method, many smells

This is the kind of code you might be handed (or write in a hurry):

How to refactor safely, under time pressure

Interview questions

• What's the difference between refactoring and rewriting?
• You're handed a 300-line method in a review. Where do you start?
• Isn't introducing interfaces for every rule over-engineering?

Further reading

Key takeaways

• Smells are symptoms; refactorings are small, named, behaviour-preserving fixes.
• The big ones in LLD: long methods, god classes, primitive obsession, repeated type switches, data clumps, feature envy, hidden dependencies.
• Pin behaviour before refactoring; verify after every small step.
• Make the change easy, then make the easy change — and say so in the interview.

Previous: Writing Interview-Grade Code · Next: Schema Design for LLD