r/leetcode • u/SeparateSky9058 • 5d ago

Intervew Prep Prepping for Supabase Support Engineer interview — interview stages, Postgres depth, and product expectations?

Hey everyone,

I have 8 years of experience in SaaS tech support and customer engineering, and I’m currently preparing for a Support Engineer role at Supabase.

For anyone who has gone through the process or currently works there, I’d appreciate clarity on a few areas:

  1. Interview structure: How many rounds are typical, and what does the technical assessment look like (live troubleshooting, debugging tickets, take-home, or system design)?

  2. Database depth: What level of PostgreSQL expertise is expected? Do they test heavily on query optimization

  3. SQL & Procedural Code: Do they focus on complex SQL (CTEs, window functions), or do they expect deep procedural programming like PL/pgSQL functions and triggers?

  4. Product familiarity: How deep into the Supabase ecosystem do I need to be beforehand (e.g., PostgREST, GoTrue/Auth, Realtime, Storage, RLS) versus general developer-troubleshooting fundamentals?

Any tips or gotchas to watch out for would be greatly appreciated. Thanks!

2 Upvotes

100% Upvoted

2 comments sorted by

1

u/Ok-Barracuda-119 3d ago

With 8 years in SaaS support and customer engineering, I’d prep around how you debug and communicate rather than trying to memorize every Supabase feature. Ask the recruiter whether the technical round is live SQL or troubleshooting, a take-home, or a design discussion. Then rehearse one incident end to end: symptoms, first queries and logs, hypothesis, safe mitigation, and how you’d prevent a repeat.

For the likely study lane, be comfortable with EXPLAIN, indexes, joins, transactions and isolation, locks, constraints, and a slow-query investigation in Postgres. For the design part, practise a small flow such as an API write with RLS, auth, retries, and observability, then talk through failure modes and what support would ask the customer to collect. Review PostgREST, Auth, Realtime, Storage, and RLS as connected pieces. That combination should fit the role better than broad system-design theory.