# Inside the TigerData (formerly Timescale) engineering interview

Source: https://www.techinterview.org/post/3233476179/tigerdata-timescale-engineering-interview/
Updated: 2026-07-12 · techinterview.org

Timescale rebranded to TigerData in 2025, and for once the name change tells you something useful about the interview. This is a database company before it is anything else. The flagship product is a set of PostgreSQL extensions written in C, wrapped by a cloud platform written mostly in Go that runs thousands of Postgres instances for customers. Walk in expecting a generic FAANG algorithm gauntlet and you will have prepped for the wrong exam.

The company started in 2017, built by Ajay Kulkarni and Mike Freedman (a Princeton systems professor whose fingerprints are still on the engineering culture). It is headquartered in New York and the team is remote-first across many time zones. That last detail shapes the loop more than people expect. Because most of the real work happens in design docs and pull requests rather than a conference room, they screen hard for written clarity and whether you can think in public without a whiteboard to hide behind.

## Figure out which track you are interviewing for

The single biggest prep decision is knowing which of two engineering tracks your role sits on, because they test almost completely different muscles.

The database internals track covers roles like Senior Software Engineer, Database Internals. You will be writing C against the Postgres source and the TimescaleDB extension. Expect questions about MVCC, the query planner and executor, background workers, memory contexts, the write-ahead log, and how an extension hooks into Postgres without forking it. If you have never read Postgres source or written a background worker, this track will surface that in about ten minutes.

The platform track covers roles like Senior Backend Engineer, Platform, and other control-plane work. Here the language is Go, and the subject is distributed systems on AWS: how you provision, monitor, upgrade, and scale a fleet of database instances without waking anyone at 3am. Postgres knowledge still helps, but the questions lean toward orchestration, failure handling, and multi-tenancy rather than storage internals.

Some roles blur the two, and the fastest signal is the job description's first three bullets. If they mention C, storage engines, or query execution, prep internals. If they mention Kubernetes, control planes, or fleet operations, prep systems.

## What the loop looks like

The process is fairly compact for a company at this stage, usually five or six conversations after the recruiter. Candidates describe meeting the hiring manager plus a couple of team members, a technical round, a behavioral round, and a closing conversation with senior leadership (sometimes the Chief People Officer, sometimes a founder) about direction and culture. The bar is real, and rejections tend to come from shallow systems reasoning rather than a failed coding puzzle.

| Interview stage | Who runs it | What it tests | Typical length |
| --- | --- | --- | --- |
| Recruiter screen | Talent partner | Background, motivation, remote logistics, comp expectations | ~30 min |
| Hiring manager | The team's engineering manager | Depth of past systems work, why databases, role fit | 45–60 min |
| Coding | One or two engineers | Practical problem in C or Go, edge cases, testing habits | ~60 min |
| Systems design | Senior engineers on the team | Database or distributed-systems design tied to the product | ~60 min |
| Values and behavioral | Cross-team interviewer | Ownership, written communication, handling ambiguity | ~45 min |
| Closing conversation | Leadership (Chief People Officer or a founder) | Culture, company direction, your questions | 30–45 min |

## The coding round is practical, not tricky

This is where Timescale diverges from the LeetCode-heavy shops. The coding interview tends to be a real problem in the language you would actually use on the job, and interviewers care more about how you structure code and reason about edge cases than whether you recalled a clever trick. On the platform side that might be a concurrency problem in Go: build a bounded worker pool, add rate limiting, handle a context cancellation cleanly, and explain what happens when a worker panics. On the internals side it lands closer to systems C, like parsing a binary format, managing memory carefully, or reasoning about who owns a pointer.

They watch for the things that separate senior from mid-level. Do you write a test before declaring victory? Do you handle the empty input and the integer overflow? Can you talk through the time and space cost without being asked twice? Silence while you think is fine. Hand-waving past the hard case is not.

## The systems round is built on their actual product

Expect the design round to circle back to problems TimescaleDB solves, because that is what the interviewers live in every day. A common opener is a schema and query problem: you are storing sensor readings, one row per device per second, billions of rows. Design it so range queries over the last day stay fast while the table grows for years. That question is really probing whether you understand partitioning, and it is the front door to a conversation about how hypertables split one logical table into time-based chunks so the planner can skip everything outside your time range.

From there the interviewer pushes on the parts that get hard at scale. A few of the areas they like to explore:

- How would you keep dashboard queries fast over billions of rows without recomputing everything? (This opens into continuous aggregates, which incrementally refresh a rollup instead of rescanning raw data on every query.)

- Old data is rarely updated but still queried. How do you cut its storage cost? (Columnar compression on cold chunks, which can shrink them by 90% or more, with transparent decompression at read time.)

- You need vector similarity search next to your relational data. Do you add a second database? (A chance to weigh pgvector and pgvectorscale living inside Postgres against a dedicated vector store.)

- How do you upgrade Postgres across thousands of customer instances with no downtime and a safe rollback?

You do not need to have memorized the docs. You need to reason from Postgres fundamentals toward the design they actually shipped, and be candid about tradeoffs. Answering "I would reach for a separate time-series store" is defensible if you can say why, but know that the whole thesis of the company is that you often do not have to.

## The Postgres depth they probe

Whichever track you are on, a working model of Postgres is the thing that separates strong candidates. Interviewers ask why a B-tree index is the default and where it struggles for append-heavy time-series inserts. They ask what MVCC costs you in dead tuples and how vacuum reclaims that space. They ask what actually happens between typing a SELECT and getting rows back, and they will follow your answer into the planner's cost model if you open that door. A candidate who can explain constraint exclusion, meaning how Postgres and TimescaleDB prune irrelevant partitions before touching them, stands out right away, because it is the mechanism underneath the whole product.

## The behavioral round is about how you work remote

Because the team is distributed, the values round leans on ownership and communication more than the usual "tell me about a conflict" script. Expect to be asked about a time you drove a project with no one managing you day to day, how you write things down so async teammates can follow, and how you handled being wrong about a technical call in public. Vague answers land badly here. Bring the specifics: the decision, the data you had at the time, and what you would do differently.

## Comp and how to actually check it

Timescale does not publish a public leveling ladder, and because the team is global the same title can carry very different numbers by location. For US senior engineers, cash base tends to sit in a competitive-startup range rather than a top-of-market FAANG one, with most of the upside coming from equity in a company that has raised at a unicorn-scale valuation. Equity at this stage is real potential and real risk in the same envelope, so weigh the strike price, the current preferred valuation, and your own read on the exit before you treat the paper number as money.

Rather than trust any single figure, cross-check the band on [Levels.fyi](https://www.levels.fyi), read the salary ranges Timescale is legally required to post on its US job listings, and ask the recruiter directly what band the role sits in and how refreshers work. A recruiter who will not discuss the band by the final stage is itself a data point.

## How to prep in the week before

If you are on the internals track, spend your time reading actual Postgres source and the TimescaleDB extension on GitHub, and be ready to explain one nontrivial thing you understood from it. Write a toy background worker or a small extension so the C interview is not your first contact with the API. If you are on the platform track, drill Go concurrency until worker pools and context cancellation are muscle memory, and prepare one distributed-systems story you can go deep on, including what broke and how you found it.

The people who do well here tend to genuinely like databases, not the ones who ground three hundred algorithm problems and hoped. If the idea of chunk pruning and compression ratios sounds tedious to you, that preference will show up in the room, and it is worth knowing that about yourself before you sign an offer to work on storage engines every day.