Mock Interview Review for a Test Engineer with 6 Years of Experience: Three Fatal Mistakes and How to Fix Them

Introduction

A software test engineer based in Shanghai, with 6 years of experience, went through a mock interview while job hunting after resigning. With a target salary of 16K RMB, the interview exposed critical issues including low communication efficiency, unclear technical articulation, and superficial descriptions of AI applications. This mock interview review serves as a highly practical reference for anyone preparing for QA/test engineering interviews.

Candidate Background: 6 Years of Testing Experience, Yet Struggling in Interviews

The candidate has nearly 6 years of software testing experience, all based in Shanghai. Their career path covers the full spectrum from manual testing to test automation:

• First Company: Outsourced to a Beijing-based project, primarily doing manual testing, with later exposure to a Java+Excel+DDT-driven automation framework
• Second Company (Citibank): A foreign enterprise environment with full English communication, 70% UI automation (Python+Selenium), and some API automation (PyTest)
• Third Company (Ping An): Used an internal testing platform for API automation, with virtually no hands-on Python coding

The reason for leaving was office relocation. The target salary is 16K RMB, with market feedback hovering around 15K.

Technical Background: DDT and the Automation Test Stack

DDT (Data-Driven Testing) is an automation test design pattern that separates test logic from test data. In a Java+Excel+DDT setup, test scripts read input data and expected results from Excel spreadsheets, allowing the same test logic to be executed repeatedly with different datasets. This greatly improves test coverage and maintenance efficiency. It's a classic entry-level automation practice and a common topic in interviews for assessing a candidate's test design thinking.

The Python+Selenium+PyTest stack adopted at Citibank represents a higher level of engineering maturity. Selenium is the most widely used Web UI automation framework, supporting multiple browsers and languages. PyTest is one of the most powerful testing frameworks in the Python ecosystem, offering parameterization, fixture dependency injection, plugin extensions, and other advanced features. It's often paired with the Requests library for API automation. Mastering this stack in a foreign enterprise environment typically indicates that the candidate has a solid foundation in engineering-level testing.

Three Fatal Problems Exposed in the Mock Interview

Problem 1: Low Communication Efficiency with Hesitant, Uncertain Answers

The interviewer pointed out directly during the review: throughout the entire interview, the candidate displayed obvious hesitation and uncertainty. When asked technical questions, the answers were vague and ambiguous, giving the interviewer a sense of "difficult communication."

This is an extremely fatal problem. The interviewer's core reasoning is: If you've truly done something, you should be able to describe it clearly and confidently. Hesitation and vagueness immediately make the interviewer doubt the authenticity of your experience, potentially ending the interview prematurely.

Problem 2: Contradictory Descriptions of the API Automation Framework

This was the most serious technical communication failure in the entire interview. The candidate gave clearly inconsistent descriptions when introducing their API automation framework:

First description: The framework has four layers — a base methods class, a common utilities class, a test case layer, and a data layer.

Second description (after the interviewer asked them to repeat because it wasn't clear): It became three layers — request encapsulation, test case encapsulation, and test data management.

The two descriptions were inconsistent, with the number of layers changing from four to three. This directly triggered the interviewer's core concern: What does your framework actually look like? Why did it change when you described it a second time?

Technical Background: Layered Architecture in API Automation Frameworks

Mature API automation frameworks typically adopt a layered architecture to achieve separation of concerns and improve maintainability. A common four-layer structure includes: Base Request Encapsulation Layer (handles low-level HTTP logic such as timeout settings, header management, and response parsing), Common Utilities Layer (database operations, logging, assertion wrappers, and other shared capabilities), Business Test Case Layer (orchestration and organization of specific test scenarios), and Data Management Layer (test data storage and retrieval in formats like YAML/JSON/Excel). Being able to describe a framework's layered design clearly and consistently is a core criterion for judging whether a candidate has truly participated in framework development. It's the key dividing line between a "user" and a "builder." Any contradiction in the description immediately signals to the interviewer that the candidate lacks genuine, deep involvement with the framework.

Even more serious issues emerged during follow-up questions:

• When asked about what the common layer encapsulates, the candidate said "it's not core, it's not important" — but in reality, database operations are frequently used in the testing workflow
• When asked about the method for writing to YAML files, the candidate directly answered "I can't remember"
• The test case design structure (whether workflows are managed through separate files, classes, or individual test cases) was never explained at all
• The business process explanation was long and disorganized — a simple "user initiates approval → approver approves" workflow took an excessively long time without being clearly communicated

The interviewer's direct verdict: Most of it seems fabricated; the candidate probably hasn't actually done this work. Once an interviewer reaches this conclusion, the interview is essentially over.

Problem 3: AI Application Description Lacks Depth and Practical Value

The candidate mentioned that their team used AI (an internal platform built on the DeepSeek base model) to generate test cases, using a Harness system with Skills and Rules to constrain the LLM's output. The interviewer noticed that the candidate was noticeably more confident and assured when discussing AI topics, indicating this was a genuine experience.

Technical Background: The Harness System and Enterprise-Level AI Testing Implementation

Harness, in the AI application context, refers to a structured framework for constraining and guiding LLM output. Skills define the model's capability boundaries and output format for specific tasks — for example, "generate equivalence class test cases based on API documentation." Rules set business constraints, quality standards, and prohibited behaviors — for example, "no test cases without assertions" or "must cover boundary value scenarios." Enterprise internal testing platforms built on domestic LLMs like DeepSeek use the Harness system to "tune" general-purpose language models into vertical tools focused on test case generation, enabling team-level reuse of AI capabilities while protecting data security. This enterprise-level AI implementation approach has far more engineering value than directly calling public APIs. It represents a frontier practice in the testing industry's AI transformation — a qualitative leap from "individual AI usage" to "team-level AI engineering."

However, the problem was that the expression lacked depth:

What the candidate said: AI can generate 70% of test cases that are directly usable.

What the interviewer expected to hear should have included:

1. How core test case skeletons are generated based on the Harness/Rules/Skills approach
2. How the team shares and optimizes high-quality Skills
3. The human review process for verifying AI-generated content
4. How AI-generated skeletons are refined and supplemented
5. The process and methods for improving Skills accuracy from 10% to 70%
6. How the team-level AI collaboration system achieves overall efficiency gains

The interviewer specifically emphasized: Simply saying "we use AI to generate test cases" no longer carries any weight — any LLM can do that at low cost. What's truly valuable is the construction of a team-level AI collaboration system, continuous optimization of Skills, and deep AI integration into testing platforms (such as test result analysis, automated defect logging, responsibility assignment, etc.).

Core Improvement Recommendations from the Interviewer

The Underlying Logic of Interview Communication

The interviewer made a crucial statement:

"What you actually did at your company doesn't really matter. What matters is what you express to the interviewer about what you did. As long as you can make the interviewer believe you, whether you actually did it or not isn't really the point."

This isn't encouraging fabrication — it's emphasizing that an interview is fundamentally an assessment of your communication skills. You need to articulate what you've done clearly, confidently, and with demonstrated value. Every technical skill listed on your resume must withstand follow-up questioning.

Technical Preparation Priorities

Based on current market trends, the two areas most frequently asked about and most deeply examined in test engineering interviews are:

1. Test Automation: Framework design, test case management, data-driven approaches, correlated data handling, etc.
2. AI Applications: Not just simple test case generation, but team-level AI system construction and deep integration

Four Takeaways for Testing Professionals

Don't Stop Building Technical Skills While Employed

During their time at Ping An, this candidate used an internal testing platform for API automation and essentially stopped writing Python code, causing their previously accumulated framework skills to severely deteriorate. This is a classic case of the "boiling frog" syndrome.