We combine static analysis with LLM code review to evaluate test quality, bug reports, and testing patterns. Screen candidates efficiently by analyzing their actual work before interviews.
We combine static code analysis with LLM-powered code review for contextual understanding. Here's what we can assess and with what confidence level.
Static analysis catches these definitively
LLM analyzes context, quality, and sophistication
Multiple signals combined for assessment
These are binary patterns: present or absent. No subjective judgment required.
cy.wait(5000); // hope it loadscy.wait('@apiCall'); // deterministicWhy it matters: Random waits cause flaky tests that waste CI time
Detection method: AST parsing for cy.wait with number literals
.container > div:nth-child(3) > span[data-testid='user-email']Why it matters: Breaks with any DOM restructuring or styling change
Detection method: Regex patterns for :nth-child, complex CSS paths
Selectors repeated in 20 different test filesSelectors centralized in page object classesWhy it matters: One UI change requires updating many test files
Detection method: Analyze import patterns and selector duplication
cy.type('test@example.com') in every testconst USER = fixtures.validUser;Why it matters: Hard to maintain, unclear what data is significant
Detection method: Static analysis for string literals in test files
See what we can actually detect and how reliably
cy.get('.container > div:nth-child(2) > button').click()Brittle selector coupled to DOM structure - breaks with any layout change
cy.get('[data-testid="submit-button"]').click()Stable selector that survives refactoring and styling changes
Detectability: HIGH - AST parsing catches selector patterns reliably
cy.wait(3000); // wait for API
cy.get('.user-name').should('contain', 'John');Arbitrary timeout, no API verification, flaky in CI
cy.intercept('GET', '/api/user').as('getUser');
cy.wait('@getUser');
cy.get('[data-testid="user-name"]').should('exist');Deterministic, verifies actual network call, catches API errors
Detectability: HIGH - cy.wait with numbers vs aliases is clear in code
cy.get('#username').type('admin');
cy.get('#password').type('pass');
cy.get('button').click();Repeated selectors across all login tests - change one, update everywhere
class LoginPage {
login(user, pass) {
cy.get('[data-testid="username"]').type(user);
cy.get('[data-testid="password"]').type(pass);
cy.get('[data-testid="login-btn"]').click();
}
}DRY principle, maintainable, clear abstraction
Detectability: MEDIUM - Can detect class/function existence, harder to judge quality
We tag every finding with confidence levels so you know what to trust
Static analysis provides definitive detection
Use case: Filter out obvious technical issues
AI code review provides contextual assessment
Use case: Assess testing skill and sophistication
Human evaluation necessary
Use case: Technical interviews remain essential
Pay contractors in 100+ countries with one platform. They get professional invoicing, you get simple payments.
AI code review is powerful for technical assessment, but human evaluation remains essential for complete hiring decisions
What AI Can Do:
AI can evaluate test code quality, page object sophistication, edge case coverage, and bug report analytical depth. LLM understands context like "why this sleep() might be intentional" or "is this test organization appropriate for this codebase size."
Our Approach:
Provide technical quality scores with confidence levels. Flag patterns worth discussing in interviews rather than making binary judgments.
What AI Can Do:
AI analysis works best with public repositories showing consistent patterns across multiple projects. Limited data means lower confidence scores, but even 1-2 repos with good code provide useful signals.
Our Approach:
Clearly show data availability and confidence scores. Suggest traditional screening when public code is scarce.
What AI Can Do:
AI can assess if tests exist and their technical quality, but understanding if someone thinks strategically about what to test, when to use E2E vs unit tests, or how to balance coverage requires dialogue.
Our Approach:
Surface technical quality to filter candidates, then use interviews to probe testing philosophy and decision-making.
What AI Can Do:
AI cannot assess communication skills, collaboration ability, mentorship capacity, or cultural alignment. These human factors are critical for QA roles that involve working across teams.
Our Approach:
Focus AI on technical screening to reduce interview pool. Use interviews to evaluate soft skills, problem-solving approach, and team dynamics.
AI code review excels at technical pattern recognition, quality assessment, and catching issues at scale. It can evaluate test sophistication, bug report quality, and code evolution much faster than manual review.
But interviews remain essential for assessing problem-solving approach, communication skills, and team fit. Use our analysis to interview fewer candidates more effectively, not to skip interviews entirely.
Time-saving pre-screening, not skill assessment
"You spend 30 minutes with someone only to discover they don't know the difference between cy.wait(5000) and cy.wait('@apiCall')"
What we do: Automated pre-screening catches these red flags before interviews
Being honest: We can't tell you if they're 'senior', but we can tell you if they have glaring issues
"Resumes claim 'test automation expert' but you can't verify until technical interviews"
What we do: Analyze public test repositories for common anti-patterns
Being honest: We show what patterns exist in their code, you decide if they're concerning
"Someone followed a Cypress tutorial vs built production test suites - resumes look identical"
What we do: Check for sophistication indicators: page objects, proper API mocking, test organization
Being honest: Multiple repos with consistent patterns are stronger signals than one polished project
Comprehensive technical assessment with clear confidence indicators
AI evaluates test code sophistication and quality
Pre-screen technical competency before interviews
AI analyzes bug reports and testing approach
Assess testing sophistication and critical thinking
Know what to trust and what needs verification
Make informed screening decisions
Read resume claiming 'Cypress expert', schedule interview, discover basic misunderstanding
See that their code has cy.wait(5000) everywhere - filter before interview
Hope their tests are maintainable, find out after hiring they're brittle
Check for page object pattern presence, repeated selectors, DRY violations
Ask hypothetically 'how do you handle flaky tests?'
Show them their code with arbitrary waits and ask 'why this approach?'
Give take-home test (many candidates drop out)
Review their existing test repos - they've already written tests
Wonder if they write tests or just claim to
See commit history, test files, but can't judge if they're the right tests
With varying levels of confidence based on data availability
Cypress, Playwright, Selenium, Puppeteer
HIGH - Framework imports and syntax patterns are clear
Jest, Mocha, Vitest, Testing Library
HIGH - Test runner configs and assertion patterns detectable
Supertest, REST Assured, Postman collections
MEDIUM - Can see API test files, harder to assess quality
GitHub Actions, Jenkins, CircleCI configs
HIGH - Config files are binary: present or absent
Not definitively. We can detect red flags (hardcoded test data, brittle selectors, no page objects) and positive patterns (proper API mocking, good test organization). But we can't judge if someone is 'senior' or 'junior' - that requires interviews. Think of our analysis as filtering out obvious mismatches so you spend interview time on candidates who clear basic quality bars.
Binary patterns: Does code have cy.wait(numbers) vs cy.wait('@alias')? Are selectors using data-testid or nth-child? Is there a page object pattern or repeated selectors everywhere? Do test files exist? These are detectable. What we can't know: Is this appropriate for their context? Are they following team standards? Do they understand testing strategy?
We examine public GitHub issues, but confidence is lower here. We can check if reproduction steps exist, if screenshots are attached, if the reporter provided environment details. But many good testers work in private issue trackers, and evaluating 'quality' is subjective. We show what we find and flag when data is limited.
This is common and we're upfront about it. Our analysis works best when testers have public test repositories. Without that, we show 'limited data available' and note lower confidence. We encourage candidates to share sanitized examples or create portfolio projects. When data is scarce, traditional screening is still necessary.
No. We help you avoid wasting interview time on candidates with obvious issues (no tests, terrible patterns, security mistakes). But determining if someone can think critically, find edge cases, and work with your team requires actual interviews and take-home exercises. We're pre-screening, not full assessment.
Automation is easier to analyze from code. Manual testing skills require reviewing bug reports, test case documentation, and ideally watching someone test. We show what we can detect from public repos (bug report quality, exploratory testing evidence in issues), but clearly mark confidence levels. Manual testing assessment is harder than automation analysis.
AI analysis evaluates test code quality, bug reports, and testing patterns. Get pre-screened candidates with technical assessments before interviews. Free forever.
AI code review • Technical screening • No subscription fees