Block Security Engineer Interview: Questions & Prep (2026)

Block is a global fintech company behind Square, Cash App, and TIDAL, built around the mission of economic empowerment. Its products span point-of-sale hardware, peer-to-peer payments, Bitcoin services, and decentralised identity tools through TBD. Security engineers at Block protect systems that handle real money for a large and growing user base, which means the work cuts across application security, cryptography, infrastructure hardening, and incident response.

As of mid-2026, Block has 233 open roles tracked on knok jobradar, making it one of the more active companies hiring in tech right now. Competition is real, and interviews reflect that. Expect technical depth rooted in fintech threats, scenario-based problem solving, and questions that test whether you can move fast without cutting corners.

Candidates report that Block's interview process typically covers a mix of technical and behavioural questions across one or more rounds. The following questions come up often across levels:

1. How would you do threat modelling for a payment processing flow, such as Cash App's peer-to-peer transfer?
2. Walk me through how you would respond to a production security incident involving customer financial data.
3. Describe a significant vulnerability you discovered. How did you handle disclosure and remediation?
4. How do you balance security requirements with the speed that product teams need to ship?
5. Block handles Bitcoin and crypto assets. What unique security challenges come with protecting private keys and wallets?
6. How would you design a security review process that scales across dozens of engineering teams?
7. What is your experience with PCI-DSS compliance, and how have you worked through a real audit?
8. How would you detect and respond to an account takeover campaign targeting Cash App users at scale?
9. Tell me about a time you had to push back on a design decision because of security risk. How did you get buy-in?
10. What would your first few months in this role look like to build trust with engineering partners?
11. How do you stay current with the threat landscape specific to financial services and fintech?
12. Describe your experience with static analysis, dependency scanning, or DAST tooling inside a CI/CD pipeline.

Q: How would you do threat modelling for a payment processing flow?

*Situation:* At my previous company, we were launching a new mobile payment feature that processed card transactions in real time.

*Task:* I was asked to lead a pre-launch security review before the feature went live to customers.

*Action:* I ran a STRIDE threat modelling session with the backend, mobile, and product teams. We mapped every data flow, identified trust boundaries, and flagged three high-risk areas: token handling on the client side, replay attack potential in the API, and insufficient rate limiting on the transaction endpoint. I wrote detailed mitigation tickets and worked with the team to prioritise them by risk level.

*Result:* We caught two critical issues before launch. The replay attack vector was fixed with nonce-based request signing, and the rate limiting gap was patched before the feature shipped. No security incidents related to those vectors occurred in the months following launch.

---

Q: Walk me through how you responded to a production security incident.

*Situation:* We received an alert late on a Friday showing anomalous API call patterns from a subset of user accounts.

*Task:* I was the on-call security engineer and needed to lead the investigation and coordinate the full response.

*Action:* I immediately contained the affected accounts, pulled logs from our SIEM, and traced the pattern to a credential stuffing attack using credentials leaked from an unrelated third-party breach. I coordinated with the trust and safety team to force password resets, updated our WAF rules to block the attack signature, and drafted a customer communication with the legal and comms teams.

*Result:* We contained the attack within two hours. A post-incident review led us to add breached-credential checks at login, which blocked the same attack vector from working in future campaigns.

---

Q: Tell me about a time you pushed back on a design decision because of security risk.

*Situation:* Our team planned to log full request payloads for debugging, which would have included user PII and partial payment data.

*Task:* I identified this as a compliance and data-exposure risk and needed to get the plan changed before it shipped.

*Action:* I put together a one-page brief showing the specific PCI-DSS clauses the logging would violate, publicly reported fine structures for non-compliance, and two concrete alternatives: structured logging with field-level redaction, or a sandboxed debug environment. I presented this to the engineering lead and the head of product in a focused review session.

*Result:* The team adopted the redaction approach, which shipped without any compliance findings. The brief became a template the team reused for future risk escalations.

For threat modelling questions: Use STRIDE explicitly. Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. Name the framework, then walk through each category for the specific system. Interviewers at security-focused companies appreciate structured thinking over instinct, and naming STRIDE signals you will bring a repeatable process to the team.

For incident response questions: Anchor your answer to a clear sequence: detect, contain, investigate, remediate, communicate, and review. Name specific tools such as SIEM, WAF, and runbooks even in hypothetical scenarios to show operational familiarity. Interviewers want to know you have done this before, not just read about it.

For cross-functional influence questions: Lead with business risk framed in compliance terms or customer impact, not just CVSS scores. Then offer two concrete options so the conversation becomes a decision, not a debate. Showing you make it easy for stakeholders to say yes is the key signal interviewers look for.

Block interviewers typically look for engineers who think in terms of real-world impact, not just severity ratings. Because Block's products handle real money, they pay close attention to whether you understand the downstream consequences of a vulnerability: regulatory exposure, customer trust, and direct financial loss.

They also want to see that you can work with non-security engineers without becoming the person who blocks every launch. Candidates report that a recurring theme in feedback is 'security as a product' thinking: can you make the secure path the easy path for developers?

Finally, Block values written and verbal clarity. Security engineers here write risk briefs, incident reports, and policy documents that reach non-technical audiences. Show that you can translate technical findings into business language without losing the key details.

Week 1: Know what you are protecting. Use Cash App and Square yourself. Read Block's public engineering blog and TBD's documentation. Understanding the products, their user base, and their threat surface makes every answer you give more credible.

Week 2: Practice threat modelling out loud. Pick one of Block's public-facing flows and run a STRIDE analysis as if you were in the interview. Record yourself if it helps. Candidates who can structure their thinking in real time tend to score well in technical rounds.

Week 3: Review the core fintech security topics. PCI-DSS Level 1 requirements, OAuth 2.0 and token security, crypto key management basics, and common fintech attack patterns (credential stuffing, API abuse, SIM swapping) are all relevant to Block's environment.

Week 4: Practice behavioural delivery. Block security engineers are expected to communicate risk clearly to non-technical stakeholders. Practice framing technical issues in business terms. Two mock interviews with a friend or a practice tool will sharpen your delivery before the real thing.

If you want to keep an eye on all open Security Engineer roles at Block while you prepare, knok checks 150+ job sites nightly, applies to jobs matching your resume, and messages HR for you.

1. Talking only about tools, not outcomes. Listing SAST and DAST tools without explaining what you found or fixed signals shallow experience. Interviewers want to hear what changed because of your work.

1. Ignoring the fintech context. Generic security answers that could apply to any industry suggest you have not thought about what makes Block's threat model unique. Tie your examples to financial systems wherever you can.

1. Positioning yourself as a blocker. If your answers frame security as a gate that slows teams down, interviewers flag it. Block wants engineers who help teams ship fast and safely, not ones who add friction.

1. Skipping the business framing. Saying a bug is 'critical' without explaining what an attacker could actually do with it, or what it would cost the company, misses what the interviewer is listening for.

1. Not doing product research. Candidates who cannot name a single Cash App or Square feature in their answers stand out in the wrong way. Spend time with the products before you interview.