Real Time Project Interview Questions
After "tell me about your project", interviewers test whether you really worked on it: How would you build a framework from scratch? How many tests did you automate? What percentage is automated? What couldn't you automate? These questions have no single right answer — they have credible answers built from your own project. This guide gives a structure and a model answer for each, the follow-ups to expect, and how to handle numbers honestly.
1. How Would You Build a Framework From Scratch?
Interviewers want a process, not a list of tools. Walk through it in order:
- Understand the application and goals — web, API or mobile; release frequency; what the team needs from automation (fast smoke, full regression, cross-browser).
- Choose the approach and tools — language the team knows, Selenium or Playwright for UI, REST Assured for APIs, TestNG or JUnit, Maven, and BDD only if business people will read the scenarios.
- Set up the structure — base classes, driver factory, page objects, config per environment, test data, utilities, reporting.
- Prove it with a smoke suite — five to ten critical tests running reliably in CI before scaling.
- Scale and harden — data-driven tests, parallel runs, retries only for known infrastructure issues, failure screenshots, logs.
- Make it the team's framework — README, coding conventions, code reviews, a dashboard for results.
Model answer
"I'd start by understanding the application and what the team needs from automation. For a Java team testing a web app I'd pick Selenium with TestNG and Maven, the Page Object Model, and REST Assured for API setup and checks. I'd build the foundation first — a driver factory with ThreadLocal for parallel runs, a BasePage with wait helpers, config per environment, and reporting with screenshots on failure — then prove it with a small smoke suite in Jenkins before scaling up to regression and data-driven tests. I'd document it and review code with the team so it stays maintainable."
The layers and code in detail: The Complete Automation Framework Guide, a 30-day plan in Build a Framework From Scratch, and a full example in E-Commerce Selenium Java Framework.
Follow-ups to expect
- "Why that framework type?" — Hybrid (POM + data-driven + keyword/BDD pieces) because it combines maintainability with data coverage; BDD only when non-technical people read the tests.
- "How do you handle multiple environments?" — properties file per environment, selected with
-Denv=qa, secrets from environment variables. - "How do you keep it from becoming flaky?" — explicit waits, independent test data, stable locators, and fixing root causes rather than adding retries.
2. Which Types of Testing Did You Perform?
| Type | What it checks | Example from a project |
|---|---|---|
| Functional | Features work as specified | Login, search, checkout |
| Smoke | The build is stable enough to test | 10 critical checks after each deployment |
| Sanity | A specific fix or change works | Retesting a corrected coupon rule |
| Regression | Changes didn't break existing features | Nightly automated suite |
| Integration | Modules and services work together | Order placed in UI appears in the order API and database |
| API | Endpoints return correct data and errors | REST Assured checks on orders and auth |
| Database | Data is saved and updated correctly | SQL checks after a transfer |
| Cross-browser | Consistent behavior across browsers | Chrome, Firefox, Edge on Grid |
| UAT support | Business users accept the release | Helping users with scenarios and data |
Only claim what you actually did. If performance or security testing was done by another team, say so — "a separate team handled load testing with JMeter; I shared the critical flows with them" is a strong, honest answer. See Smoke vs Sanity and Integration & System Testing.
3. How Many Test Cases Did You Automate?
Give a real, round number and immediately explain what it covers — the number alone means little.
"I personally automated around 180 regression tests for the cart, checkout and payment modules, out of roughly 600 in our suite. About 20 of mine are in the smoke pack that runs on every deployment, and the checkout tests run with multiple data sets — card types, coupons, delivery options."
- Distinguish yours from the team's — "our suite has 600; I wrote about 180".
- Count tests, not data rows — one data-driven test with 20 rows is one test, 20 executions.
- Be ready for "how are they organized?" — by module and by group (smoke, regression).
Inflated numbers ("I automated 2,000 test cases in six months") invite probing questions that are hard to survive.
4. What Percentage of the Application Is Automated?
There's no ideal number; it depends on the product's stability and risk. Answer with the split and the reasoning:
"About 70% of our regression scenarios are automated — the stable, repetitive, business-critical flows like login, search, checkout and account updates, plus API checks. The rest stays manual on purpose: new features still changing, exploratory testing, usability, visual checks and a few third-party flows we can't control in test environments."
| Automate | Keep manual |
|---|---|
| Stable, frequently run regression flows | Features still changing every sprint |
| Data-heavy checks (many combinations) | Exploratory and usability testing |
| Smoke checks for every build | One-off or rarely run tests |
| API validations and test data setup | Visual judgment ("does this look right?") |
| Cross-browser runs of critical paths | CAPTCHA, real OTPs, physical devices without a lab |
More: Manual vs Automation Testing.
5. How Do You Handle CAPTCHA?
"We don't automate CAPTCHA — it exists specifically to stop automation, and solving it would make the test depend on a third-party service or a trick that breaks. In test environments the developers disable it with a configuration flag, or we use the provider's test keys (Google reCAPTCHA has keys that always pass). For flows behind login we often authenticate through the API and reuse the session. Production keeps the real CAPTCHA, and we check manually that it appears."
The same approach applies to OTP and two-factor authentication: a fixed OTP or test SMS gateway in lower environments, never real phone numbers.
6. How Did You Test Your Project?
- Understand requirements — user stories and acceptance criteria; ask questions in refinement.
- Plan — scope, test types, environments and data for the sprint.
- Design — test cases or checklists, including negative and edge cases; update the traceability.
- Execute — test new stories manually first; run smoke on each build and regression before release.
- Report defects in Jira with steps, evidence and severity; retest fixes.
- Automate stable scenarios and add them to the regression suite.
- Sign off with a summary of what was tested, open defects and risks.
7. What Makes a Good Selenium Test?
- Independent — creates its own data, runs in any order, and in parallel.
- Focused — checks one behavior, with a clear name that says what it proves.
- Real assertions — verifies outcomes (values, states, messages), not just that no exception happened.
- Stable locators and explicit waits — no
Thread.sleep, no absolute XPath. - Page objects — no locators in test methods.
- Fast setup — uses APIs for data and login where the UI isn't what's under test.
- Good failure evidence — screenshot, logs and a meaningful assertion message.
See Selenium Waits and Page Object Model.
More Questions in This Group
- What was the most difficult thing to automate? — describe one real case (iframes in payment, dynamic tables, file downloads) and how you solved it.
- How long does your regression suite take, and how did you reduce it? — parallel runs, API setup, removing duplicate tests.
- How do you decide a test is flaky, and what do you do? — rerun history, trace/screenshot, fix the cause, quarantine only temporarily.
- How do you maintain tests when the UI changes? — page objects mean one place to change; review locators with developers; ask for test IDs.
Practice these answers out loud, with follow-ups, in the Framework Interview Simulator.
From Real Projects
When I explain my own projects, I use the same structure this page recommends. For example: Canolog is an automotive dealership management system that connects sales, inventory, finance, service and parts; my role covered requirement analysis, writing and reviewing test cases, execution and defect tracking in Jira, and Selenium script development in a POM-based framework. Prepare your own project the same way — the application, your role, your tools and one concrete contribution. On Apkope, prospect and customer data arrives from email, phone, social media and chatbots, so test scenarios had to cover every channel that feeds the same records. Use real examples from your own project for every answer.
📚 Official documentation: Selenium documentation · ISTQB Glossary of testing terms
👉 See also: How to Explain an E-Commerce or Banking Project in an Interview
👉 See also: Healthcare Domain Project Explanation
FAQs
How do you explain building a framework from scratch?
As a process: understand the app and goals, choose tools, build the foundation (driver factory, base classes, config, reporting), prove it with a smoke suite in CI, then scale and document.
How many test cases should I say I automated?
Your real, round number — separated from the team's total — with what it covers and how it's organized.
What is a good automation percentage?
There's no fixed target; many teams automate 60–80% of stable regression scenarios. Explain what's automated, what stays manual, and why.
How do you handle CAPTCHA in automation?
Disable it or use test keys in test environments, authenticate through APIs where possible, and verify the real CAPTCHA manually.
What shouldn't be automated?
Rapidly changing features, exploratory and usability testing, one-off checks, visual judgment, and flows that depend on CAPTCHA or real OTPs.
Related
- Real-Time Questions: Process & Team
- How to Explain Your Automation Framework
- How to Explain Your Project
