The questions Hasura interviews actually ask, answered the way you would say them out loud. Most of them are really testing whether you have run this in production or only followed a tutorial.
How does Hasura generate an API without resolvers?
It reads your database schema — tables, columns, types, foreign keys — and generates a GraphQL schema from it, then compiles each incoming query directly to SQL. There is no resolver layer because there is nothing to resolve: one GraphQL query becomes one SQL statement.
The follow-up is usually where does the configuration live? Answer: metadata, which is neither in your database nor in your code, and which you should keep in version control.
What happens when a role has no permission on a table?
The best-signal question in the set. The wrong answer is “it returns an empty list” or “a permission error”.
What actually happens: the field does not exist. Permissions shape the schema per
role, so introspection shows that role a smaller API and the query fails validation with
field 'bookings' not found in type: 'query_root'. Access is not filtered out of a shared
schema — each role gets its own.
Do permissions cascade through relationships?
No, and this catches people. Being allowed to read properties does not grant the
related host row; every table is evaluated independently. It is the safe default, and it
is why a nested field silently disappears for one role. The fix is a permission on the child
table.
Related: roles do not inherit either. A host gets nothing from
customer’s rules. Flat, verbose, and impossible to grant something by accident
through a hierarchy.
Why can’t I name my admin role admin?
Because admin is reserved — it is what the admin secret grants, it always has
unrestricted access, and declaring a permission for it is rejected. Name your staff role something
else. A JWT can never carry real admin access, which is the point: full access requires the secret,
not a token.
Is a nested query n+1?
No. A nested relationship compiles to a lateral join inside a single SQL statement, and Postgres
assembles the JSON. You can prove it with the /v1/graphql/explain endpoint.
The honest caveat, which is what a good interviewer wants: a remote relationship — joining to another service — genuinely can be n+1, because it is a network call. Hasura batches where the remote supports it; if the remote only exposes a single-item field, twenty rows mean twenty calls.
How do you handle logic Hasura can’t express?
Two routes. An Action puts your own HTTP endpoint into the same GraphQL schema, so clients see one API. A remote schema merges an existing GraphQL service in.
The stronger answer adds where the line is: if a write is a fact, the generated mutation is fine. If it is a decision — check availability, price it, take payment, send a confirmation — put it behind your own endpoint. Do not push business rules into database triggers to keep everything inside Hasura.
What does an event trigger guarantee?
At least once, not exactly once. The event is written in the same transaction as the data change, so it cannot be lost or fire for a rolled-back transaction — but delivery is retried, so your handler must be idempotent, and ordering is not guaranteed.
Mention that the payload carries both old and new, which is what lets you
react to a transition rather than a state.
How do you keep a client from taking the database down?
A row limit on every public role’s select permission. Without one,
query { properties } with no arguments returns the whole table.
Then: indexes on whatever you have exposed to where and orderBy —
including a trigram index if you exposed _ilike, since a leading wildcard cannot use a
B-tree. Depth and rate limits exist but are Enterprise. And connection pooling, which is the thing
that actually falls over first.
What do you turn off before production?
The question that separates people who have shipped it. Console off, dev mode off — dev mode
leaks generated SQL in error responses. Introspection restricted for public roles. CORS narrowed from
*. The admin secret out of every client and rotated. A least-privilege database user
rather than a superuser. And an audit of the unauthorized role, because that is the one every visitor
on the internet gets for free.
What is the difference between v2 and v3 (DDN)?
On this answer. The v3 details below come from the official Hasura DDN documentation as read on 2026-08-21. Feature availability in DDN is still moving, so check the current matrix before quoting it in an interview.
They are different products, not two releases of one. v2 is a single engine configured through a
console with metadata applied to it live. v3 (DDN) is a supergraph compiled from .hml
files over native data connectors, driven by a CLI, producing immutable builds.
The three specifics that show you have actually looked:
There is no admin secret in v3. API access uses a Cloud PAT.
Cron triggers do not exist and event triggers are still work in progress, so scheduled work has to move out before migrating.
Database migrations are no longer Hasura’s job. hasura migrate
has no successor; you use your own tool and re-introspect.
The concepts survive — roles, row filters, field allowlists, session variables, relationships. The syntax does not.
Would you use Hasura for this project?
The one where “yes, obviously” is the weak answer. Good reasons to: a read-heavy product over a well-modelled relational schema, where a permission model expressed once beats resolvers written many times.
Good reasons not to: heavy write-side business logic, a schema that is not relational, or a team with nobody willing to own database performance — because Hasura makes it very easy to ask expensive questions, and the database is where those land.
That is the track
Twenty lessons, both products, every v2 example run against a real engine. If you want to see the whole v2-to-v3 mapping in one place, it is the table in lesson 18.