YC Interview Questions About Technical Architecture

Founders who handle technical architecture questions well demonstrate that they built the product themselves, understand the decisions they made and why, and can communicate complex technical choices in plain language.

1. Did you actually build this?

The most basic check. Founders who describe their architecture clearly and specifically — naming the specific database, the specific API design choice, the specific bottleneck they hit and how they resolved it — demonstrate firsthand building experience. Founders who describe architecture at a high level without specific implementation detail raise the question of whether the product was built by them or outsourced.

2. Will it scale to the next milestone?

Partners are not asking whether your architecture will handle a million users. They are asking whether it will handle 10x your current load without a full rebuild. A pre-scale architecture that requires a complete rewrite at 1,000 users is a different concern than one that requires optimization work at 100,000 users.

3. Is there genuine technical moat?

For deeptech, AI, and infrastructure companies, technical architecture is often the primary source of competitive differentiation. Partners probe architecture specifically to understand whether the technical foundation creates a durable advantage or whether a competitor could build an equivalent system in a few months.

"Walk me through your technical stack."

What partners probe: Whether you built it, whether the choices are deliberate, and whether the stack is appropriate for your scale.

Framework: Name the stack components, name why you chose each one, name the specific scale it is designed for.

"Our backend is Node.js with a PostgreSQL database, deployed on Railway. We chose Node because both founders know it well and we wanted zero context switch — we are too early to optimize for theoretical performance gains from a different language. PostgreSQL because our data model has complex relational joins — product inventory, supplier relationships, transaction history — that a NoSQL database would handle awkwardly. Railway because it gave us auto-deployments from GitHub with zero DevOps overhead. We are currently handling 23 customers with about 2,000 daily transactions. This stack handles 10x that without any architectural changes."

"What is the hardest technical problem you have solved so far?"

What partners probe: Whether your hardest problem is genuinely hard, whether you solved it yourself, and what it reveals about your technical depth.

Framework: Name the specific problem, describe the approach you took, name what you tried that did not work before you found the solution.

"The hardest problem was getting WhatsApp message parsing to work reliably at scale. WhatsApp Business API sends messages in several different formats depending on the user's device, message type, and language — there is no guaranteed schema. We had a 12% parse failure rate in month 1 that was silently dropping inventory updates. We tried regex parsing first — fragile. We rebuilt it using a state machine that processes message tokens sequentially rather than pattern-matching the full string. Parse failure rate is now below 0.3%. It took 3 weeks and 4 different approaches before the state machine worked reliably."

"How does your architecture scale if you 10x your current customer base?"

What partners probe: Whether you have thought about scale, whether 10x reveals a fundamental bottleneck, and whether that bottleneck has a clear solution path.

Framework: Identify the specific component that breaks first at 10x, and name the specific solution.

"At 10x — 230 customers instead of 23 — our current single PostgreSQL instance becomes the bottleneck. We would need to add read replicas for our reporting queries, which are currently running on the same instance as write operations. That is a well-understood problem with a well-understood solution — PostgreSQL read replicas on Railway are a 2-hour configuration change. The bigger concern at 10x is our WhatsApp webhook processing — currently single-threaded, which means message processing backs up during peak hours. We would add a message queue (BullMQ on Redis) to handle concurrent processing. Both are 2-4 week projects that do not require architectural changes to the core data model."

"Do you have any proprietary technology or IP?"

What partners probe: Whether there is genuine technical differentiation that creates a moat, or whether the product is built on standard components that a competitor could replicate quickly.

Framework: Be honest about what is proprietary and what is not — partners will probe this directly and overclaiming creates credibility problems.

"Our core stack is standard — Node, PostgreSQL, WhatsApp API. Our proprietary element is our expiry prediction model: we trained a gradient boosting model on 18 months of pharmacy transaction data from our 23 customers to predict which SKUs will expire based on purchase patterns, seasonal demand curves, and historical sales velocity. The model has 91% accuracy in flagging expiry risk 30 days out. A competitor starting today would need 18 months of transaction data from pharmacy customers to train an equivalent model. That data is our moat, not the algorithm itself."

"Have you had any significant technical failures or outages?"

What partners probe: Your honesty, your incident response maturity, and whether you learn from technical failures.

Framework: Name the incident, what caused it, how long it lasted, how you fixed it, and what you changed to prevent recurrence.

"We had one significant outage in week 6 of operating. Our database ran out of disk space — we had not set up monitoring alerts and the PostgreSQL instance stopped accepting writes. 3 customers tried to log inventory updates that failed silently. It was down for 4 hours before a customer WhatsApp-messaged us directly. We restored from backup with no data loss, upgraded our storage, and set up Uptime Robot alerts for disk usage and response time. We have had zero outages since. The incident was embarrassing but it gave us a culture of monitoring discipline we would not have had otherwise."

"Why did you choose [specific technology] instead of [alternative]?"

What partners probe: Whether technology choices were deliberate and considered, or defaults without evaluation.

Framework: Name the alternative you evaluated, the specific criterion that drove the decision, and whether you still believe it was the right call.

"We chose PostgreSQL over MongoDB specifically because our data has strong relational integrity requirements — a pharmacy's inventory record references supplier records, which reference distributor records, which reference transaction records. Foreign key constraints and JOIN performance matter to us. MongoDB's document model would have required us to denormalize data in ways that make our reporting queries significantly more complex. We benchmarked both for our specific query patterns in week 1 and PostgreSQL was 3x faster on our most common query type. I still think it was the right call."

"For AI/ML products: How does your model improve over time?"

What partners probe: Whether the AI product has a genuine data flywheel or whether it is a static model that competitors can replicate.

Framework: Name the specific data generated by product usage, how it feeds back into the model, and the measurable improvement over time.

"Our expiry prediction model improves with every transaction our customers process. Each time a pharmacy owner marks a product as expired, that event becomes a training label — we know the SKU, the purchase history, the seasonal context, and the actual outcome. We retrain the model monthly on the accumulated dataset. Month-1 accuracy was 71%. Month-6 accuracy is 91%. The improvement curve is still steep — we expect to plateau around 94-95% based on the irreducible variability in demand. A competitor entering today with no transaction data would start at our month-1 accuracy and need 6 months of customer data to reach our current performance."

Technical founder being asked about non-technical aspects of architecture

If a partner asks about the business implications of an architectural decision — "does your current architecture support a mobile app?" or "can you white-label this for enterprise?" — the technical founder should answer both the technical and the business dimension: "Yes, our API is designed as a standalone layer. A mobile app would be a 4-week project. We have intentionally not built it yet because our target user — 45-year-old pharmacy owner — does not use apps. If our customer profile shifts toward younger pharmacy managers, the mobile surface is a fast follow."

Non-technical founder being asked about technical architecture

If you are a non-technical founder, acknowledge clearly which founder owns the technical architecture and answer from your actual knowledge, not a bluffed position. "Technical architecture is Rohan's domain — I can give you the headline and he can go as deep as you want. Our stack is Node/PostgreSQL/Railway, we handle 2,000 daily transactions without performance issues, and our biggest upcoming technical project is adding a message queue for concurrent WhatsApp processing." Then hand off to your cofounder.

Technical architecture questions serve as a proxy test for a broader set of founder qualities:

Honesty about limitations. Founders who describe their architecture's current scale limits clearly — "this breaks at X, here is how we fix it" — demonstrate technical maturity and honesty. Founders who claim their architecture is infinitely scalable at any scale reveal either naivety or dishonesty.

Learning speed. The specific technical problems a founder has encountered and solved, and how quickly they resolved them, tells partners about how fast the team learns from operational reality. A specific incident story with a clear resolution demonstrates faster learning than an architecture that has never been stress-tested.

Appropriate complexity calibration. A pre-revenue company that has already built microservices, Kubernetes deployment, and distributed caching is over-engineered for its stage. A company with 10,000 users running on a single unmonitored server is under-engineered for its risks. Partners are looking for architecture that is appropriately complex for the current stage — not too simple, not overbuilt.