Big Assets Infra Android Engineer Interview: Questions, Experience & Prep (2026)

Big Assets Infra currently has 13 open roles, with Android Engineer among its active positions as of July 2026. The company works in infrastructure and asset management, and its Android roles typically sit within teams building tools for field operations, asset tracking, or internal dashboards.

Candidates report a structured process that typically covers core Android knowledge, a coding or design round, and a final discussion with a senior engineer or hiring manager. The process most commonly runs across two to four rounds, held over video call or on-site depending on the candidate's location.

This guide covers the questions most commonly seen in these interviews, frameworks for giving strong answers, and a focused preparation plan you can follow in the weeks leading up to your call.

Interviewers at Big Assets Infra tend to probe both technical depth and practical problem-solving. These are the questions candidates report most frequently.

1. Walk us through how you have architected an Android app from scratch. Which pattern did you choose and why?
2. How do you handle background tasks in Android? What are the trade-offs between WorkManager, JobScheduler, and foreground services?
3. Describe a time you had to optimise an app for battery or memory. What was your step-by-step approach?
4. How do Jetpack Compose and the traditional View system differ? When would you choose one over the other on a new project?
5. Explain the Android activity and fragment lifecycle. How have you used lifecycle-aware components to prevent memory leaks?
6. How do you manage state across configuration changes such as screen rotation?
7. What is your approach to unit testing and UI testing on Android? Which frameworks have you worked with?
8. How do you store sensitive data such as tokens and API keys securely on an Android device?
9. Describe your experience integrating REST or GraphQL APIs. How do you handle network errors and retries gracefully?
10. Big Assets Infra deals with infrastructure tracking. How would you design an Android screen showing real-time asset status for a field engineer with unreliable connectivity?
11. Tell us about a time you disagreed with a technical decision on your team. How did you handle it?
12. How do you keep up with Android platform changes, and how have you adopted a recent API or library in a production app?

Use the STAR format for every behavioural and scenario question. Keep the Situation and Task brief, spend most of your time on the Action, and end with a concrete Result.

---

Q: Walk us through how you architected an Android app from scratch.

*Situation:* My previous team needed to build a field inspection app for engineers visiting remote sites with unreliable internet.

*Task:* I was responsible for the full Android architecture, from the data layer up to the UI.

*Action:* I chose MVVM with a Room database as the local source of truth, synced to the backend when connectivity returned. I used Hilt for dependency injection, Kotlin coroutines for async operations, and kept the ViewModel free of Android framework imports so every unit test could run on the JVM without an emulator.

*Result:* The app handled offline-first scenarios without data loss. New developers could onboard in under a week because the layer boundaries were clear, and the test suite gave the team confidence when shipping updates.

---

Q: Describe a time you optimised an app for battery or memory.

*Situation:* A tracking feature in our app was draining the battery noticeably and users were leaving complaints in reviews.

*Task:* I was asked to reduce background battery usage without removing the feature entirely.

*Action:* I profiled the app using Android Studio's Battery Historian and found that a service was polling location at a very frequent interval even when the app was backgrounded. I migrated the work to WorkManager with a flexible interval and added a check so it only ran when the device was not in battery-saver mode. I also replaced a custom in-memory cache with an LRU cache capped at a reasonable size to reduce garbage collection pauses.

*Result:* Battery usage from the app dropped noticeably in internal testing, and user feedback in reviews improved after the next release.

---

Q: Tell us about a time you disagreed with a technical decision on your team.

*Situation:* The team had decided to use a third-party UI library for a core screen because it looked quick to integrate.

*Task:* I had concerns about the library's maintenance status and its impact on app size, but I did not want to push back without evidence.

*Action:* I spent a day building a small proof of concept using native Jetpack Compose. I put both options side by side in a document showing bundle size impact, dependency risk, and estimated maintenance cost, then shared it before the next sprint planning.

*Result:* The team agreed to go with the native approach. The lead appreciated the structured comparison over a gut-feel objection, and it became a pattern the team reused for future library decisions.

For architecture and design questions: Start with the constraints (scale, connectivity, team size), name the pattern you would choose (MVVM, MVI, Clean Architecture), explain what problem it solves for those constraints, then walk through the data flow from the UI down to the data source. Interviewers want to see that your choices are driven by real trade-offs, not trend-following.

For 'how do you handle X' technical questions: State what the platform provides out of the box, explain when that is enough and when it is not, then describe what you would reach for in each case. For background tasks, for example: simple one-off work fits a coroutine, periodic or deferrable work fits WorkManager, and something that must run while the user sees a notification fits a foreground service.

For behavioural questions: Follow STAR tightly. Keep Situation and Task to two or three sentences, spend most of your time on the Action using 'I' rather than 'we', and end with a concrete Result. If you have a measurable outcome, state it clearly.

For system design questions about asset or infra apps: Address offline-first design early, since field workers often have poor connectivity. Cover local storage (Room), sync strategy (WorkManager with conflict resolution), real-time updates (WebSocket or Firebase), and how the UI reflects loading, error, and empty states cleanly.

Based on what candidates report, Big Assets Infra interviewers look for a few things beyond raw Android knowledge.

Practical experience over theory. They want to hear about real apps you have shipped, real bugs you have debugged, and real trade-offs you have navigated. Answers that stay purely theoretical tend to score lower.

Architecture thinking. Candidates who can explain why they made a structural choice, not just what they chose, stand out. Be ready to defend your decisions and discuss what you would do differently in hindsight.

Ownership mindset. The company works in infrastructure where reliability matters. Interviewers want to see that you take responsibility for quality and testing, not just writing code and handing it off.

Communication clarity. Android Engineers here likely collaborate with backend, design, and operations teams. Interviewers notice whether you can explain a technical idea clearly to someone outside your discipline.

Curiosity about the platform. Knowing about recent Android changes, such as the move toward StateFlow over LiveData or the push to Kotlin-first APIs, signals that you actively keep up with the ecosystem.

Two to three weeks before the interview:
Revise Android fundamentals: lifecycle, Jetpack components, coroutines, and Kotlin idioms. Build or revisit one personal project that uses MVVM or MVI so you have a concrete example ready. Practise explaining your architecture choices out loud, not just writing them down.

One week before:
Prepare three to five STAR stories covering a technical challenge you solved, a time you improved app quality, a disagreement you handled professionally, and a feature you designed end to end. Look into what Big Assets Infra does and think about how Android apps serve field workers or operations teams in the infrastructure and asset management space.

Two to three days before:
Do one or two timed coding exercises focused on Android-relevant problems: RecyclerView adapters, ViewModel state management, or API integration with error handling. Review your answers to the 12 questions listed above and note any gaps in your preparation.

Day before:
Prepare your environment for the video call (stable connection, IDE ready if asked to share your screen). Write down two or three questions to ask the interviewer about team structure, the current tech stack, and what success looks like in the first few months.

If you are still searching for roles while you prepare, knok checks 150+ job sites nightly, applies to jobs that match your resume, and messages HR for you, so your search keeps moving even while you focus on interview prep.

Describing team work as personal work. Interviewers ask what you did, not what your team did. If you use 'we' throughout every answer, they cannot assess your individual contribution. Be specific about your own role in each situation.

Skipping the 'why'. Saying 'I used MVVM' without explaining why you chose it over alternatives tells the interviewer nothing about your decision-making. Always pair a choice with its reasoning.

Overclaiming on performance improvements. If you say the app became 'much faster', an interviewer will ask for specifics. If you do not have them, say 'noticeably faster in user testing' or 'we saw fewer ANR reports after the release.' Vague claims with no grounding come across as hollow.

Ignoring edge cases in design questions. For the real-time asset dashboard question or anything similar, candidates who only describe the happy path score lower. Mention what happens when the network drops, when data is stale, or when the device has limited storage.

Under-preparing behavioural rounds. Many candidates over-invest in coding prep and walk into the behavioural round without structured stories. Interviewers at infrastructure-focused companies often weight communication and ownership heavily, so practise your STAR answers until they feel natural.

Not asking questions at the end. Closing the interview with 'no, I think I am fine' signals low interest. Ask about the team, the tech stack, or what a strong first few months in the role looks like.