Big Tech or Startup? (Why One Engineer Chose Clarisights After Google)

Bhanu Prakash Thandu worked at Google before joining Clarisights' database team. Two years into his journey building specialized data systems at scale, he shares candid insights for engineers weighing offers between big tech and high-growth startups.

You were at Flipkart, then moved to Google in 2021. What were you hoping to find?

I was in a Cloud Infrastructure team at Flipkart, which was stagnating. The broad work for containerisation of workloads with Kubernetes and Istio was being handled by another team. So there wasn't much meaningful work left for us. When a Google recruiter reached out, I thought: great brand value for the resume, chance to work with complex systems and smart people. During team matching, I specifically looked for roles closer to customer and product for a change than the pure infrastructure work I'd been doing.

I ended up on a team building B2B shopping experiences, working on structured data quality and enrichment. We were exploring everything from rule-based systems to LLMs for attribute extraction. Sounds exciting right?

But the reality was different?

Very different. My sub-team was very small. It was also a new team building a new product so there was a lot of groundwork involved. We were supposedly moving like a startup within Google, but the levelling hierarchy meant that at junior levels, you simply don't get much interesting work. I spent most of my time doing groundwork: data exploration, analysis, writing SQL scripts to support other people's design decisions. Not building systems, just supporting decisions.

The opportunities for meaningful work at lower levels were extremely limited, which translated to slow growth trajectory. People were nice but formal. My managers were supportive, but overall it was a combination of levelling hierarchy and limited team scope that made it just an okay experience. In the end, when my team was dissolved during the post-COVID downturn— we were a beta product without real business—I saw it more as an opportunity than a setback.

What were you looking for when you decided to leave?

Wherever I ended up, I wanted to make sure not to join as a junior in a hierarchy with many levels again. I was looking for sophisticated engineering teams. Two things were important: the levelling—if I'm at some junior level, I'll probably get uninteresting work—and teams that actually do interesting work. If there's no interesting work in the team, the level doesn't matter.

How did Clarisights enter the picture?

Larissa reached out and shared some engineering blog posts. The depth immediately caught my attention—this felt like a real engineering culture. I listened to clips of Ashu talking about what they look for in candidates. But honestly, I was sceptical. The interview experience and blogs were so good that I worried the actual work wouldn't match. Plus, I hadn't felt belonging at Google despite the nice people—would a startup be any different?

How did the Clarisights interview compare to big tech interviews?

Completely different. My first technical round with Stefan felt like a daily conversation between engineers. We discussed my compiler project from college, what I liked about past work. We spent maybe fifteen minutes on actual coding problems.

Starting with the culture fit interview was smart. Why waste time if what the candidate wants doesn't match what you can provide? Even the system design round with Ashu was different. I didn't have much systems design experience then, but he evaluated how I approached problems, not whether I reached the perfect solution. The feedback focused on my thinking process, which was refreshing.

What was it like when you actually started?

One week of onboarding, then straight into a real project. My first task involved our custom channels where customers provide data through sheets and other non-native sources. They needed to freeze certain sources—stop ingestion but keep existing data queryable.

The Ruby on Rails codebase was a nightmare, I'll be honest. I have a slight distaste for high-level languages in production-grade code. But navigating that complex codebase and shipping changes was satisfying. The challenge came from dealing with different ingestion frameworks—Airflow, cron jobs—where the criteria for picking channels wasn't unified. I had to understand how all these pieces fit together and make changes across them.

Let's talk about the recent Postgres upgrade project. This seems like something most engineers would never encounter.

Exactly. Most teams use managed database offerings—they'd never handle upgrades themselves. We were on Postgres 12, which was already end-of-life, managing 10+ TB of data. When we tried the standard pg_upgrade utility, it corrupted indexes due to a PG 12 bug. Re-indexing at our scale would mean days of downtime.

So we built a custom solution: logical replication for DML, custom DDL replication using event triggers to a new PG 17 instance, validating data correctness with the old instance while it’s still in service. Small downtime cutover. We dug deep into Postgres internals, improved implementations for scale limitations, and even mitigated a logical replication slot slippage bug in Postgres on the fly. It was quite an adventure.

And the custom interpreter for MorselDB?

We discovered query planning was taking more time than query execution. Our queries operate on dozens of channels and hundreds of columns, creating massive query trees. ClickHouse's interpreter makes multiple passes over these, which gets expensive at our scale.

Since we know our query patterns intimately, we built them directly into a custom interpreter. We skip the intermediate steps—query to AST to plan to execution—and jump straight to building the query pipeline. This is optimization you can only do when you deeply understand your specific use case.

You're also working on fsync implementation for MorselDB. What makes that unique?

While most databases need durability guarantees through fsync, our write-ahead log design is different—one per table instead of one per cluster. This handles our ingestion scale and is only possible because we don't need strong consistency guarantees across tables for our product requirements.

Our transactions have their own WALs and can resume after closed sessions. Providing durability guarantees required thinking from fundamentals—surveying literature, researching fsync behavior for linux systems and ceph filesystem (our storage layer), benchmarking, accounting for different failure scenarios. It's not just implementing a known solution; it's designing for our specific constraints.

What has surprised you most about working at Clarisights?

The peer quality. Coming from big tech, I didn't realize there's a whole spectrum of engineering talent who actively prefer startups. Some have impressive affiliations, but don't be fooled by modest backgrounds—these are driven, excellent engineers.

Also, the mentorship is unparalleled. Even after two-plus years, the depth of technical discussions we have—not just about MorselDB but broader computer science topics—is something I wouldn't get anywhere else.

And the growth opportunities?

Irrespective of level, you work on meaningful problems with real depth. Take Aditya, who joined recently early in his career—he's working on distributed systems nuances, handling service failures and degradation gracefully, currently optimizing MorselDB’s Equi-Join (Fused) implementation. This is not typical early career work!

We have a ton of backlog and future work, which shows the vision here. Almost every system is actively evolving, being matured for specialised product features and long-term maintainability. Every problem involves trade-offs at different layers—not just code, but systems and product. You're not just learning to navigate process like at Google; you're learning to build and ship.

What are the real challenges?

Work-life boundaries get blurred. Not daily, but often enough. There's no way of escaping it.

People often mention "dealing with ambiguity" at startups. What does that mean at Clarisights?

We have clear direction—that's not the issue. It's about making decisions when choices aren't obvious. Based on current data, you might design something one way, but then we onboard a new vertical and things break. The engineering is complex because the product is complex, not because we don't know what we're building.

For someone weighing offers between Clarisights and Google or similar companies, what's your advice?

It depends heavily on personal priorities. If someone is trying to maximise their growth, they should heavily consider Clarisights. There's no question.

Ask yourself: What kind of problems will you solve? What will it take to solve them? That translates to growth opportunities. Here, you'll work on meaningful problems with real depth. Irrespective of level, you're working on problems that help you grow as a software engineer.

Any final thoughts for engineers considering this path?

If you're frustrated by the limitations of big tech, if you want to grow faster than your years of experience would typically allow, if you want more ownership—this is the place to be.

Ready to own your impact? Explore engineering opportunities at Clarisights at careers.clarisights.com