Clean Code and Best Practices Questions

Covers the principles and hands on practices that produce readable, maintainable, and reliable code. Core elements include intent revealing and consistent naming, small focused functions and classes that follow single responsibility, avoiding duplication through refactoring and appropriate abstractions, clear structure and separation of concerns, following language specific idioms and style guides, consistent formatting, concise comments that explain nonobvious intent, defensive programming and robust error handling, edge case handling and input validation, use of linters and static analysis, incremental refactoring techniques, and pragmatic trade offs between ideal design and delivery constraints. Interviewers will also probe involvement in code reviews, version control hygiene, code metrics, and how candidates advocate for and teach coding standards to peers.

MediumTechnical

126 practiced

At the code level, what concrete refactorings and coding patterns reduce memory churn and battery usage in mobile apps? Give focused examples for image loading, background work scheduling, large object allocation, and hot loops. Explain why each practice improves performance and maintainability.

Sample Answer

**Approach (brief)** Show concrete refactorings + small code examples (Kotlin/Swift) for image loading, background jobs, large objects, and hot loops. Explain why each reduces allocations, GC pressure, and CPU/wakeups — improving memory and battery.

**Image loading** - Refactor: downsample on decode, use disk+memory caches, reuse Bitmaps/CGImage when possible, avoid full-res in-memory.- Why: reduces heap size and decoding CPU.- Kotlin (Glide reuse):

kotlin

Glide.with(context)
  .asBitmap()
  .load(url)
  .override(targetWidth, targetHeight) // downsample
  .dontAnimate()
  .into(imageView)

- Swift (decode scaled):

swift

let options = UIGraphicsImageRendererFormat.default()
let renderer = UIGraphicsImageRenderer(size: targetSize, format: options)
let scaled = renderer.image { _ in original.draw(in: CGRect(origin:.zero,size:targetSize)) }

**Background work scheduling** - Refactor: batch work, use OS schedulers (WorkManager / BGTaskScheduler), add constraints (unmetered/charging).- Why: fewer wakeups, coalesced network I/O lowers radio power.- Example: WorkManager with ExistingWorkPolicy.REPLACE and setRequiredNetworkType to avoid frequent retries.

**Large object allocation** - Refactor: reuse buffers, pool objects, avoid large temporary collections, prefer streaming/parsing.- Why: avoids large GC pauses and out-of-memory spikes.- Kotlin example:

kotlin

val buffer = ByteArrayPool.get(8 * 1024)
try { input.read(buffer) ... } finally { ByteArrayPool.release(buffer) }

**Hot loops** - Refactor: hoist allocations out of loops, use primitive arrays, avoid creating lambdas/boxed types per iteration.- Why: eliminates per-iteration allocations and JIT/ARC churn.- Kotlin example:

kotlin

val tmp = StringBuilder()
for (i in 0 until n) {
  tmp.setLength(0) // reuse
  tmp.append(data[i])
  process(tmp)
}

**Maintainability notes** - Encapsulate pooling/caching behind interfaces, add metrics and fallbacks for low-memory situations, document lifecycle (cache sizes, eviction). These keep code readable while preserving performance.

EasyBehavioral

65 practiced

Describe how you participate in code reviews to promote clean code. Provide three concrete examples of feedback you give that improve readability, maintainability, and safety in mobile code and explain how you deliver those suggestions constructively to avoid friction with the author.

MediumSystem Design

77 practiced

Design a repository-service-layer pattern for a mobile app consuming REST APIs. Explain how you would structure network calls, handle caching and cache invalidation, map DTOs to domain models, and where to place retry with backoff logic so the UI and view models remain clean and testable.

MediumTechnical

75 practiced

Which code metrics would you track to monitor clean code health in a mobile repository, for example cyclomatic complexity, code coverage, and duplication? For each metric propose a practical threshold and describe a non-blocking remediation workflow when the threshold is exceeded.

Sample Answer

**Metrics to track (why it matters)**

- **Cyclomatic complexity** — measures method/function branching. High complexity = hard-to-test mobile logic (lifecycle, callbacks). - Threshold: <= 10 per function; fail if > 20. - Non-blocking remediation: annotate PR with complexity badge and suggestion card (split method, extract view-model, reduce nested conditionals). Create tech-debt ticket if >20 and assign to next sprint; require a small follow-up refactor in same feature branch if feasible.

- **Code coverage (unit + UI tests)** — ensures business logic and platform-specific behavior are exercised. - Threshold: overall 70% with critical modules (network, auth, payment) >= 85%. - Non-blocking remediation: require coverage delta check (no new coverage regression). For drops, add a “must add tests” checklist to the PR and create lightweight mocks/stubs; schedule deeper coverage improvement tasks in backlog.

- **Duplication (copy-paste)** — increases bugs across iOS/Android or platform variants. - Threshold: file-level duplication < 5%, project-level < 3%. - Non-blocking remediation: flag duplicated blocks in PR, suggest extracting shared component or utility. Log a refactor ticket (tag: cross-platform/shared) and pair with owner to remove duplication in next refactor sprint.

- **Maintainability/Severity hotspots (SonarQube issues, code smells)** - Threshold: zero new blocker/critical issues; maintainability rating A/B. - Non-blocking remediation: block only for security/critical bugs. For code smells, require description and plan in PR; triage weekly and schedule fixes.

**Workflow & tools**- Enforce checks in CI (SonarQube, Danger, Danger-Swift, Danger-Kotlin).- PR policy: fail builds only for security/blocker rules and major regressions (coverage drop >2%, new critical issues). For others, add automated comments, labels, and create tracked backlog tasks.- Use lightweight guardrails: template remediation steps, owner assignment, and dashboard for tech-debt aging.

This balances developer flow on mobile feature delivery with continuous improvement of code health.

MediumSystem Design

73 practiced

For a cross-platform mobile project, outline a module structure that maximizes shared business logic while allowing platform-specific UI and services. Compare two approaches: a shared compiled library (for example Kotlin Multiplatform or shared C++) versus duplicating platform modules with strict interface contracts. List pros and cons that include developer productivity, debugging cost, and binary size.

Sample Answer

**Clarify goals & constraints**- Maximize shared business logic (network, models, validation, persistence, domain rules).- Keep platform-specific UI and services (push, native SDKs, platform UX) separate.- Fit mobile developer workflows (fast iteration, debuggability, reasonable binary size).

**Recommended module structure**- shared-core (pure business logic, no platform deps)- shared-platform-adapters (expect/actual or C++ JNI/bridges for platform services)- android-app (UI, DI wiring, Android-specific services)- ios-app (UI, Swift wrappers, iOS-specific services)- integration-tests (end-to-end using platform runners)

Approach A — Shared compiled library (Kotlin Multiplatform / shared C++)Pros:- High code reuse; single source for logic reduces bugs and feature drift- Faster feature parity across platforms- Easier automated testing of business logic- Smaller dev overhead for new features (one implementation)Cons:- Debugging cross-platform runtime/interop can be harder; stack traces can be less clear- Native binary size may increase (runtime + bridge layers)- Build complexity and CI setup heavier- Platform-specific bugs may require knowledge of both ecosystems

Approach B — Duplicate platform modules with strict interface contractsPros:- Each platform uses idiomatic code and tooling — easier interactive debugging- Potentially smaller binaries (no shared runtime), lean implementations per platform- Simpler builds and faster platform-local iterationCons:- Higher developer cost: duplicate implementation, risk of divergence- Slower feature delivery; more manual sync work and testing- More QA effort to ensure behavioural parity

**Trade-offs (productivity, debugging, binary size)**- Productivity: Shared library > duplicated if team comfortable with KMP/C++; otherwise duplication may be faster short-term.- Debugging cost: Duplication lowest (native tools), shared increases debugging complexity unless good tooling/symbols exist.- Binary size: Duplication often smaller; shared library can bloat binaries due to runtimes and bridging.

**Recommendation**- Prefer shared compiled library for medium+ lifespan apps where business logic is substantial and team invests in KMP/C++ skills. Isolate platform hooks via small adapter interfaces to keep debug surface minimal. For very UI-centric apps or teams lacking cross-platform expertise, duplicate modules with rigorous tests and code-gen to reduce drift.

Unlock Full Question Bank

Get access to hundreds of Clean Code and Best Practices interview questions and detailed answers.

Join thousands of developers preparing for their dream job.