Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Sigmoid hiring for Software Testing roles
Sigmoid is a data engineering and AI services company that helps enterprises build cloud data platforms, analytics solutions and machine learning applications. It works with clients in consumer goods, retail, banking and manufacturing on big data pipelines, data lakes and business intelligence. It has its main engineering teams in India and hires data engineers, data scientists, analysts and cloud engineers.
For Software Testing roles, this Sigmoid practice set focuses most on Bug Life Cycle and Jira (8), Test Case Design (6), Performance and Security Basics (4), Manual Testing Basics (4). It has 9 easy, 27 medium, 4 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
San Francisco, USA
Main India offices
Bengaluru, Pune
Sigmoid Software Testing interview process
Online coding assessment (SQL + Python or Java)
Technical interview (data engineering)
Technical or managerial round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for SigmoidStart 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.
✓ 3 questions free • Unlock the rest in seconds
01
How do you test a country dropdown that controls a dependent state dropdown?
Check the state list is empty or disabled until a country is selected. Select a country and verify the correct states load. Change the country and confirm the old state selection is cleared and the new list loads. Test countries with no states, a long list with scrolling and search, and default values on page load. Submit the form and verify the saved values, then reload and check both dropdowns keep the saved selection.
Trigger the email from each event, such as signup or order placed, and verify it arrives at the right address within the expected time. Check subject, sender name, personalised fields, amounts and links. Click every link and confirm it opens the right page. Check the layout on desktop and mobile mail apps, the unsubscribe option where required, and that no email is sent for failed or cancelled actions. Use a test mailbox tool in QA.
03
What is a performance bottleneck and where do bottlenecks usually occur?
A bottleneck is the component that limits the whole system's performance, so adding load beyond it increases response times or errors. Common places are slow database queries or missing indexes, too few database connections or threads, CPU or memory limits on servers, slow third-party APIs, large uncompressed files and chatty code that makes many small calls. Monitoring each layer during a test shows which resource saturates first.
Defect removal efficiency shows how many defects the team found before release. DRE = defects found before release divided by (defects found before release plus defects found after release), multiplied by 100. If QA found 90 bugs and users reported 10, DRE is 90 percent. A falling DRE means testing is missing more defects, and the escaped bugs should be analysed to improve test coverage.
05
A form saves names with an apostrophe, like O'Brien, incorrectly or fails to save them. What do you test?
This suggests the input is not handled safely, possibly string-built SQL, which is also a SQL injection risk. Test names with apostrophes, double quotes, Hindi and other Unicode text, emojis, leading spaces and maximum length. Query the database to confirm the exact stored value and character encoding. Then check the value displays correctly everywhere it is read back. Log a high-severity bug and mention the possible injection risk.
06
How do Selenium, Playwright and Cypress differ at a high level?
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.
Model answer: To me quality means the product does what users need, reliably, and is easy to use, not just that test cases pass. In my final-year project I tested a library app; all features worked, but students struggled to find the search option. I reported it as a usability issue and the team moved search to the home screen. That taught me to test from the user's point of view as well.
08
A page loads slowly only for some users. How do you investigate as a manual tester?
Collect details from affected users: location, device, browser, network and time. Try to reproduce with similar conditions using browser network throttling. Use the browser developer tools network tab to find slow requests, large files or failing calls, and compare with a fast user. Check whether those users have more data, like a long order history. Share the slow request, timing and conditions in the bug for the developers.
09
What is the difference between a walkthrough and an inspection?
Both are static review techniques. A walkthrough is informal and led by the author, who explains the document or code to peers to share knowledge and gather feedback. An inspection is the most formal review: it has defined roles such as moderator, reader and scribe, uses checklists, needs preparation and records defects and metrics. Inspections find more defects but take more effort.
10
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
Send and receive text messages and check order and timestamps. Test sent, delivered and read status. Send emojis, long messages, links and attachments within and over the size limit. Check messages sent while offline are queued and delivered on reconnect. Verify blocking a user stops messages. Test notifications when the app is in background. Check chat history after reinstall or on a second device, and that deleted messages disappear for both users if supported.
Verify notifications arrive when the app is in foreground, background and closed. Check title, text, icon and that tapping opens the right screen with the correct data. Test with notifications disabled at OS level and inside app settings. Check behaviour after logout, reinstall and on multiple devices with the same account. Test grouping of many notifications, time-sensitive ones, and that no notification shows private data on the lock screen.
15
What is cold start versus warm start, and why test app launch time?
A cold start launches the app from scratch when it is not in memory, loading the process and the first screen; it is the slowest. A warm start happens when the app process exists but the screen must be recreated, and a hot start just brings it to the foreground. Users abandon slow apps, so teams set targets, such as cold start under two seconds on a mid-range device, and measure each release for regressions.
Collect exact details: user, time, device, browser and request IDs. Compare production with QA for configuration, feature flags, data volume, third-party integrations, versions and caching. Ask for production logs and error traces through the support or dev team. Try to reproduce in QA with production-like data or in a staging environment. Once found, add a test for the gap and fix the environment difference if one caused it.
18
Explain three usability heuristics with examples from a web app.
Visibility of system status: after clicking Pay, show a progress indicator so users do not click again. Error prevention: disable the Submit button until required fields are valid, or ask for confirmation before deleting an account. Recognition rather than recall: show recently searched items and saved addresses instead of making users remember them. Other heuristics include consistency, user control with undo, and clear help for recovering from errors.
19
How do you test session management in a web application?
Check that a new session ID is created after login, and that the session expires after the defined idle time. Verify logout invalidates the session on the server, so pressing back or reusing the old cookie does not work. Check that cookies use Secure, HttpOnly and SameSite flags. Test concurrent logins if they are limited, and that changing the password ends other sessions. Session IDs must not appear in URLs.
Keep it short and decision-oriented. Show open bugs by severity, the created versus resolved trend, blockers with owners and dates, defect leakage from the last release and modules with the most defects. Give a clear recommendation, such as ready, ready with known issues or not ready, with reasons. Use a shared dashboard for detail, and one slide or email summary for leaders who need only the risk picture.
Execution progress = test cases executed divided by total planned test cases, multiplied by 100. Pass rate = test cases passed divided by test cases executed, multiplied by 100. For example, if 200 cases are planned, 150 are executed and 120 passed, progress is 75 percent and pass rate is 80 percent. Report blocked cases separately because they are neither passed nor failed.
24
How do you link stories, test cases and bugs in Jira for traceability?
Create test cases as linked issues or in a test management add-on and link each one to its story with a tests relationship. When a test fails, create the bug from the test execution or link it to both the test and the story with is blocked by or relates to. Use the same fix version for all. A story then shows its tests and open bugs, which makes sign-off and the traceability report easy.
PUT replaces the whole resource with the data sent, so fields you leave out may be cleared or reset. PATCH applies a partial update and changes only the fields sent. For example, to change only a user's phone number, PATCH with just the phone field is enough, while PUT expects the complete user object. Testers check that PUT and PATCH behave as documented and that missing fields are handled correctly.
26
How do you test touch target size and gestures for accessibility in a mobile app?
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.
This relies on colour alone to give information, which fails WCAG criterion 1.4.1. Users with red-green colour blindness, which affects a noticeable share of men, cannot tell the states apart, and screen readers announce nothing. Recommend adding text or icons such as a tick and a cross with labels like 'Passed' and 'Failed', and accessible names for the dots. Test with a colour blindness simulator in browser developer tools.
29
How do you balance manual testing and automation work in the same sprint?
I agree the split with the team at sprint planning. Testing new stories manually comes first because it blocks the sprint goal. I then automate the stable flows from the previous sprint, so scripts are not rewritten while features change. For example, I block two afternoons a week for automation and report progress in stand-up. If a release is at risk, I pause automation and tell the lead openly.
Model answer: Most users in India now use services first on their phones, so mobile quality directly affects customers. In my project I tested a college event app on four phones and found that the registration button was hidden by the keyboard on small screens. Fixing it raised sign-ups. I enjoy the variety of devices, networks and real-life situations that mobile testing involves.
A performance baseline is a set of measurements of the current system under a known load, such as response times, throughput, error rate and resource usage. Every new build or release is compared with it to spot regressions. For example, if the checkout API had p95 of 800 milliseconds at 200 users last release and now shows 1.5 seconds, the change needs investigation. A benchmark compares against an industry or competitor standard.
32
How do you capture screenshots, videos and traces when an automated test fails?
Most frameworks support this through configuration. In Playwright, set screenshot to only-on-failure, video to retain-on-failure and trace to on-first-retry in the config, then open the trace viewer to step through actions, network calls and the page state. In Selenium, call save_screenshot in a teardown hook when a test fails. Store these artefacts in CI so anyone can debug the failure without rerunning it.
33
A feature passed all your test cases, but users say it is confusing. What went wrong?
The tests verified the specification but did not validate the user experience. The test cases probably checked only functional outcomes and missed usability: unclear labels, too many steps or poor error messages. Next time, add usability heuristics to reviews, do exploratory sessions as a real user persona and involve users in UAT or demos. Log the current feedback as improvement items with clear examples.
An urgent patch released outside the normal schedule to fix a critical production defect, followed by regression testing and merge back to the main branch.
35
Which basic Git commands should a manual tester learn before working on automation?
Start with: git clone to copy the test repository; git pull to get the latest changes; git checkout -b feature/login-tests to create a branch; git status and git diff to see changes; git add and git commit -m to save work with a message; and git push to send the branch so you can raise a pull request for review. Also learn to resolve simple merge conflicts and never commit passwords.
36
Tell me about a time you had to learn SQL or API testing quickly for a project.
Model answer: Situation: in my first project, testers had to verify orders in the database, and I knew only basic SELECT. Task: become useful within a week. Action: I practised joins on a copy of the test database every evening and asked a senior to review my queries. Result: by the second sprint I was validating order data on my own and caught a missing tax column bug.
Defect age is how long a defect stays open, measured either in time, from the date it was logged to the date it was closed, or in phases, from the phase where it was introduced to the phase where it was found. High defect age signals slow fixing or triage. Phase-based age shows how late defects are caught; a requirement defect found in UAT has a high age and is costly.
38
As a QA lead, how do you measure the quality of test case design?
Look at requirement coverage through the traceability matrix, the share of defects found by scripted tests versus exploratory testing or production, and defect leakage per module. Review samples for clear objectives, correct expected results and use of techniques like boundaries and negative cases. Track how many cases were updated or retired after changes. If many production bugs map to areas with passing tests, the design, not the execution, needs improvement.
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.
40
How do you handle a bug found late in a release cycle?
Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.
Tips to crack the Sigmoid Software Testing interview
Revise distributed data concepts such as Spark, partitioning and data pipelines, along with strong SQL and one programming language.
Be ready to design a simple batch or streaming data pipeline on a cloud platform and explain your choice of tools.
Prepare a data project walkthrough that shows how you cleaned data, built transformations and checked quality of results.
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; Sigmoid interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Sigmoid Software Testing interview?
Candidates usually go through 4 stages: Online coding assessment (SQL + Python or Java); Technical interview (data engineering); Technical or managerial round; HR 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 Sigmoid Software Testing interview?
This practice set leans on Bug Life Cycle and Jira (8), Test Case Design (6), Performance and Security Basics (4), Manual Testing Basics (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Sigmoid interviewers ask you to walk through real work.
Are these the exact questions asked at Sigmoid?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like Sigmoid's. They are not a leaked or verified list of past questions.
Where does Sigmoid hire Software Testing professionals in India?
Sigmoid has large teams in Bengaluru, Pune. Openings and locations change often, so check the Sigmoid careers page and filter by city and experience.