What Android Engineers Actually Do
Android engineers build the applications that users interact with on Android devices—the world's most popular mobile operating system with over 70% global market share. When you open an Android app, tap buttons, scroll through content, or receive a notification, Android engineers designed and built those experiences. They bridge the gap between beautiful designs and functional software, navigating Android's device diversity while delivering smooth, responsive user experiences.
Android Engineering vs. Mobile Engineering
A key hiring decision: should you hire Android specialists or generalist mobile engineers?
When Android Specialists Are Better
- Global reach matters: Android dominates globally (especially emerging markets). If your user base is international, Android expertise directly impacts most of your users.
- Complex Android features: Background processing, widgets, Wear OS, Android Auto, or deep OS integrations require specialized platform expertise.
- Performance on diverse hardware: Budget phones to flagships—Android engineers optimize for real-world device constraints, not just emulators.
- Play Store optimization: Getting featured, managing staged rollouts, handling device compatibility, and navigating Google's policies requires specialized knowledge.
- Enterprise Android deployment: MDM integration, work profiles, managed configurations, and corporate app distribution.
When Cross-Platform Might Work
- Smaller teams needing iOS and Android simultaneously
- Content-focused apps with simple interactions
- MVPs where speed to market outweighs platform optimization
- Internal tools where native polish is less critical
Kotlin vs. Java: The Modern Landscape
Kotlin (Modern Standard)
Kotlin is Google's preferred language for Android development, officially recommended since 2019 and now the standard for new Android projects. It's safer, more concise, and interoperates seamlessly with Java.
What to look for:
- Kotlin 1.8+ experience (current stable version)
- Understanding of null safety, coroutines, and extension functions
- Familiarity with Kotlin Flow for reactive programming
- Experience with Kotlin DSL for Gradle builds
Java (Legacy)
Java was the original Android language and still powers many large-scale applications. Some codebases have millions of lines of Java code.
When Java matters:
- Maintaining legacy codebases (banking, enterprise apps)
- Working with established SDKs that are Java-based
- Teams with strong Java expertise transitioning to mobile
Hiring guidance: Require Kotlin proficiency for all roles. Java is a nice-to-have for roles involving legacy code, but shouldn't be a primary requirement unless your codebase is predominantly Java. All new Android development should use Kotlin.
Jetpack Compose vs. XML: The UI Framework Decision
XML Layouts (Established)
XML layouts with View-based UI is Android's mature approach with 15+ years of development. Most production apps use XML layouts.
Strengths:
- Complete control over every UI element
- Extensive documentation and community resources
- Mature tooling and layout editor support
- Supports all Android versions
When to prefer XML experience:
- Apps supporting Android 5 (API 21) and earlier
- Complex custom UI requirements with heavy customization
- Large existing codebases built with Views
- Teams familiar with traditional Android patterns
Jetpack Compose (Modern)
Jetpack Compose is Google's modern declarative UI toolkit, reaching stable in 2021. It's the future of Android UI development.
Strengths:
- Faster development for standard interfaces
- Built-in Material Design 3 support
- Less boilerplate code than XML
- Better preview support in Android Studio
- Interoperability with existing Views
When to prefer Compose experience:
- New apps targeting Android 7+ (API 24+)
- Rapid prototyping needs
- Teams investing in Google's future direction
- Apps already using reactive patterns
Hiring guidance: Most Android engineers should know XML/Views well and have Compose familiarity. For new apps targeting modern Android versions, Compose experience becomes more valuable. Don't require both at expert level—assess which matters more for your codebase.
Skills by Experience Level
Junior Android Engineer (0-2 years)
Capabilities:
- Build standard Android interfaces with XML or Compose
- Implement basic networking and data persistence
- Follow existing architecture patterns (MVVM, Clean Architecture)
- Write unit tests for their code
- Navigate Android Studio and debugging tools
Learning areas:
- Complex architecture patterns and modularization
- Performance optimization and profiling
- Memory management and leak detection
- Play Store submission process
- Advanced Android SDK features
Mid-Level Android Engineer (2-5 years)
Capabilities:
- Design and implement features independently
- Architect moderate complexity applications
- Debug complex issues including ANRs and memory leaks
- Review code and mentor juniors
- Handle Play Store submissions and staged rollouts
Growing toward:
- System architecture decisions
- Cross-team technical leadership
- Performance optimization at scale
- Technical planning and estimation
Senior Android Engineer (5+ years)
Capabilities:
- Architect complex applications from scratch
- Lead technical direction for mobile teams
- Optimize performance for challenging device constraints
- Mentor and grow other engineers
- Drive technical strategy and tool choices
Demonstrates:
- Business impact awareness
- Cross-functional collaboration
- Technical decision documentation
- Platform expertise and Google relationship
- Incident leadership and prevention
Curiosity & fundamentals
Independence & ownership
Architecture & leadership
Strategy & org impact
Where to Find Android Engineers
High-Signal Sources
- GitHub: Contributors to popular Android libraries (Retrofit, Dagger/Hilt, Coil, Room)
- Play Store: Engineers with shipped apps demonstrate real completion ability
- Android communities: Reddit r/androiddev, Android Dev Discord, Kotlin Slack
- Conference speakers: Droidcon, Android Dev Summit, KotlinConf presenters
- Google Developer Experts: GDEs for Android show exceptional platform expertise
Specialized Talent Pools
| Background | Strengths | Considerations |
|---|---|---|
| Big Tech Android | Scale experience, code quality | May expect large team support |
| Agency Android | Diverse project experience | Depth vs. breadth trade-off |
| Startup Android | End-to-end ownership | May need process structure |
| Indie developers | Product sense, Play Store savvy | Team collaboration experience |
Interview Focus Areas
Kotlin Fundamentals
"Explain the difference between val and var, and what null safety means in Kotlin. How do you handle nullable types?"
- Look for: Understanding of immutability, safe call operators (?.), Elvis operator (?:), let/run/apply scope functions
- Red flag: Can't explain null safety or defaults to using !! everywhere
Architecture Understanding
"How would you structure a new Android app? Walk me through your architecture decisions."
- Look for: Clear separation of concerns, MVVM or Clean Architecture understanding, testability considerations, practical trade-offs
- Red flag: Only knows one architecture pattern or can't explain why
Lifecycle Management
"How do you handle configuration changes and process death in Android?"
- Look for: Understanding of ViewModel, SavedStateHandle, lifecycle-aware components
- Red flag: Never dealt with configuration changes, doesn't understand why they happen
Production Experience
"Tell me about a challenging bug you debugged in a production Android app."
- Look for: Systematic approach, use of crash reporting (Firebase Crashlytics), handling of device-specific issues
- Red flag: Never worked on production apps
Common Hiring Mistakes
1. Requiring Both Compose and XML Expertise
Expecting deep expertise in both UI frameworks is unrealistic for most candidates. Determine which matters more for your codebase and evaluate accordingly.
2. Ignoring Play Store Experience
Many technically strong developers have never navigated Play Store review, handled staged rollouts, or managed Android App Bundles. This experience matters for shipping.
3. Overweighting Algorithm Problems
LeetCode-style problems test general CS skills but not Android engineering. Include Android-specific challenges: debugging ANRs, implementing efficient RecyclerViews, or handling background work.
4. Neglecting Device Diversity
Android runs on thousands of device configurations. Engineers who only test on emulators or flagship phones create fragile experiences. Ask about how they handle device fragmentation.
5. Dismissing Indie Developers
Engineers who've shipped their own apps demonstrate product thinking, full-stack mobile skills, and completion ability. Don't overlook them because they lack big company experience.
Recruiter's Cheat Sheet
Resume Green Flags
- Apps in the Play Store (especially with good ratings and significant downloads)
- Kotlin proficiency clearly stated
- Specific Android frameworks mentioned (Jetpack, Compose, Hilt)
- Experience with CI/CD for Android (Gradle, Fastlane, GitHub Actions)
- Open source Android contributions
- Google I/O or Droidcon attendance
- Play Console and staged rollout experience
Resume Yellow Flags
- Generic "mobile development" without Android specifics
- Only cross-platform experience (React Native, Flutter)
- No shipped apps mentioned
- Java only (unless legacy role)
- Missing Android SDK specifics
- No mention of testing or quality practices
Technical Terms to Know
| Term | What It Means |
|---|---|
| Kotlin | Google's preferred language for Android |
| Jetpack Compose | Modern declarative UI toolkit |
| XML Layouts | Traditional Android UI approach |
| Android Studio | Google's IDE for Android development |
| Gradle | Build system for Android apps |
| Hilt/Dagger | Dependency injection frameworks |
| Room | Android's database persistence library |
| Retrofit | Popular networking library |
| Coroutines/Flow | Kotlin's async programming model |
| MVVM/Clean Architecture | Architecture patterns |
| ANR | Application Not Responding (crash type) |
| ProGuard/R8 | Code shrinking and obfuscation |
| Play Console | Google's app management portal |
| Firebase | Google's mobile development platform |
Developer Expectations
| Aspect | ✓ What They Expect | ✗ What Breaks Trust |
|---|---|---|
| Technical Environment | →Modern development setup, latest Android Studio, CI/CD pipeline with automated testing, and time to address technical debt. Access to real devices for testing across different manufacturers and OS versions. | ⚠Outdated Android Studio versions, no CI/CD, forcing old Gradle versions, or expecting quality without device testing. Telling them the codebase is "modern" when it's 90% Java with no migration plan. |
| Codebase Quality | →Reasonable architecture (MVVM, Clean Architecture), some test coverage, and a path to modernization if legacy code exists. Clear coding standards and code review process. | ⚠God activities, no architecture patterns, zero tests, and no acknowledgment that improvements are needed. Expecting them to "just ship features" without addressing quality. |
| Device Testing Strategy | →Access to diverse test devices (different manufacturers, screen sizes, OS versions), Firebase Test Lab or similar, and understanding that Android is not "one size fits all." | ⚠Only testing on emulators or one flagship phone. Dismissing device-specific bugs as "edge cases." No budget for test devices or cloud testing services. |
| Release Process | →Structured release process with internal testing tracks, staged rollouts, and engineer input on release timing. Understanding of Play Store policies and review requirements. | ⚠Chaotic releases, skipping staged rollouts, blaming engineers for policy violations, or pushing broken builds to 100% of users. Last-minute release demands without considering rollout safety. |
| Growth and Learning | →Google I/O attendance (or budget for sessions), time to explore new Android features, and path to senior/lead roles. Mentorship from experienced Android engineers. | ⚠No learning budget, pressure to use outdated approaches, or dead-end role with no advancement. Being the only Android engineer with no technical leadership support. |