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

Goldman Sachs is running 287 open roles as of mid-2026, and security engineering sits at the core of its technology strategy. The firm protects some of the world's highest-value financial transactions, so it looks for security engineers who combine deep technical skills with strong risk communication. Candidates report the process typically runs across 4-6 rounds, mixing coding assessments, security architecture discussions, and behavioural interviews.

The broader Security Engineer market in India listed 628 openings tracked by knok jobradar, with Bangalore leading at 69 postings, followed by Delhi and Pune at 12 each. Goldman Sachs stands out for its emphasis on financial-sector threat models, regulatory awareness (think PCI-DSS and SOX controls), and the ability to make security trade-offs under time pressure.

Salary data for Goldman Sachs security roles in India is limited in public sources. For current figures, check Glassdoor and levels.fyi, which carry self-reported compensation from Goldman Sachs employees.

Goldman Sachs interviewers typically probe both hands-on security skills and your ability to think at scale. Candidates report these questions coming up most often:

1. Walk me through how you would perform a threat model for a real-time trading API.
2. Explain the difference between authentication and authorisation, and give a Goldman Sachs-relevant example of each.
3. A penetration test found a critical SQL injection in an internal tool used by hundreds of internal users. How do you prioritise and respond?
4. How does TLS work, and where can it break down in a financial services context?
5. You notice unusual outbound traffic from a production server late at night. Walk me through your investigation step by step.
6. How would you design a secrets management system for a microservices environment handling sensitive trade data?
7. What is the difference between SIEM, SOAR, and EDR? Which would you recommend for a large bank and why?
8. How do you balance security hardening with the developer velocity that a fast-moving trading technology team demands?
9. Describe a time you had to push back on a business team's request because it introduced unacceptable security risk.
10. Goldman Sachs operates under regulations like PCI-DSS and SOX. How do you make compliance requirements practical for an engineering team?
11. What are the most common vulnerabilities in containerised workloads, and how do you mitigate them?
12. How would you build a zero-trust architecture for a firm where some employees still operate on legacy systems?

Q: Describe a time you identified and fixed a serious security vulnerability under pressure.

*Situation:* My team ran a routine code review for a payment-processing microservice two days before a major product launch.

*Task:* I found a broken access control flaw that could let any authenticated user query another user's transaction history.

*Action:* I raised it immediately with the engineering lead, wrote a temporary middleware fix within three hours, and drafted a post-mortem template so the full team could track the root cause. I also ran a quick search across related services to check for the same pattern.

*Result:* The fix shipped before launch, the vulnerability never reached production, and the post-mortem led to a new code-review checklist that caught two similar issues in the next sprint.

---

Q: Tell me about a time you influenced a non-technical stakeholder on a security decision.

*Situation:* A business unit wanted to move client onboarding documents to a public cloud bucket to speed up a partner integration.

*Task:* The proposed setup had no encryption at rest and relied on obscurity rather than access controls.

*Action:* Instead of saying 'no', I prepared a one-page risk brief showing the regulatory exposure in plain language, then proposed an alternative design using pre-signed URLs with short expiry times. I walked the product owner through both options with a cost comparison.

*Result:* The business unit adopted the secure design, the integration launched on schedule, and the approach became the standard for all partner data-sharing requests going forward.

---

Q: Give an example of how you handled a security incident that turned out to be more complex than it first appeared.

*Situation:* An alert fired for a single failed login on an internal admin portal. Standard triage said it was a false positive.

*Task:* I was the on-call engineer and something felt off. The source IP was a known cloud egress range but the account belonged to a developer who was on leave.

*Action:* I escalated to a full investigation, pulled logs across identity, network, and endpoint layers, and discovered a credential-stuffing attempt that had already succeeded on a lower-privilege account. I locked the affected accounts, rotated credentials, and coordinated with the SIEM team to build a detection rule for the pattern.

*Result:* The attacker did not reach any sensitive data. The new detection rule fired twice in the following month, catching similar attempts early.

Goldman Sachs interviewers typically want structured thinking, not stream-of-consciousness answers. Two frameworks work particularly well here.

STAR (for behavioural questions): Lead with the *Situation* (brief context), then the *Task* (your specific role), then *Action* (what you did and why you chose that approach), then *Result* (measurable or observable outcome). Keep each component tight. Goldman Sachs interviewers reportedly appreciate answers that connect results back to business or risk impact, not just technical outcomes.

Threat Modeling structure (for technical design questions): Start by scoping the system (what are we protecting?). List assets, trust boundaries, and likely attackers. Walk through STRIDE or a similar framework to surface threats. Then prioritise by likelihood and impact. Finish with mitigations and any residual risk you are accepting. This structure signals that you think like a security architect, not just a practitioner.

For incident response questions: Use a Prepare, Detect, Contain, Investigate, Recover, Learn sequence. This mirrors industry-standard incident response and shows Goldman Sachs interviewers that you operate systematically under pressure, which matters a great deal in a trading environment where downtime has direct financial cost.

Based on what candidates report, Goldman Sachs security engineering interviews reward a specific combination of traits.

Financial sector context awareness. Generic security knowledge is not enough. Interviewers want to hear you connect threats to financial services realities: high-frequency trading systems, regulatory mandates, insider threat models, and the cost of downtime in markets.

Clear risk communication. Security engineers at Goldman Sachs frequently present to non-technical audiences. Interviewers look for candidates who can translate a CVE score into a business impact statement without jargon.

Ownership mentality. Goldman Sachs values engineers who 'fix the problem, then fix the process'. Candidates who describe only the technical fix without mentioning what they changed to prevent recurrence tend to score lower.

Depth where it matters. Expect at least one question that goes several levels deep on a topic you mention. If you say 'I used TLS 1.3', be ready to explain the handshake, the cipher suite, and where you would look if the certificate chain broke in a distributed system.

Collaboration under constraints. Security at a major bank means saying yes carefully, not just saying no. Interviewers test whether you can find secure paths that let the business move forward.

A focused 3-4 week plan candidates typically find effective for Goldman Sachs security roles.

Week 1: Core technical refresh. Revise network security fundamentals (TLS, firewalls, DNS security), authentication protocols (OAuth 2.0, SAML, Kerberos), and common vulnerability classes from OWASP. Pick one penetration testing tool you know well and be ready to explain it in depth.

Week 2: Financial sector context. Read publicly available guidance on PCI-DSS, SOX IT controls, and RBI cybersecurity guidelines. Understand what 'compliance' means operationally for an engineering team, not just on paper. Study insider threat scenarios specific to trading environments.

Week 3: System design and architecture. Practice designing secure systems end-to-end: a secrets vault, a zero-trust network, a cloud security posture for a fintech. Use STRIDE to threat-model at least two systems out loud. Practice explaining your designs to a colleague who is not a security specialist.

Week 4: Behavioural prep and mock rounds. Write down 6-8 stories from your career using STAR format. Cover: handling a critical incident, pushing back on a stakeholder, mentoring someone, and a failure you learned from. Practice answering in under three minutes per story. Do at least two timed mock interviews.

knok checks 150+ job sites nightly, applies to roles matching your resume, and messages HR directly on your behalf. If you want to track Goldman Sachs security openings (currently 287 roles open) alongside your prep, it handles the applications while you focus on interview readiness.

Candidates who have gone through Goldman Sachs security rounds often highlight the same avoidable errors.

Staying too surface-level. Saying 'I would use a WAF' without explaining how you would configure it, what it would not catch, and how you would monitor it flags a lack of depth. Go one layer deeper than you think is necessary.

Ignoring the business context. Security answers that start and end with 'block it' or 'patch immediately' without acknowledging deployment windows, change management, or user impact suggest you have not worked in a large enterprise before.

Overclaiming on tools. Listing many security tools on your resume invites deep questions on all of them. Mention only tools you can defend in detail. Honesty about gaps is respected more than a wide but shallow skill list.

Weak incident response structure. Vague answers like 'I would investigate the logs' without a clear sequence lose points fast. Practice a structured response narrative before the interview.

Not asking good questions. Goldman Sachs interviewers typically judge candidate curiosity. Candidates who ask generic questions like 'what does a typical day look like' miss the chance to show domain knowledge. Ask about the specific threat categories the team focuses on, or how the security team measures its own effectiveness.