Block Coding Interview Questions: Square, Cash App & Product Engineering

If you are searching for "Square interview questions" and landing on pages about Block, you are in the right place. The company formerly operated as Square, Inc. and renamed itself Block in late 2021. Square is still very much alive as a brand - it is the seller business - but it now sits alongside Cash App and other units under the Block umbrella.

That structure matters for your preparation. "Interviewing at Block" can mean building software for a coffee shop's checkout counter or for a consumer's phone, and those are genuinely different engineering problems. This guide covers the process as candidates commonly describe it, how the two biggest engineering contexts differ, the practical coding style many candidates report, and the mobile and product instincts worth building. As always, we describe problem types and patterns rather than claiming to publish real interview prompts, because question sets rotate and pattern fluency is what transfers.

The Block interview process, as candidates describe it

Loops vary by business unit, role, level, and platform, and they change over time. The shape below is what candidates most commonly report. Treat it as a starting point and confirm your own steps with your recruiter.

Ask your recruiter early which business the role sits in and whether it is backend, frontend, iOS, Android, or hardware-adjacent. That one answer changes what "relevant example" means for every round that follows.

Two businesses, two engineering contexts

Many candidates prepare for "Block" as one thing. The better move is to understand which side you are joining and let that shape your examples, your design instincts, and the questions you ask back.

Square: engineering for sellers

Square serves businesses - restaurants, retailers, salons, and service providers. The software runs on point-of-sale apps, card readers and other hardware, and web dashboards, and it has to work in a real, busy store. Instincts that fit this context:

• Reliability at the counter. A checkout that stalls costs a seller a sale and a queue of annoyed customers. Talk about what the app does when connectivity drops mid-shift.
• Devices and sync. Several devices in one location may share a catalog, orders, and inventory. Think about how changes propagate and what happens when two devices edit the same thing.
• Business workflows. Orders, modifiers, refunds, tips, inventory counts, staff permissions, and multi-location reporting. These make good modeling exercises.
• The seller is the user. Features should save a small business time, not create more admin. Say how you would know a feature is working for them.

Cash App: engineering for consumers

Cash App is a consumer, mobile-first product for sending money, spending, and managing personal finances. The instincts shift:

• Mobile experience first. Fast launch, smooth scrolling through activity, sensible loading and empty states, and behavior on a weak network.
• Trust and safety. Consumer money apps attract scams and account takeover attempts. Recognising where a flow needs friction - confirmation, verification, clear warnings - shows maturity.
• Onboarding and clarity. A new user should understand what just happened to their money. Clear states and copy are engineering concerns, not just design ones.
• Experimentation. Consumer products iterate on flows constantly, so feature flags, gradual rollouts, and measuring impact are natural discussion points.

The coding bar: practical over puzzling

In terms of pure algorithms, candidates typically describe an easy-to-medium bar. What stands out in many write-ups is the style: rounds that ask you to build a small working thing, extend it as requirements are added, or find and fix a bug, with the interviewer acting more like a collaborator than an examiner. Prepare for both halves:

• Arrays, strings, and hash maps - the backbone of most practical exercises: grouping, lookup, and transformation.
• Sorting and merging - ordering records by time or priority, and merging sorted streams, which shows up whenever you build a feed or a report.
• Trees and graphs - BFS and DFS, hierarchies such as categories or permissions, and dependency ordering.
• Heaps and intervals - scheduling, top-K, and overlapping time ranges such as appointments or shifts.
• Code structure - small classes or modules with clear responsibilities, sensible names, and code that is easy to extend when the next requirement arrives.
• Testing as you go - writing a few quick test cases, including edge cases, is often a visible signal in a practical round.

Our LeetCode patterns guide covers the algorithm range. For the practical half, the best preparation is building small programs end to end in your chosen language, with tests, under a timer.

Mobile and product-minded engineering

Mobile is central to both businesses - seller apps on phones and tablets for Square, and the app itself for Cash App. If you are interviewing for an iOS or Android role, candidates commonly report platform-focused discussion alongside general coding. Be ready to talk through:

• App lifecycle and state. What survives backgrounding, rotation, or the process being killed, and where state lives.
• Networking on bad connections. Timeouts, retries with backoff, showing cached data while refreshing, and never leaving the user unsure whether an action went through.
• Offline behavior. Queueing actions locally and syncing later, with a clear story for conflicts.
• Lists and performance. Paging long activity or order histories, image loading, and keeping scrolling smooth.
• Testing and release. Unit and UI tests, feature flags, and staged rollouts, since a mobile release cannot be rolled back as instantly as a server deploy.

Backend candidates benefit from the same list viewed from the other side: design APIs that page cleanly, return stable ordering, and behave predictably when a mobile client retries on a flaky network.

Here is a small example in that spirit - the kind of practical building block behind an activity screen. It merges newest-first events from several sources into one page and returns a cursor for the next page.

import heapq

def feed_page(sources, limit, cursor=None):
    """Merge newest-first activity from several sources into one page.
    Each source is already sorted by (ts, id) descending.
    cursor is the (ts, id) of the last item the client has already shown."""
    merged = heapq.merge(*sources,
                         key=lambda e: (e["ts"], e["id"]),
                         reverse=True)
    page = []
    for event in merged:
        if cursor is not None and (event["ts"], event["id"]) >= cursor:
            continue                  # already shown on an earlier page
        page.append(event)
        if len(page) == limit:
            break
    next_cursor = (page[-1]["ts"], page[-1]["id"]) if len(page) == limit else None
    return page, next_cursor

The strong answer explains the choices: the id tie-break keeps ordering stable when two events share a timestamp, a cursor survives new items arriving at the top of the feed where an offset would not, and in production each source would be queried for items older than the cursor rather than skipping in memory. Then it adds a couple of quick tests - an empty source, duplicate timestamps, and the last page.

Representative problem types

These are the kinds of problems commonly reported in practical, product-focused loops, described as categories so you prepare the pattern rather than a single prompt:

• Build a small feature in stages. Start with a simple model - an order, a cart, a contact list - and extend it as new requirements are added.
• Records and reporting. Group, sort, and summarise a set of orders, transactions, or events by day, item, or user.
• Feeds and pagination. Merge sorted streams, page through history, and keep ordering stable.
• Scheduling and intervals. Appointments, shifts, or opening hours: overlaps, gaps, and available slots.
• Hierarchies and dependencies. Categories, permissions, or setup steps modeled as trees or graphs.
• Debugging and extending existing code. Read unfamiliar code, find the bug, and fix it without breaking anything else.
• Product design discussion. Multi-device catalog sync for a store, an activity feed, or a notification flow, with follow-ups on offline behavior and failure. Our notification system walkthrough maps well onto that last one.

What interviewers actually score

• Working code. A complete, running solution to a practical problem usually beats a clever partial one.
• Readability and structure. Clear names, small functions, and code that is easy to extend when the interviewer adds a requirement.
• Testing instinct. Writing and running a few cases, including edge cases, without being asked.
• Product judgement. Naming the user, choosing sensible defaults, and noticing where a flow could confuse or harm someone.
• Collaboration. Treating the interviewer as a teammate: thinking out loud, asking clarifying questions, and taking hints well.
• Ownership stories. Behavioral examples where you shipped, measured, and improved something. Our STAR examples guide helps you shape them.

A note on integrity: prepare deeply and reason honestly in the room. Practical, collaborative rounds are especially good at revealing whether someone understands the code they are writing, and follow-up requirements are exactly where a memorised answer stops working.

A realistic two-week prep plan

1. Days 1-4: Core patterns - arrays, strings, hash maps, sorting, and two pointers. Solve easy-to-medium problems, and write a few test cases for each one.
2. Days 5-8: Trees, graphs, heaps, and intervals. Then build two small programs end to end under a timer - for example an order model with modifiers and a report, and an appointment scheduler - adding a new requirement halfway through each.
3. Days 9-11: Context prep. Pick the business you are interviewing for. For Square, sketch multi-device catalog sync and offline checkout. For Cash App, sketch an activity feed with pagination and a send-money confirmation flow. If you are a mobile engineer, walk through lifecycle, offline, and list performance for each.
4. Days 12-14: Behavioral STAR stories about ownership and customer impact, plus a full timed solo mock that includes a practical round where you extend your own code.

FAQ

Is Block the same company as Square?

Yes. The company formerly operated as Square, Inc. and changed its corporate name to Block in late 2021. Square is now one of Block's businesses, focused on sellers, alongside Cash App for consumers and other units. Job postings and interview write-ups may use either name, so search for both when researching.

How hard are Block coding interview questions?

Candidates typically describe a moderate bar in terms of pure algorithms, mostly easy-to-medium, but many report that the rounds feel practical: building a small working feature, extending code across several steps, or debugging, rather than solving a single puzzle. Clean, readable, tested code and clear communication tend to matter more than knowing an obscure algorithm.

How is interviewing for Square different from Cash App?

Square builds for sellers: point-of-sale apps, card readers and other hardware, orders, inventory, and business tools that must keep working in a busy store. Cash App builds for individual consumers: a mobile-first app for sending money, spending, and managing finances, where onboarding, trust, and a polished experience matter. The algorithms overlap, but the product scenarios and follow-up questions often reflect the team, so tailor your examples to the side you are interviewing for.

Does Block ask mobile engineering questions?

For iOS and Android roles, candidates commonly report platform-specific discussion alongside general coding: app lifecycle, state management, networking and caching, offline behavior, list performance, and testing. Backend candidates are less likely to get deep mobile questions but benefit from understanding how their APIs are consumed by mobile clients on unreliable networks.

What topics should I study for a Block software engineer interview?

Cover core data structures and algorithms first: arrays and strings, hash maps, sorting, two pointers, trees and graphs, and heaps. Then practice writing small, well-structured programs with tests, API and data modeling for product features, and behavioral stories about ownership and customer impact. Add mobile fundamentals if you are targeting iOS or Android. Processes vary by team and change over time, so confirm your specific loop with your recruiter.