Square SWE Interview: Technical Phone Screen Pair Programming Guide

Estimated read time: 8-10 minutes

Summary: The Square SWE technical phone screen or pair-programming round evaluates collaborative implementation, problem solving, debugging, and communication. Square-specific official material supports an engineering pair-programming task.

At a glance

• Stage: Technical phone screen or pair programming.
• Typical duration: 30-60 minutes when reported.
• Likely interviewer: engineer or senior engineer.
• Relevant levels: intern through staff-plus, possible or role-dependent.
• Core signal: collaborative coding, not silent solo problem solving.

What happens in this round

Expect a live technical task where the interviewer can see how you think, code, test, and collaborate. The source includes pair-programming tasks, a bill-splitting app example, simple sorting reports, and debugging or testing during pair programming. Exact questions vary, but the collaboration style is central.

Good pair programming means making your thinking visible without narrating every keystroke. Clarify the requirement, name the small first version, implement cleanly, test it, and invite course correction when tradeoffs appear.

Level-specific expectations

Intern and new grad candidates should focus on fundamentals, clarity, and coachability.

Junior and mid-level candidates should show clean implementation, tests, debugging, and communication.

Senior and staff candidates should add maintainability, product constraints, collaboration habits, and tradeoff reasoning.

Candidate-facing questions to prepare

• Build a small bill-splitting feature that divides a total across people, handles uneven cents, and supports item-level shares.
• Implement transaction grouping by merchant, day, or customer, then add filtering for refunds or failed payments.
• Sort and summarize integer or event data, then explain how your approach changes for streaming input.
• Build a cart total calculator with tax, discounts, and edge cases for invalid items.
• Debug a pair-programming task where tests fail for duplicate records, empty input, or rounding behavior.
• Explain your test plan before running code: normal case, edge case, invalid input, and scale case.
• When the interviewer proposes a different design, talk through the tradeoff and adjust collaboratively.

Strong signals

• Clear requirement clarification and incremental implementation.
• Readable code with tests and edge-case thinking.
• Comfort responding to interviewer suggestions.
• Debugging discipline when a first attempt fails.
• Practical awareness of payments, commerce, rounding, state, and correctness where relevant.

Common failure modes

Coding silently. Pair programming needs a partner-aware rhythm.

Skipping tests. Candidate reports and source synthesis repeatedly point to debugging and testing as important signals.

Overbuilding. Start with the simplest useful version, then extend when the interviewer changes requirements.

How to prepare

• Practice live coding with a partner who can interrupt and redirect you.
• Review maps, arrays, sorting, parsing, rounding, state transitions, and test design.
• Use Square-like data: invoices, sellers, carts, payments, refunds, customers, and transactions.
• Prepare to explain tradeoffs and accept suggestions without losing momentum.
• End with tests and a short note about what would change in production.