Why pre-screen programmer analysts before the technical interview
The analyst half of this job is where most of the value and most of the failure sits. A developer who takes a stated requirement literally will build exactly what was asked for and solve nothing, because users describe solutions rather than problems. The other half is maintenance reality: most of the work is in code somebody else wrote, often years ago, with no tests. A short screen establishes whether someone is strong at both or only at building.
What actually matters when screening Computer Programmer Analyst candidates
- 01
Technical proficiency
Check fluency in the stack they claim: C#/.NET, Java, or COBOL, plus SQL joins, stored procedures, and version control workflow in Git or TFS branching.
- 02
Systems and trade-offs
Probe how they weigh batch versus real-time processing, index design against write cost, and when they refactor legacy modules instead of wrapping them in new interfaces.
- 03
Evidence and rigour
Test debugging discipline: reproducing a production defect, reading query execution plans, log analysis, unit test coverage, and how they validate data migrations before cutover.
- 04
Collaboration and communication
Assess how they turn vague user requests into specifications: requirement gathering sessions, use cases, sign-off documents, and status updates to business owners during releases.
Pre-screening questions to ask Computer Programmer Analyst candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Systems they built
3 questions01Can you describe a complex programming project you have recently worked on?
Listen forTheir own decisions described with what made it complex, plus what they would build differently now.
A project described with no decisions of their own, or complexity that turns out to be size alone.
02What programming languages are you proficient in?
Listen forReal depth in one with an honest split between what they use daily and what they have touched.
Long language lists at equal proficiency, or claims that do not match the projects described.
03Do you have experience in database modelling and design?
Listen forA schema they designed with a decision they would now make differently, and what it cost them later.
Database design left entirely to an ORM, or no schema of theirs they have had to maintain.
Analysis before code
3 questions04Do you have experience in systems analysis, and which methodologies have you used?
Listen forRequirements established by observing the work as performed, with a stated request they challenged.
Requirements taken from a document and built literally, with no contact with the people doing the work.
05Can you explain your understanding of the software development lifecycle?
Listen forA view drawn from working within one, including where their team's process broke down and what they did.
A textbook sequence recited, or no experience of a phase beyond writing code.
06What is your approach to documenting your code?
Listen forDocumentation aimed at why rather than what, with decisions recorded somewhere the next maintainer will find them.
Comments that restate the code, or documentation produced only when a process requires it.
Testing as habit
3 questions07Do you have experience with test-driven development?
Listen forAn honest account of where they use it and where they do not, tied to real work rather than a principle.
Claims to always work this way with no example, or dismissal of testing as slowing delivery.
08Can you describe how you typically test your code?
Listen forA view on what is worth testing at each level, with a bug a test of theirs actually caught before release.
Testing described as running the application, or tests written to satisfy a coverage number.
09Do you have experience in software quality assurance?
Listen forWorking relationship with testers including how they respond to a defect report they disagree with.
Quality treated as someone else's stage, or defects disputed rather than investigated.
Debugging other people's code
3 questions10Can you describe your experience with debugging code?
Listen forA method that narrows the fault with evidence, and a specific bug where their first theory turned out wrong.
Debugging by changing code until the symptom clears, or no example they can describe.
11What is your approach to troubleshooting a piece of faulty code you did not write?
Listen forReading and reproducing before changing, with a failing test added first where the codebase allows it.
Unfamiliar code rewritten rather than understood, or changes made without reproducing the fault.
12How do you handle deadline pressure and prioritise on projects with tight schedules?
Listen forTrade-offs made visible with a recommendation, and a case where they flagged a date as unachievable early.
Deadlines met by cutting testing silently, or schedule risk raised only after the date was missed.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names languages and frameworks with version detail, writes non-trivial SQL from memory, and explains their branching and code review workflow.
Systems and trade-offs
25%5Explains a concrete trade-off they made, such as denormalising a reporting table, and names the performance or maintenance cost accepted.
Evidence and rigour
25%5Walks through a real defect with evidence gathered (logs, execution plan, test case) rather than guesswork, and cites the fix's measured effect.
Collaboration and communication
15%5Describes translating ambiguous business asks into documented specs, and handling scope changes with stakeholders without stalling the release schedule.
Users describe solutions, not problems, and a literal developer builds exactly the wrong thing. A one-way video screen asks what requirement they pushed back on.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish what they built, hear how they gather requirements, and check their testing and debugging habits before a technical interview.
How should I weight analysis against coding?
Decide which your team is short of first. Both are legitimate profiles and the title covers both. A strong coder who takes requirements literally is a different hire from an analyst who codes adequately.
Evaluating answers
What is the strongest signal when screening a programmer analyst?
A requirement they questioned. Analysts who add value can name a request they pushed back on and what the real need turned out to be. Anyone who builds exactly what was asked for is a pair of hands.
How do I judge maintenance capability?
Ask how they approach a bug in unfamiliar code with no tests. Real answers describe reading before changing and adding a test that reproduces it. Anyone who starts rewriting will create more work than they close.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
