Goldman Sachs Mobile Engineer Interview: Questions, Experience & Prep (2026)

Goldman Sachs is one of the world's top investment banks, and its engineering teams build the internal tools, client-facing apps, and trading platforms that move global markets. The mobile engineering function at Goldman Sachs focuses on building secure, high-performance iOS and Android apps for both institutional clients and internal users. With 287 open roles at the firm as of mid-2026 and 79 Mobile Engineer positions listed across India, this is an active hiring cycle.

The interview process typically runs across several rounds: an initial recruiter call, a technical phone screen, one or more coding rounds, a system design round, and a final behavioural round. Candidates report the process taking anywhere from a few weeks to a couple of months. Goldman Sachs places a premium on engineering rigour, code quality, and an understanding of financial systems, so preparation needs to go deeper than a standard mobile interview.

Technical Questions

1. Explain the iOS or Android application lifecycle in detail. How do you handle state across lifecycle changes?
2. How would you approach securing a mobile app that handles sensitive financial data? What techniques prevent data leakage on a device?
3. Describe how you would architect an offline-first mobile app that syncs data when connectivity is restored. What conflict-resolution strategy would you choose?
4. Walk through how you would build a real-time stock price ticker in a mobile app. Which networking approach would you use and why?
5. How do you approach performance profiling in a mobile app? Describe a time you identified and fixed a UI jank or memory issue.
6. What are the trade-offs between REST, GraphQL, and WebSockets for a financial mobile application?
7. Explain dependency injection in the context of Android (Hilt/Dagger) or iOS. Why does it matter for testability?
8. How would you implement biometric authentication securely in a mobile app handling financial data?
9. Goldman Sachs apps need to support multiple regions and languages. How do you handle internationalisation and right-to-left layouts?
10. Describe a situation where you had to balance a tight deadline with maintaining code quality. What did you prioritise and why?

System Design Questions

1. Design the mobile client for a portfolio-tracking app that shows live P&L, holdings, and transaction history.
2. How would you design a push-notification system for a trading alert app that needs to be reliable and low-latency?

Q: How have you handled a performance issue in a production mobile app?

*Situation:* At my previous company, our Android app was receiving complaints from users that the portfolio screen took several seconds to load, especially on mid-range devices.

*Task:* My responsibility was to diagnose the root cause and deliver a fix without disrupting the existing release cycle.

*Action:* I used Android Studio's CPU and memory profilers to trace the rendering pipeline. I found that the main thread was running a database query on every layout pass. I moved all data-fetching to a background coroutine, introduced a local cache using Room, and replaced the RecyclerView adapter with a DiffUtil-based one to reduce unnecessary redraws.

*Result:* Load time on the portfolio screen dropped noticeably in internal testing. The fix shipped in the next patch release and user complaints about that screen stopped appearing in our support queue. The approach was later adopted as a team standard for all list-heavy screens.

---

Q: Describe a time you had to make a difficult technical trade-off.

*Situation:* Our team was building a real-time chat feature for an internal banking app. The product manager wanted it shipped in the same sprint as two other features.

*Task:* I had to decide whether to use a battle-tested third-party SDK or build a lightweight WebSocket layer ourselves, given the time constraint.

*Action:* I listed the risks of each path: the SDK added a large dependency and had licensing restrictions that legal would need to review, while building in-house gave us full control but would take longer. I presented both options to the team lead with a clear recommendation: build a minimal in-house layer scoped only to what the feature needed, and defer the polished version to the next sprint. I documented the known gaps in a tech-debt ticket.

*Result:* We shipped on time with the minimal implementation. The tech-debt ticket was picked up in the following sprint, and the final solution passed the firm's security review without the licensing concerns the third-party SDK would have triggered.

---

Q: Tell me about a time you improved the security of a mobile feature.

*Situation:* During a code review at my previous company, I noticed that an iOS feature was storing an authentication token in UserDefaults, which is not encrypted by default.

*Task:* I was asked to assess the risk and propose a fix before the feature reached production.

*Action:* I documented the vulnerability: UserDefaults can be read from a device backup if the device is compromised. I moved the token to the iOS Keychain with the 'whenUnlockedThisDeviceOnly' access flag, added a unit test to verify the Keychain call was made, and updated the team's internal security checklist to flag this as a standard check for any credential storage.

*Result:* The fix was merged before the feature shipped. The checklist addition caught a similar issue in a different feature two sprints later, preventing another potential vulnerability from reaching production.

For technical questions, use a 'context, approach, trade-offs' structure. Start by confirming your understanding of the problem, explain the approach you would take, and then name at least one trade-off or alternative you considered. Goldman Sachs interviewers commonly probe the 'why' behind technical choices, so never just describe what you did: explain why you chose it over the alternatives.

For behavioural questions, the STAR format (Situation, Task, Action, Result) works well. Keep the Situation and Task brief, and spend most of your time on Action and Result. Goldman Sachs values ownership and impact, so make sure the Result includes something measurable or observable, even if you describe it qualitatively.

For system design questions, follow a structured flow: clarify requirements and constraints first, then define the data model, then the API layer, and finally the mobile-specific concerns (offline handling, caching, push notifications, security). Candidates report that Goldman Sachs interviewers pay close attention to how you handle failure cases and security, not just the happy path.

A note on financial context: you do not need prior fintech experience to interview well, but showing that you have thought about the sensitivity of financial data (encryption at rest, secure transmission, audit trails) will set you apart from candidates who treat it like any consumer app.

Goldman Sachs engineering interviews are thorough. Based on what candidates typically report, interviewers are looking for a few specific things.

Deep platform knowledge. Interviewers expect you to know how the OS manages memory, threading, and lifecycle, not just how to call the APIs. Be ready to explain what happens under the hood.

Security-first thinking. Given that Goldman Sachs handles sensitive financial data, any design or coding question is an opportunity to show you think about security by default, not as an afterthought.

Clear communication. Goldman Sachs engineers work closely with traders, risk managers, and compliance teams. Interviewers want to see that you can explain a technical decision to a non-technical stakeholder without losing accuracy.

Ownership and initiative. Behavioural questions are not just a formality here. Interviewers look for evidence that you spotted a problem without being asked, proposed a solution, and saw it through. Avoid answers where 'the team decided' and you simply executed.

Code quality and testability. Expect to write clean, readable code and to be asked how you would test it. Knowing the difference between unit, integration, and UI tests in a mobile context, and when to use each, is expected.

Three to four weeks out

Review core mobile fundamentals for your primary platform (iOS or Android): lifecycle, memory management, threading models, and the most common architectural patterns (MVVM, Clean Architecture). Revise data structures and algorithms at the level of a standard coding interview, as Goldman Sachs typically includes a coding round.

Two weeks out

Practice system design with a financial-product lens. Pick a few common Goldman Sachs product types (portfolio tracker, trading alert app, internal dashboard) and sketch out a mobile architecture for each, including offline data handling, authentication, and push notifications. Read publicly available material about how large fintech apps handle security on mobile.

One week out

Prepare several STAR stories from your own experience. Cover at least: a hard technical decision, a performance problem you solved, a time you pushed back on a requirement, and a time you improved a process beyond your direct task. Rehearse these out loud so they flow naturally in the interview.

Day before

Read Goldman Sachs's publicly available engineering blog posts and recent news about their technology initiatives. Having one or two specific references ready for 'why Goldman Sachs' questions shows genuine interest. Review your own resume so you can speak fluently to every line.

If you are actively applying, knok checks 150+ job sites nightly, applies to jobs that match your resume, and messages HR on your behalf, so you can focus your energy on preparation rather than chasing application volume.

Skipping the 'why'. Describing what you built without explaining why you made the technical choices you did is the most common gap candidates report after Goldman Sachs interviews. Every design decision has a reason: say it out loud.

Treating security as an add-on. Candidates who mention security only when directly asked give the impression it is not a natural part of their thinking. Weave security considerations into your answers from the start.

Generic behavioural answers. 'We worked as a team and delivered the project' is not enough. Goldman Sachs interviewers want to know your specific contribution, the constraint you were working under, and the concrete outcome.

Not clarifying system design questions. Jumping into a design without asking about scale, user type, latency requirements, or platform constraints is a red flag. Spend the first few minutes asking good questions before drawing anything.

Over-indexing on one platform. If you list both iOS and Android on your resume, be ready for questions on both. If your experience is primarily on one, be upfront about it early rather than getting caught out mid-round.

Not asking questions at the end. Candidates who have no questions for the interviewer often come across as less engaged. Prepare a few genuine questions about the team's technical challenges, tooling, or how the mobile team collaborates with other engineering groups.