At Tellius, a Software Engineer plays a pivotal role in redefining how organizations interact with cloud-scale enterprise data. The company is at the forefront of decision intelligence, building an innovative platform that allows users to query billions of records using a natural, ChatGPT-like interface. As an engineer here, you will design and implement the robust infrastructure that translates complex natural language queries into optimized, actionable insights. Your work will directly impact how business leaders, analysts, and data scientists uncover hidden drivers and trends within their data. You will be tasked with solving highly complex technical challenges, such as optimizing real-time data pipelines, grounding large language models (LLMs) in structured business logic, and orchestrating sophisticated AI agents. Whether you specialize in backend systems, frontend user interfaces, or AI engineering, your contributions will help shape a new category of agentic business intelligence. This role requires a unique combination of technical depth, product intuition, and adaptability. Working in a fast-paced, high-ownership startup environment, you will collaborate closely with product managers, AI researchers, and design partners. The systems you build must not only handle massive scale but also remain highly performant and intuitive for non-technical users.
Initial Screening
reportedAlign on expectations and technical background through an initial screening phase.
What to demonstrate
- Align on expectations and technical background through an initial screening phase
- Depth in Python
How to prepare
- Be able to walk your CV end to end in two minutes, and say why this company specifically.
- Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
Technical Assessments
reportedParticipate in deep-dive technical assessments tailored to your engineering focus.
What to demonstrate
- Participate in deep-dive technical assessments tailored to your engineering focus
- Depth in Python
How to prepare
- Answer aloud and timed: How would you optimize a high-frequency data grid in React.js to prevent unnecessary re-renders when rendering thousands of rows?
- Answer aloud and timed: Walk through the process of lazy loading components and how it impacts initial page load performance.
Hands-on Coding Sessions
reportedEngage in intensive hands-on coding sessions relevant to your domain, such as React.js for frontend candidates.
What to demonstrate
- Engage in intensive hands-on coding sessions relevant to your domain, such as React.js for frontend candidates
- Depth in Python
How to prepare
- Answer aloud and timed: How do you manage global state in a complex single-page application, and what are the trade-offs of using Context API versus external state libraries?
- Answer aloud and timed: Design a database schema for an enterprise analytics dashboard that tracks user interactions and report generation.
Architectural Discussions
reportedDiscuss architectural concepts and alternative engineering approaches during technical rounds.
What to demonstrate
- Discuss architectural concepts and alternative engineering approaches during technical rounds
- Depth in Python
How to prepare
- Answer aloud and timed: How would you optimize a slow-running SQL query containing multiple joins and aggregations over a table with millions of records?
- Answer aloud and timed: Explain the concept of database indexing, including the trade-offs between B-Tree indexes and Hash indexes.
Final Offer Stage
reportedTransition to the final offer stage after completing the technical evaluations.
What to demonstrate
- Transition to the final offer stage after completing the technical evaluations
- Depth in Python
How to prepare
- Answer aloud and timed: How do you handle concurrency and race conditions in a distributed backend system?
- Answer aloud and timed: Describe how you would build a scalable API in Python to ingest and process large batches of analytical data.
PracHub editorial advice for the preparation topics above.
Emphasize Optimization
Do not stop at a working solution. During coding rounds, proactively discuss how you would optimize your code for memory, rendering performance, or database query execution.
Showcase Startup Agility
Tellius operates with high ownership and speed. Highlight past experiences where you took a vague product requirement, designed the technical solution, and drove it to completion.
Be Collaborative
Treat your interviewer as a peer. Talk through your thought process out loud, ask clarifying questions before writing code, and welcome constructive feedback.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the difference between the Virtual DOM and the real DOM, and describe how React's reconciliation algor
Explain the difference between the Virtual DOM and the real DOM, and describe how React's reconciliation algorithm works.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
How do you handle concurrency and race conditions in a distributed backend system?
How do you handle concurrency and race conditions in a distributed backend system?
Approach
- Say what the runtime actually does before reasoning about the code.
- Name what is shared across threads and what owns each piece of state.
- Identify the window where an invariant is briefly untrue.
- Distinguish a value from a reference to it, and say which one you handed out.
Follow-up
- What happens if two callers reach this at the same time?
- Where could this allocate more than you expect?
Identify the heaviest tenants in a five-minute window under memory pressure
The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.
Approach
- Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
- Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
- State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
- Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.
Follow-up
- The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
- Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?
How would you optimize a slow-running SQL query containing multiple joins and aggregations over a table with m
How would you optimize a slow-running SQL query containing multiple joins and aggregations over a table with millions of records?
Approach
- Name the grain you start from and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which index the query would use, and what makes it unusable.
- Handle the rows that do not match: that is usually the actual question.
Follow-up
- How does the query change if that join becomes one-to-many?
- What happens to this when the table is ten times larger?
What strategies do you use to evaluate and benchmark the accuracy of an LLM-powered query generation system?
What strategies do you use to evaluate and benchmark the accuracy of an LLM-powered query generation system?
Approach
- Name the grain you start from and join outward from it.
- Check whether any join is one-to-many before aggregating, or the sums inflate.
- Say which index the query would use, and what makes it unusable.
- Handle the rows that do not match: that is usually the actual question.
Follow-up
- How does the query change if that join becomes one-to-many?
- What happens to this when the table is ten times larger?
Implement a custom autocomplete search component in React.js that fetches data from a mock API and includes de
Implement a custom autocomplete search component in React.js that fetches data from a mock API and includes debouncing.
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
How would you optimize a high-frequency data grid in React.js to prevent unnecessary re-renders when rendering
How would you optimize a high-frequency data grid in React.js to prevent unnecessary re-renders when rendering thousands of rows?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Walk through the process of lazy loading components and how it impacts initial page load performance.
Walk through the process of lazy loading components and how it impacts initial page load performance.
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
How do you manage global state in a complex single-page application, and what are the trade-offs of using Cont
How do you manage global state in a complex single-page application, and what are the trade-offs of using Context API versus external state libraries?
Approach
- Say who the caller is and what they do when the call fails halfway.
- Define the identity of a request so a retry cannot double-apply it.
- Separate accepted, pending, failed and confirmed; they are different facts.
- Design the error taxonomy before the success shape; callers branch on it.
Follow-up
- What happens if the caller retries after a timeout?
- How does a client discover it is on an old version of this contract?
Design a database schema for an enterprise analytics dashboard that tracks user interactions and report genera
Design a database schema for an enterprise analytics dashboard that tracks user interactions and report generation.
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
Explain the concept of database indexing, including the trade-offs between B-Tree indexes and Hash indexes.
Explain the concept of database indexing, including the trade-offs between B-Tree indexes and Hash indexes.
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Describe how you would build a scalable API in Python to ingest and process large batches of analytical data.
Describe how you would build a scalable API in Python to ingest and process large batches of analytical data.
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
How do you ground a large language model (LLM) in structured enterprise data to prevent hallucinations?
How do you ground a large language model (LLM) in structured enterprise data to prevent hallucinations?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Describe how you would architect a multi-step AI agent workflow using frameworks like LangChain or LlamaIndex.
Describe how you would architect a multi-step AI agent workflow using frameworks like LangChain or LlamaIndex.
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
Explain how vector databases work and how you would design a retrieval-augmented generation (RAG) pipeline.
Explain how vector databases work and how you would design a retrieval-augmented generation (RAG) pipeline.
Approach
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the read and write paths separately; they rarely have the same bottleneck.
- Choose a partition key and say what query it makes expensive.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- How does this behave when that dependency is down for an hour?
How do you manage latency and token usage when building interactive, agentic applications?
How do you manage latency and token usage when building interactive, agentic applications?
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- Say what you would check first and why it is the highest-information step.
- Work from the requirement backwards to the design.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Listing latency scales with page size, not with filters
The tenant listing endpoint reads resource filtered by tenant_id and status, ordered by updated_at DESC, and returns each row plus the owner's display name from app_user and the actor of that resource's latest resource_revision. p99 is 55 ms at 10 rows per page and 1.4 s at 200. Database telemetry shows 401 statements per request, each under 1 ms, and nothing in the slow-query log. Diagnose the cause and give the fix, stating the statement count per request and the p99 you expect afterwards.
Approach
- Read the counters before forming a theory. 401 statements for 200 rows is one driver query plus two per row, and sub-millisecond execution with an empty slow-query log rules out a bad plan. The time is round trips, which is why it is invisible in every per-query metric and scales with rows returned rather than with filter selectivity.
- Name the two per-row statements from their normalised text: a single-row app_user lookup by user_id, and a resource_revision lookup by resource_id ordered by version DESC LIMIT 1. Confirm by dropping those two response fields and watching the statement count fall to one. That locates the calls in the serialisation layer, not the repository.
- Check that the arithmetic accounts for the whole gap. Measure one round trip to the replica in isolation; 400 trips at roughly 3 ms of network plus 0.2 ms of execution is about 1.3 s on top of a 55 ms baseline, which matches. If the multiplication had fallen short, the N+1 would only be part of the story and you would keep looking.
- Batch both lookups. Collect owner_user_ids and resource_ids from the driver query, then issue WHERE tenant_id = $1 AND user_id = ANY($2) for the users, and PostgreSQL's SELECT DISTINCT ON (resource_id) ... WHERE resource_id = ANY($2) ORDER BY resource_id, version DESC for the latest revision, which the UNIQUE (resource_id, version) index serves directly. On an engine without DISTINCT ON, use a lateral join or a row_number window. Three statements per request at any page size.
Follow-up
- The page size is capped at 200 today. What breaks first if it is raised to 2,000, and is it still this bug?
- How do you stop the next N+1 from reaching production, given that no individual query is slow and the endpoint's tests pass?
Built from the rounds and topics Tellius candidates report.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the Tellius loop
- Write out the reported sequence: Initial Screening, Technical Assessments, Hands-on Coding Sessions, Architectural Discussions, Final Offer Stage.
- For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.
Deliverable: A one-page map of the 5 reported rounds, with the weakest marked.
02Work Python
- Spend the session on Python, which Tellius candidates report being tested on.
- Write one worked example in Python and time yourself on it.
Deliverable: One timed worked example in Python.
03Work React.js
- Spend the session on React.js, which Tellius candidates report being tested on.
- Write one worked example in React.js and time yourself on it.
Deliverable: One timed worked example in React.js.
04Work SQL
- Spend the session on SQL, which Tellius candidates report being tested on.
- Write one worked example in SQL and time yourself on it.
Deliverable: One timed worked example in SQL.
05Answer out loud: Frontend & UI Engineering
- Answer aloud, timed: Implement a custom autocomplete search component in React.js that fetches data from a mock API and includes debouncing.
- Answer aloud, timed: Explain the difference between the Virtual DOM and the real DOM, and describe how React's reconciliation algorithm works.
Deliverable: Spoken answers to 2 reported Frontend & UI Engineering question(s), under time.
06Answer out loud: Backend, SQL, & Data Systems
- Answer aloud, timed: Design a database schema for an enterprise analytics dashboard that tracks user interactions and report generation.
- Answer aloud, timed: How would you optimize a slow-running SQL query containing multiple joins and aggregations over a table with millions of records?
Deliverable: Spoken answers to 2 reported Backend, SQL, & Data Systems question(s), under time.
07Answer out loud: AI Engineering & Agent Orchestration
- Answer aloud, timed: How do you ground a large language model (LLM) in structured enterprise data to prevent hallucinations?
- Answer aloud, timed: Describe how you would architect a multi-step AI agent workflow using frameworks like LangChain or LlamaIndex.
Deliverable: Spoken answers to 2 reported AI Engineering & Agent Orchestration question(s), under time.
Expand any day for tasks and deliverables. Your progress is saved on this device.
Behavioural rounds judge the decision you made and what it cost.
Tell callers you do not own that their integration breaks
A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.
Approach
- Establish the reader set empirically rather than from a wiki of owners: per-field usage counters keyed by principal, or access logs attributed to a consumer. State the blind spot of whichever you pick, since a consumer that reads the field only on a monthly job will not appear in a week of logs.
- Ship additive first. Populate the new field alongside the old one so no reader is forced to move, which is also what keeps a rolling deploy safe, because old and new instances answer the same requests at the same time and a rollback must still find the old shape present.
- Set the window from the slowest legitimate consumer's release cadence, not from your calendar, and decide separately what to do for a consumer with no release process at all, such as an external webhook endpoint you can only email.
- Convert silence into evidence before you rely on it: a short, low-traffic removal window that makes a still-dependent consumer fail visibly and loudly while you are watching, rather than at three in the morning after you have moved on.
Follow-up
- How would you detect a consumer that reads the field only during a monthly export?
- One caller refuses to move and has a commercial relationship behind it. What changes in your plan and what does not?
Narrate an outage you owned from page to postmortem
Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.
Approach
- Open on the signal rather than the cause: which metric at which percentile moved, on which service, at what time, so the listener follows the same evidence you had rather than a conclusion you already reached.
- Separate mitigation from diagnosis out loud. State what you did to stop the bleeding (flag off, shed traffic, drain a lease, roll back a deploy) and say plainly that you did it before the mechanism was known, because those are two jobs with different deadlines.
- Establish blast radius in countable terms: how many tenants, how many writes, and crucially whether the effect was loss or only delay. An append-only revision table or a pending outbox row means the change survived and the projection was merely behind, which is a repair rather than a data-loss incident.
- Prove the mechanism instead of asserting it. Name the trace span that grew, the plan that flipped to a sequential scan, the lease that expired, plus one alternative you ruled out and the signal that stayed flat while you ruled it out.
Follow-up
- What would you do differently in the first five minutes, given the same dashboard and no more information?
- Which follow-up action did you deliberately not take, and why was dropping it the right call?
Argue against a design, lose, and commit anyway
Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.
Approach
- State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
- Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
- Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
- Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.
Follow-up
- What threshold on that alert would have proved you right, and did anyone ever look at it?
- If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?
- 01
A field in a write endpoint's response must change shape. You own the endpoint; you do not own the four internal callers or the outbound webhook consumers who read it. Describe a deprecation you were responsible for: what you shipped first, how you established who was actually reading the field, the window you gave and what set its length, what you did about the consumer who never moved, and how you decided removal was safe. Name the signal you used, not the announcement you sent.
- 02
Pick an incident you personally drove, ideally one where writes were affected rather than reads. In six to eight minutes: state the symptom as it first appeared on a dashboard, the blast radius you established before you knew the cause, the mitigation you applied and when, the mechanism you eventually proved, and the follow-up that would prevent a repeat. Bring numbers: error rate, tenants affected, minutes to mitigate, minutes to resolve. If you cannot name what you measured, choose a different incident.
- 03
Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.
What is the typical difficulty of the Tellius software engineering interview?
Candidates generally describe the interview difficulty as average to challenging. The technical rounds are highly practical, focusing on hands-on coding and real-world system optimization rather than obscure algorithmic brain teasers.
Tellius Software Engineer candidate reports ↗How much preparation time is recommended before the technical rounds?
It is highly recommended to spend 2 to 3 weeks preparing. Focus on brushing up on your core domain fundamentals (such as React optimization or SQL performance tuning) and practicing system design scenarios.
Tellius Software Engineer candidate reports ↗Does Tellius support remote or hybrid working arrangements?
Tellius offers hybrid and remote-friendly configurations depending on the specific team, role level, and location (with major engineering hubs in Bengaluru, India, and San Francisco, CA). You should clarify the exact expectations for your role during your initial recruiter screen.
Tellius Software Engineer candidate reports ↗What distinguishes candidates who receive offers from those who do not?
Successful candidates demonstrate strong technical execution, but more importantly, they show an ability to receive feedback, optimize their code during the interview, and discuss the trade-offs of alternative approaches clearly.
Tellius Software Engineer candidate reports ↗What topics come up in the Tellius Software Engineer interview?
Tellius Software Engineer interviews most often cover Python, React.js, SQL, AI Engineering, and Agentic Workflows, based on topics extracted from real candidate reports.
Tellius Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Tellius Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Discord Software Engineer Interview Guide
Database practice for Discord candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.
Cohere Software Engineer Interview Guide
Testing exercises for Cohere software engineer prep: choosing boundary cases over repetition, isolating tests from shared clock and ordering, and treating an intermittent failure as a defect rather than noise.
Rystad Energy Software Engineer Interview Guide
Prepare for Rystad Energy software interviews with worked Python validation, OOP and decorator examples, plus an ingestion case and practical checks.
Webcreek Software Engineer Interview Guide
What Webcreek asks Software Engineer candidates, from reported rounds and questions.