Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About ThoughtSpot hiring for Software Testing roles
ThoughtSpot is an analytics software company known for search and AI-driven business intelligence that lets users ask questions of data in natural language. Its platform connects to cloud data warehouses and creates interactive charts and dashboards. It has an engineering presence in India and hires software engineers, data engineers, quality engineers and customer-facing technical roles.
For Software Testing roles, this ThoughtSpot practice set focuses most on Bug Life Cycle and Jira (7), Test Case Design (6), Agile, SQL and API Testing (5), Testing Types (4). It has 4 easy, 31 medium, 5 hard questions, so you can start easy and work up to the harder ones.
Company type
Product
Headquarters
Mountain View, California, USA
Main India offices
Bengaluru
ThoughtSpot Software Testing interview process
Online coding assessment
Technical round 1 (DSA)
Technical round 2 (system design or domain)
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for ThoughtSpotStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.
03
A developer asks you to test a feature that has no acceptance criteria. How do you proceed?
First ask the product owner or business analyst for the expected behaviour and write down the answers as draft acceptance criteria. Meanwhile, explore the feature, compare it with similar existing features and list assumptions. Share the assumptions in the story so everyone agrees before you sign off. Raise the missing criteria in the next refinement so future stories are not picked up without them.
04
Product is running an A/B test on the checkout button. What does QA need to verify?
QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.
05
How do you handle a bug found late in a release cycle?
Test with location permission allowed, denied and approximate only. Use mock location tools to simulate different cities and moving routes. Verify the app shows nearby results correctly, updates location while moving and handles GPS turned off. Check accuracy indoors and with weak GPS, battery impact of continuous tracking and that background location is used only if needed and explained to the user.
07
A manager says the app has 50,000 daily users, so the load test must run 50,000 virtual users at once. How do you respond?
Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.
08
SQL: find orders whose total does not match the sum of their order items.
SELECT o.order_id, o.total_amount,
SUM(i.quantity * i.unit_price) AS items_total
FROM orders o
JOIN order_items i ON i.order_id = o.order_id
GROUP BY o.order_id, o.total_amount
HAVING o.total_amount <> SUM(i.quantity * i.unit_price);
Turn on the screen reader, for example NVDA with a browser, and listen rather than look. Navigate by headings to check the structure is logical, by landmarks to find main regions and by Tab through controls. Each control should announce a clear name, role and state, such as 'Subscribe, checkbox, not checked'. Check images, form errors, dynamic updates like cart counts and dialogs. Note exactly what was announced in bug reports.
10
Your automated tests pass one by one but fail randomly when run in parallel. How do you fix the test data so tests are independent?
Each test should create the data it needs, usually through an API or database helper, use unique values such as an email with a timestamp, and clean up afterwards. Avoid tests that depend on data made by another test or on a shared account other tests change. For fixed reference data, seed it before the suite runs. Independent data allows tests to run in parallel and in any order without random failures.
Selenium is the oldest, uses the WebDriver standard, supports many languages like Java, Python and C# and every major browser, and is common in older enterprise suites. Playwright supports TypeScript, Python, Java and .NET, runs Chromium, Firefox and WebKit, and has built-in auto-waiting, tracing and parallel runs. Cypress runs inside the browser with JavaScript or TypeScript, has a friendly runner and is popular with front-end teams.
13
The developer says "it's not a bug". What do you do?
Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.
Test monitoring compares actual testing progress with the plan, using metrics like test cases executed, pass rate, open defects and effort spent. Test control is the action taken when monitoring shows a gap, such as re-prioritising tests, adding testers, changing the schedule or tightening entry criteria. For example, if half the time has passed but only a quarter of cases are executed, the lead must act and inform stakeholders.
16
SQL: check that no user has more than one active subscription.
-- Business rule: at most one ACTIVE subscription per user
SELECT user_id, COUNT(*) AS active_count
FROM subscriptions
WHERE status = 'ACTIVE'
GROUP BY user_id
HAVING COUNT(*) > 1;
-- Expected result: no rows
Save filters for common views such as my open bugs, bugs ready for retest, blockers in the current sprint and bugs by fix version. Add them to a dashboard with gadgets like pie charts by priority, created versus resolved trend and a sprint bug list. Share the dashboard with the team so status is visible without manual reports. Testers start their day from the ready-for-retest filter.
Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.
21
Search works fine in QA but is very slow in production. Could a missing database index be the reason, and how do you check?
Yes, very likely. An index lets the database find rows quickly, like the index of a book. With a small QA table, a full table scan is still fast, but with millions of production rows it becomes slow. Compare indexes on the searched columns in both environments and ask a developer to check the query plan. Test key queries on production-size data in staging, and include data volume in future performance checks.
22
What are ACID properties and how can a tester check them?
ACID means Atomicity, Consistency, Isolation and Durability. Atomicity: a transfer that debits one account must also credit the other, or neither happens; test by forcing a failure midway. Consistency: constraints still hold after the transaction. Isolation: two users updating together do not see each other's half-done work; test with two sessions. Durability: committed data survives a restart; test by committing, restarting the service and querying again.
23
Your automated accessibility scan shows zero errors. Is the page accessible?
Not necessarily. Automated tools catch only a part of WCAG issues, such as missing labels and contrast. A clean scan still needs manual checks: keyboard-only navigation, focus order, a screen reader pass, meaningful alt text and link names, error handling, zoom and reflow and dynamic content. Report the result as 'no automated violations found' and add the manual checklist outcome before claiming conformance.
Installation testing checks that software installs correctly on supported systems: fresh install, custom paths, low disk space, missing prerequisites and clean uninstall. Upgrade testing checks moving from an older version to the new one: user data and settings must be kept, database migrations must run, and the app must work after the upgrade. Also test skipping versions, such as 1.2 to 1.5, and what happens if the upgrade is interrupted.
25
What is regression testing, and when do you automate it?
Pick a small set of stable, high-value regression cases first. Review each one: make steps precise, remove judgement-based checks and define clear expected results. Prepare test data that the script can create and clean up. Build reusable page objects and helpers for common steps like login. Automate, run several times to confirm stability, then link each script to its manual case ID and mark the manual case as automated.
Learning, test design and execution at the same time, without scripted cases — time-boxed sessions with a charter (e.g. 'explore checkout with coupons'), noting bugs and ideas. Great for finding edge cases.
28
You notice full card numbers printed in the application logs. What do you do?
Treat it as a high-severity security defect, because storing full card numbers in logs breaks payment card security rules and creates a data leak risk. Do not copy the card numbers into the bug; use masked examples and the log location instead. Log the bug with restricted visibility and inform your lead and the security contact right away. After the fix, verify new logs are masked and confirm old logs are cleaned.
List conditions and actions in a table and cover every combination of conditions (rules) — ideal for business rules like loan approval: salary > X AND credit score > Y → approve.
A defect is a flaw in the software that makes it behave differently from the requirement, whether found in testing or production. A production incident is an event that disrupts or degrades service for users, such as an outage or a failed payment flow. An incident may be caused by a defect, but also by infrastructure, configuration or third-party failures. Incidents are handled by an incident process first, then linked to defects for the fix.
A test condition is an item or event of the system that can be verified by one or more test cases, derived from the test basis. For example, for a login requirement, conditions include valid login, wrong password, locked account and remember me. Test conditions answer what to test, while test cases describe how to test it with steps, data and expected results. Listing conditions first helps check coverage before writing detailed cases.
Do not automate all 500. First clean the suite: remove duplicates and outdated cases. Rank the rest by business risk, run frequency and stability. Start with a smoke set of 20 to 30 critical journeys and move rule-heavy checks to the API level. Choose a tool that fits the team's skills, build a simple framework with page objects and CI runs, then expand in batches while tracking time saved and flakiness.
Won't Fix means the bug is acknowledged as real, but the team decides not to fix it, usually because the impact is very low, the feature is being retired or the cost of fixing is higher than the benefit. The decision is made by the product owner, often in triage with dev and QA leads. The tester should make sure the reason is recorded and, if user-facing, documented as a known issue.
Check that buttons and icons are large enough to tap without hitting neighbours: Android guidance is 48 by 48 dp and iOS is 44 by 44 points. Test with large font settings and one-handed use. Any action using complex gestures, such as swipe to delete or pinch, must have a simple tap alternative. Then turn on TalkBack and VoiceOver and confirm each control can be focused, named and activated.
38
SQL: how do you test a foreign key defined with ON DELETE CASCADE?
-- Create a parent and child, delete the parent, child rows must disappear
INSERT INTO customers (id, name) VALUES (501, 'Cascade Test');
INSERT INTO orders (id, customer_id, total) VALUES (7001, 501, 250);
DELETE FROM customers WHERE id = 501;
SELECT COUNT(*) FROM orders WHERE customer_id = 501;
-- Expected: 0
-- Also test inserting an order for a non-existent customer: it must fail
1. Open and close by click and keyboard. 2. Select one, then several options; all show as chips or a count. 3. Deselect an option. 4. Select all and clear all, if available. 5. Search inside the list filters options. 6. Maximum selection limit is enforced with a message. 7. Required field shows an error if none selected. 8. Saved selection persists after refresh. 9. Long option names do not break layout. 10. Screen reader announces selected state.
The observation that a small number of modules contain most defects, so testing should focus on those areas.
Tips to crack the ThoughtSpot Software Testing interview
Practise DSA problems carefully, as engineering interviews at product analytics companies often focus on strong problem-solving fundamentals.
Revise SQL, query execution basics and data warehouse concepts to discuss how analytics queries run on large datasets.
Try the product's free trial or demos so you can talk about search-based analytics from a user's perspective.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; ThoughtSpot interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the ThoughtSpot Software Testing interview?
Candidates usually go through 4 stages: Online coding assessment; Technical round 1 (DSA); Technical round 2 (system design or domain); Hiring manager round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the ThoughtSpot Software Testing interview?
This practice set leans on Bug Life Cycle and Jira (7), Test Case Design (6), Agile, SQL and API Testing (5), Testing Types (4). Revise those first, then practise explaining one or two of your own projects end to end, because most ThoughtSpot interviewers ask you to walk through real work.
Are these the exact questions asked at ThoughtSpot?
No. These are curated practice questions that match the skills and difficulty usually tested in product interviews like ThoughtSpot's. They are not a leaked or verified list of past questions.
Where does ThoughtSpot hire Software Testing professionals in India?
ThoughtSpot has large teams in Bengaluru. Openings and locations change often, so check the ThoughtSpot careers page and filter by city and experience.