Kotlin Interview Questions 2025 - Crack IT Interview

This article concerns real-time and knowledgeable Kotlin Interview Questions 2025. It is drafted with the interview theme in mind to provide maximum support for your interview. Go through these Kotlin interview Questions to the end, as all scenarios have their importance and learning potential.

To check out other interview Questions:- Click Here.

Disclaimer:
These solutions are based on my experience and best effort. Actual results may vary depending on your setup. Codes may need some tweaking.

1) What does “val is read-only, not immutable” really mean in Kotlin?

val stops reassignment of the reference, but the object it points to can still change state.
Teams often misread val as a guarantee of immutability and ship accidental side-effects.
Prefer immutable data structures for shared state; use copy on data classes when updating.
Document mutability expectations in your models to avoid surprise behavior later.
In concurrent code, mutable state behind a val is still a race condition risk.
Adopt lint rules and code reviews to flag mutable internals behind val.
If true immutability matters, model with immutable types and avoid setters entirely.
Treat val as a starting point, not a full safety net.

2) When would you prefer a data class over a regular class?

When the type represents plain data with identity defined by its properties.
You benefit from auto-generated equals, hashCode, and toString for clarity and logging.
Copy semantics simplify state updates in functional or reactive flows.
Great for DTOs, view state, and domain value objects without behavior.
Avoid stuffing heavy business logic into data classes; keep them lean.
Watch for equality traps if properties hold large collections or mutable fields.
Be explicit about which fields define identity to avoid subtle bugs.
Use regular classes when behavior or invariants dominate over raw data.

3) Sealed classes vs enums — when do you pick one?

Use enums for closed sets of simple constants with tiny, uniform behavior.
Use sealed classes for variants carrying different shapes of data.
Sealed hierarchies model domain events, results, and UI states cleanly.
Pattern matching stays exhaustive, reducing missed branches.
Enums are lighter; sealed classes express richer modeling.
Migration tip: start with enums; graduate to sealed when payloads appear.
Testing becomes clearer with sealed types as each case is explicit.
Choose based on how diverse the per-case data and rules are.

4) Interface defaults vs abstract classes — how do you decide?

If you only need contracts with optional shared snippets, interface defaults fit.
If you need shared state, constructors, or protected members, go abstract class.
Interfaces compose better; abstract classes lock you to single inheritance.
Overusing abstract bases can create rigid hierarchies and testing pain.
Prefer composition and small interfaces over deep inheritance chains.
Keep default methods minimal to avoid hidden coupling.
Evolve from interfaces to abstract classes only when state is unavoidable.
Measure change frequency: volatile domains prefer interface-first.

5) Extension functions — when helpful and when risky?

Helpful to add focused utilities without touching original types.
Great for improving readability of domain-specific operations.
Risky when they hide complex logic or clash with member functions.
Can hurt discoverability if scattered across modules with vague names.
Use for small, pure helpers; avoid side-effects in extensions.
Keep them near the domain they serve to aid maintainability.
Prefer named, clear verbs; avoid magic behavior on core types.
Review collisions carefully in shared libraries.

6) Companion object vs `object` singleton — what’s your design choice?

Companion: attach factory/utility to the class namespace for cohesion.
Standalone singleton: system-wide unique service or cache shared across app.
Companion keeps API discoverable at call sites tied to the type.
Singletons must be used sparingly to avoid hidden global state.
Testability favors dependency injection over hard singletons.
Companion methods are fine for pure helpers; avoid side-effects.
Lifecycle matters: singletons live long, so watch memory and leaks.
Choose the simplest construct that preserves clarity.

7) `var` vs `val` — what team rules actually work?

Default to val; require justification for var.
Allow var in local, short-lived scopes where mutation clarifies intent.
For shared state, model immutable data and recreate via copy.
Review PRs for accidental mutability leaking across layers.
Prefer constructor immutability for domain models.
Immutable inputs reduce defensive copying in APIs.
Document exceptions where mutation is intentional for performance.
Build a small guide with examples to keep consistency high.

8) Data class equality pitfalls — what should you watch?

Equality includes all constructor properties; large collections impact performance.
Mutable fields break the equality contract over time.
Floating-point properties can create counter-intuitive equality results.
Beware reference-type properties that don’t define their own equality well.
Consider excluding non-identity fields from primary constructor.
For performance-critical keys, benchmark equality costs.
If equality needs business rules, prefer custom types over default data class.
Always add tests covering equality edge cases.

9) Value (inline) classes — when do they pay off?

Great for type-safe wrappers like IDs, emails, and money amounts.
Reduce boxing and allocation in hot paths when used correctly.
Encode domain units to prevent parameter mix-ups.
Keep them tiny; large wrappers lose ergonomic benefits.
Interop: be mindful of runtime representation differences.
Logging and serialization need careful adapters for readability.
Benchmarks guide whether the optimization is worth it.
Use where correctness and performance both benefit.

10) `typealias` — useful shortcut or future confusion?

Useful to clarify intent for complex functional or generic types.
Helps unify terminology across teams and modules.
Can hide important details if aliases are too generic or nested.
Avoid chains of aliases that obscure the true type.
Document aliases in a central glossary for newcomers.
Prefer domain-specific names that communicate meaning.
Revisit aliases during refactors to avoid legacy traps.
Use sparingly; clarity beats cleverness.

11) Higher-order functions — what’s the business benefit?

Encourage small, composable units that are easy to reuse.
Reduce boilerplate around common cross-cutting tasks.
Enable expressive pipelines for data processing and UI state.
Improve testability by injecting behavior for scenarios.
But too many layers can hurt debugging and performance.
Keep signatures simple; name lambdas meaningfully.
Avoid capturing broad context to prevent leaks.
Measure readability gains against cognitive load.

12) Variance (`in`/`out`) — how do you explain it to a junior?

out means you can safely read that type out; producers only.
in means you can safely pass that type in; consumers only.
Variance reduces unsafe casts in generic APIs.
Start with simple producer/consumer mental model.
Prefer variance on interfaces used widely across modules.
Don’t force variance if it complicates the API surface.
Use examples like lists (read-only) vs sinks (write-only).
Add type tests that exercise edge cases.

13) Platform types from Java — what’s the risk plan?

Java nullability is unknown, so Kotlin treats it as platform type.
You can accidentally dereference null and crash at runtime.
Normalize at boundaries: validate, sanitize, and wrap early.
Prefer explicit annotations on Java APIs when possible.
Add adapter layers that convert to safe Kotlin types.
Log and monitor boundary failures to catch assumptions.
Write tests around integration seams where platform types enter.
Keep interop agreements documented across teams.

14) Practical null-safety strategy without clutter?

Normalize inputs at API boundaries once, not everywhere.
Use meaningful defaults and domain-specific “empty” types.
Propagate null intentionally only when it means “missing.”
Avoid nested null checks by structuring data and flows better.
Leverage sealed results for “present vs absent” semantics.
Monitor crash analytics for null patterns and fix at source.
Document nullable contracts in the public API surface.
Teach the team consistent patterns for optional data.

15) Exceptions vs returning `Result` — how do you choose?

Use exceptions for truly exceptional, unexpected failures.
Use Result for routine failure you expect callers to handle.
Result makes error paths explicit, improving call-site clarity.
Exceptions integrate better with interop and legacy code.
For libraries, prefer Result to guide consumers toward handling.
Consider logging implications: exceptions carry stack traces.
Keep one approach consistent per layer to reduce confusion.
Base the decision on caller ergonomics and observability.

16) `runCatching` — when is it helpful vs harmful?

Helpful for concise capture of success/failure into a Result.
Works well at edges where you map failures to user messages.
Harmful when it swallows exceptions you should surface or rethrow.
Avoid wrapping huge blocks; target the risky call precisely.
Chain onFailure for logging to avoid silent drops.
Don’t use it to hide control flow; clarity first.
Measure impact on debugging before standardizing team-wide.
Document patterns to avoid misuse.

17) Picking between `let`, `apply`, `run`, `also`, `with`?

Choose based on receiver vs it-parameter and return value needs.
Use a small team guide with two or three preferred options.
Keep calls short; nested scoping functions reduce readability.
Don’t hide side-effects in configuration-style blocks.
Prefer clear naming over clever chaining.
Benchmark readability by how fast a newcomer grasps intent.
Consistency beats micro-optimizing semantics here.
Add lint rules that flag over-nesting.

18) Sequences vs collections — the real trade-off?

Sequences are lazy; they save work for large chains with filters.
Collections are eager; simpler to debug and reason about.
For small data sets, sequences add overhead without benefit.
Avoid mixing sequence and collection back and forth repeatedly.
Profile hotspots; don’t assume laziness equals faster.
Watch for terminal operations that pull entire data anyway.
Choose sequences for streaming pipelines; collections for simplicity.
Keep the code obvious; optimize only where needed.

19) Lazy delegates — where do they shine?

Expensive objects created on first use reduce startup cost.
Great for one-time compute values like configuration or caches.
Thread safety mode matters; pick based on access patterns.
Avoid lazy on hot paths that get initialized immediately anyway.
Mind memory: lazies can hold large graphs longer than needed.
Document lifecycle so deallocation expectations are clear.
Pair with clear ownership to avoid leaks.
Measure with profiling tools, not hunches.

20) Operator overloading — justified or overkill?

Justified for well-known math or domain operations users expect.
Overkill when it hides non-obvious side-effects behind symbols.
Readability drops if operators don’t match mental models.
Prefer named functions for business logic and side-effects.
Keep overloads pure and small for predictability.
Align with domain language your team understands.
Test equality and ordering semantics thoroughly.
Err on the side of explicitness in shared libraries.

21) The delegation pattern — why is it idiomatic in Kotlin?

Language support makes delegation clear and concise.
Encourages composition over inheritance, reducing tight coupling.
Easy to swap implementations for testing.
Great for cross-cutting concerns like caching or logging.
Keeps classes focused and single-purpose.
Overuse can create indirection; keep delegation shallow.
Document what is delegated to avoid surprises.
Measure complexity added against benefits.

22) When do Kotlin DSLs genuinely help?

When domain operations benefit from readable, declarative syntax.
Build pipelines, UI layouts, and configuration are common wins.
DSLs reduce ceremony and guide valid combinations.
They can confuse newcomers if too magical or implicit.
Keep surface area small; domain terms must be crystal clear.
Provide examples and docs right where the DSL lives.
Validate at build or runtime with helpful messages.
Don’t build a DSL where a few functions would do.

23) Reflection — what risks and limits matter most?

Slows startup and can increase memory and method count.
Obscures control flow and complicates static analysis.
Increases attack surface if used for deep access.
Prefer explicit wiring or code generation where possible.
Use minimal reflective entry points with strong validation.
Cache reflective lookups sparingly if you must use them.
Avoid reflection in performance-critical sections.
Keep it out of core business logic.

24) KAPT vs KSP — how do you choose?

KSP is generally faster and more incremental-friendly.
Prefer KSP for new projects or when migrating processors that support it.
KAPT is legacy but still needed for some ecosystems.
Consider team build times; KSP can cut CI minutes.
Evaluate processor maturity and community support.
Prototype both if your stack is mixed and measure builds.
Document migration plan and fallbacks.
Keep the build simple; fewer processors, fewer headaches.

25) Gradle Kotlin DSL — when to adopt?

Improves type-safety and IDE support over Groovy scripts.
A win for larger teams that value refactoring and autocomplete.
Migration can be bumpy if you rely on Groovy-only snippets.
Standardize plugin versions and shared conventions first.
Keep build logic in convention plugins, not scattered scripts.
Measure build performance before and after.
Provide templates and training for the team.
Adopt gradually per module to de-risk.

26) Coroutines vs threads — how do you explain the choice to a manager?

Coroutines are lighter, letting you scale concurrency without many threads.
They simplify async flows with structured cancellation and scoping.
Threads fit when integrating with blocking, legacy APIs.
Coroutines reduce context-switch overhead and boilerplate.
Observability improves with structured hierarchies and scopes.
Migration can be incremental around key async use cases.
Training is needed to avoid misuse and leaks.
Choose based on throughput, latency, and maintenance cost.

27) Structured concurrency — why does it matter?

Scopes tie work to lifecycle, preventing runaway tasks.
Cancellation cascades predictably through child jobs.
Error handling becomes explicit and localized.
Easier to reason about than ad-hoc global jobs.
Debugging improves with clear job hierarchies.
Reduces resource leaks on screen or service changes.
Encourages small, composable async building blocks.
It’s the backbone of reliable coroutine design.

28) Choosing a `CoroutineScope` — what’s your approach?

Scope should reflect lifecycle: UI, request, or service.
Avoid creating scopes inside business functions casually.
Prefer dependency-injected scopes for long-lived services.
Keep parent jobs visible for cancellation and supervision.
One scope per responsibility; don’t reuse across layers.
Expose minimal scope surface to callers.
Document scope ownership and cancellation rules.
Tests should assert proper cancellation behavior.

29) Dispatcher choice — Main, IO, Default — how do you decide?

Main for UI work; keep blocks tiny and responsive.
IO for blocking I/O like files and network calls.
Default for CPU-heavy computations and JSON parsing.
Don’t bounce across dispatchers without reason.
Use flowOn or context switches sparingly and clearly.
Measure thread pool contention under load.
Keep the hot path on one dispatcher when possible.
Team guideline prevents inconsistent choices.

30) Reliable cancellation — how do you make it stick?

Tie all launched jobs to a parent scope with a clear owner.
Check cancellation regularly in long loops or flows.
Avoid swallowing CancellationException without rethrow.
Close resources in finally and cooperative checkpoints.
Don’t mix blocking calls without timeouts.
Add telemetry to watch for jobs that outlive their owners.
Include cancellation tests in CI for critical flows.
Prefer time-bounded operations and backoffs.

31) `SupervisorJob` vs `Job` — when do you use which?

SupervisorJob isolates child failures so siblings can continue.
Regular Job cancels the whole tree on one child failure.
Use supervisor in UI where one widget failing shouldn’t kill others.
Use regular job when consistency demands all-or-nothing.
Don’t hide systemic failures behind supervision.
Log and surface child failures even when supervised.
Document rationale per scope to avoid confusion.
Keep supervision shallow and intentional.

32) Handling exceptions in coroutines — best practices?

Decide per scope whether to fail fast or isolate.
Use structured handlers; avoid global catch-alls.
Convert low-level exceptions into domain errors early.
Log with context: job, coroutine name, and operation.
Don’t mask cancellation as failure; treat separately.
Write tests for retry and fallback paths.
Ensure metrics capture both handled and unhandled errors.
Keep error policies consistent by layer.

33) Cold Flow vs hot stream — how do you pick?

Cold Flow runs on collection; good for on-demand data.
Hot streams push continuously; good for events and state.
Cold simplifies testing and backpressure.
Hot needs buffering and replay decisions.
Use cold for repositories; hot for UI state or bus.
Convert between them at boundaries if needed.
Document whether consumers control execution or not.
Choose the simplest model that fits the data shape.

34) StateFlow vs SharedFlow vs LiveData — what’s your guide?

StateFlow holds a single up-to-date value, ideal for UI state.
SharedFlow is event/multicast with configurable replay.
LiveData is lifecycle-aware in Android legacy stacks.
Prefer StateFlow in new Kotlin-first architectures.
SharedFlow for one-time events; set replay carefully.
Interop with LiveData only where required by platform pieces.
Keep conversion functions small and tested.
Avoid event misfires by documenting replay policies.

35) Handling backpressure in Flow — what works?

Use buffer thoughtfully to decouple producers/consumers.
Apply conflate when only the latest value matters.
Use debounce/sample for bursty UI signals.
Offload heavy operators to flowOn with the right dispatcher.
Keep slow subscribers from blocking hot producers.
Measure drops or merges to ensure no data loss surprises.
Document policies per stream so behavior is predictable.
Test under load to validate assumptions.

36) `flowOn` and `buffer` — when do you apply them?

flowOn changes upstream context for heavy operators.
buffer smooths bursts and prevents backpressure blocking.
Apply both near the hotspot rather than blanket everywhere.
Too many buffers hide timing issues and increase memory.
Keep context switches minimal for readability and cost.
Validate behavior with trace logs in staging.
Pair with explicit dispatcher choices.
Remove when no longer needed after optimizations.

38) Testing coroutines — what lessons stick?

Control time with test facilities to avoid flakiness.
Avoid real delays; use virtual time instead.
Inject dispatchers for deterministic scheduling.
Assert cancellation and completion, not just values.
Keep tests small; one async concern per test.
Use fake repositories or sources to isolate behavior.
Log coroutine names to debug failing tests quickly.
Document test rules for new contributors.

39) Timeouts and retries — what’s your strategy?

Timebox external calls to avoid resource starvation.
Use exponential backoff with jitter to reduce stampedes.
Cap retries; surface meaningful errors to callers.
Don’t retry on caller errors or non-transient failures.
Centralize policies to keep behavior consistent.
Emit metrics for timeouts and retry counts.
Add circuit breakers where systems are fragile.
Test chaos scenarios, not just happy paths.

40) Why is `GlobalScope` a bad default?

It ignores lifecycle and makes cancellation hard.
Leaks work beyond the screen or request that started it.
Undermines structured concurrency principles.
Makes tests flaky and slow to finish.
Telemetry becomes noisy with orphaned jobs.
Prefer scoped launches tied to clear owners.
If you must use global, keep it tiny and documented.
Better: inject long-lived scopes explicitly.

41) Coroutines with lifecycle (e.g., UI) — how do you stay safe?

Tie scope to lifecycle owners so work ends appropriately.
Avoid long jobs in short-lived screens; delegate to services.
Handle rotations or config changes via retained scopes.
Expose immutable state objects to the UI.
Cancel and clean up in lifecycle callbacks.
Keep UI dispatcher usage brief; shift heavy work off main.
Test lifecycle edges like background/foreground.
Monitor for leaked jobs across screen transitions.

42) Thread safety — when do you use Mutex vs atomics?

Use Mutex for protecting multi-step critical sections.
Atomics fit single-variable updates without blocking.
Choose based on contention and fairness needs.
Keep lock scopes tiny and fail-fast.
Avoid mixing multiple locks without clear ordering.
Prefer immutable snapshots to reduce locking.
Measure hotspots before optimizing synchronization.
Document invariants protected by each guard.

43) Parallelism vs concurrency — how do you make the call?

Concurrency overlaps tasks; parallelism uses multiple cores.
Choose parallelism for CPU-bound, chunked workloads.
Choose concurrency for I/O-bound pipelines and latency hiding.
Profile to avoid over-parallelizing and thrashing cores.
Keep batch sizes and context switches tuned.
Measure throughput and tail latency, not averages only.
Let the caller specify policy when needs differ.
Keep code adaptable; don’t hardcode a single mode.

44) Compose with Kotlin — what architectural tweaks matter?

Unidirectional data flow simplifies mental models.
Keep state in view models, not scattered composables.
Small, pure composables aid reuse and testing.
Snapshot states must be consistent; avoid mutable leaks.
Hoist state and events to keep boundaries clean.
Side-effects belong in controlled blocks, not rendering.
Measure recomposition; avoid heavy work in composition.
Document patterns for navigation and theming.

45) Migrating RxJava to Flow — what’s your plan?

Map concepts: Observables to Flow; Subjects to Shared/StateFlow.
Replace operators only where semantics match.
Revisit threading strategies; dispatchers differ from schedulers.
Decide hot vs cold at each boundary explicitly.
Start at the edges; migrate leaf modules first.
Keep bridges minimal and temporary.
Update tests to match backpressure and cancellation semantics.
Communicate changes widely to avoid mixed paradigms.

46) Calling Java from Kotlin — common traps?

Platform null types create hidden NPEs if unchecked.
Checked exceptions in Java need clear handling paths.
SAM conversions help, but can hide allocation costs.
Overloaded methods plus default params can be ambiguous.
Mutable collections interop can surprise with views vs copies.
Annotations on Java APIs improve Kotlin safety.
Write adapters to normalize nullability and threading.
Test interoperability around hot spots.

47) Calling Kotlin from Java — what to watch?

Default parameters don’t translate cleanly; consider overloads.
Top-level functions need clear class names for Java callers.
@JvmStatic and @JvmOverloads improve ergonomics when needed.
Kotlin’s collections are read-only views, not immutable.
Nullability annotations guide Java use; keep them accurate.
Avoid inline/value class surprises in Java usage.
Keep binary compatibility in public libraries.
Provide Java-friendly facades for critical APIs.

48) When are `@JvmOverloads` and `@JvmStatic` justified?

Use @JvmOverloads when Java consumers need multiple overloads.
Use @JvmStatic for cleaner Java calls on companions or objects.
Don’t litter APIs with annotations; target interop hot paths.
Review binary compatibility and method explosion risks.
Prefer explicit overloads for public libraries with stability needs.
Document which surfaces are Java-facing and why.
Verify with Java callers in CI to catch regressions early.
Remove once interop requirements fade.

49) Kotlin Multiplatform — what’s the business case?

Share core logic across platforms to cut duplicated effort.
Aligns product behavior and reduces divergence over time.
Speeds feature delivery once the shared layer is mature.
Requires clear boundaries and platform-specific adapters.
Tooling and hiring maturity must be assessed upfront.
Migration is incremental; start with pure domain modules.
ROI improves when mobile and server share rules.
Track build times and developer experience as KPIs.

50) What should actually live in the KMP shared module?

Pure domain models, validation, and business rules.
Serialization, formatting, and core networking abstractions.
Algorithms and pricing/rules engines with no UI dependencies.
State machines and reducers for predictable behavior.
Avoid platform UI, storage specifics, or device APIs in shared.
Provide expect/actual shims for small platform gaps.
Keep shared API stable and well-documented.
Measure coverage to ensure shared value is real.

51) Serialization choice — how do you pick?

Favor Kotlin-first serializers for data classes and sealed types.
Evaluate performance, binary size, and schema evolution needs.
Consider multiplatform support and community health.
Interoperability with existing services can dictate format.
Keep adapters minimal; avoid deep reflection reliance.
Backwards compatibility policy must be explicit.
Benchmark encode/decode on real payloads.
Ensure good tooling for debugging payloads.

52) Logging and error reporting — your Kotlin principles?

Use structured logs with context, not ad-hoc strings.
Correlate logs with coroutine/job identifiers.
Centralize error mapping from low-level to domain level.
Avoid logging sensitive data; mask consistently.
Integrate with metrics and alerting for trends.
Fail loudly in dev; be graceful in prod.
Make logs actionable with identifiers and links.
Review noisy logs regularly and prune.

53) Performance tuning in Kotlin — what actually moves the needle?

Reduce allocations in hot paths; watch temporary objects.
Prefer immutable snapshots over defensive copies everywhere.
Measure with profilers; don’t chase micro-optimizations blindly.
Choose the right collections and iteration style for data size.
Avoid unnecessary lambdas in tight loops.
Keep reflection and heavy generics off hot paths.
Use caching thoughtfully with clear invalidation.
Track regressions with performance tests in CI.

54) Memory and allocations — how do you keep GC happy?

Minimize long-lived references and caches that never expire.
Avoid capturing large contexts in lambdas or closures.
Prefer small, immutable value objects for sharing.
Release resources on cancellation and lifecycle end.
Batch allocations where pooling helps, but don’t overengineer.
Watch for accidental global singletons holding large graphs.
Profile heap to find leaks early.
Educate the team about ownership and lifetimes.

55) Tail recursion vs loops — what’s your pragmatic view?

Tail recursion can be elegant but depends on compiler support and depth.
Loops are predictable and often faster for large iterations.
Prefer clarity; don’t force recursion where iteration is simpler.
Measure stack and performance for edge cases.
Keep algorithms iterative in critical sections.
Use tail recursion for well-bounded, readable cases.
Watch readability for newcomers unfamiliar with recursion.
Document limits and behavior under large inputs.

56) Modeling with sealed hierarchies — why is it powerful?

Encodes a closed set of domain states or events.
Exhaustive handling reduces missed branches and bugs.
Each case carries its specific data, improving clarity.
Works great with reducers and state machines.
Testing becomes straightforward per case.
Helps documentation by reflecting domain language.
Avoid overly deep hierarchies; keep it flat and readable.
Revisit cases as the domain evolves.

57) Default parameters vs overloads — what’s the trade-off?

Default params keep API surface small and readable in Kotlin.
Overloads help Java callers and explicit documentation.
Too many defaults can create ambiguous call sites.
Public libraries often mix both for interop.
Team rule: defaults internally, overloads for Java-facing APIs.
Keep defaults for non-ambiguous, truly optional values.
Document semantic defaults clearly.
Validate call-site readability during code reviews.

58) Enums with behavior vs sealed objects — which is better?

Enums are compact for uniform, simple behavior.
Sealed objects allow richer per-case data and logic.
Choose enums for stable, small sets; sealed for evolving rules.
Enums integrate nicely with switches and storage.
Sealed types aid testing with explicit case classes.
Avoid cramming complex workflows into enums.
Consider serialization needs before choosing.
Pick the smallest construct that fits change patterns.

59) Common mistakes new Kotlin devs make — what’s your shortlist?

Assuming val implies deep immutability and thread safety.
Overusing scoping functions until code reads like a puzzle.
Ignoring lifecycle with coroutines and leaking work.
Mixing Java null platform types without normalization.
Using global singletons as a quick fix for dependencies.
Copying patterns from other languages without idiomatic tweaks.
Relying on defaults and magic without documentation.
Skipping tests for cancellation and error paths.

60) Your Kotlin design philosophy — what do you emphasize?

Clarity over cleverness; small, explicit APIs win.
Immutability by default; mutation only with a reason.
Structured concurrency as a non-negotiable foundation.
Domain-driven models using sealed types and value objects.
Strong boundaries at interop seams with adapters.
Measure, don’t guess: profiling and telemetry guide choices.
Documentation that matches how the team actually works.
Consistency that helps new hires ship confidently.

Post Views: 22