Application Developer Interview Questions and Scorecard
Application developer interview questions for small businesses without HR: 6 question sets, answer guidance, red flags, and a scorecard. Download as DOCX.
40 interviewer questions in 6 sets, each with why it is worth asking and what a strong answer sounds like, plus a 1-to-5 scorecard and a method for judging technical answers when nobody on your side writes code. Download as DOCX.
The first developer interview I ever ran, I had no idea what I was listening for. I asked about frameworks I could not evaluate, nodded at the answers, and hired on how confident the person sounded. That is roughly how most small businesses hire their first in-house developer, and it is why the hire so often goes wrong in the second year rather than the first.
An application developer at a company that does not sell software has a specific job: own the applications the business runs on, connect the systems it already bought, and keep all of it working for colleagues who cannot debug anything themselves. The interview should test for that job, not for a product engineering role at a technology company.
At FirstHR, we build for small businesses that hire without an HR department, where the owner is usually the only interviewer in the room. This page gives you 40 questions in six sets, each with a stated reason it is worth asking and a note on what a strong answer sounds like, plus a scorecard.
TL;DR
Interview an application developer across six areas: requirements and stakeholder work, technical craft, integrations and data, shipping and maintenance, behavioral evidence, and a scored summary. Ask the same questions of every candidate and grade the shape of the answer, whether there was a method, a specific root cause, and a named tradeoff, rather than the technology itself. Download 40 questions and a 1-to-5 scorecard as DOCX.
What to Assess in an Application Developer
Assess four things: whether the candidate can turn a vague business request into working software, whether they build code somebody else can maintain, whether they can connect systems that were never designed to talk, and whether they will keep it all running afterward. Raw algorithmic ability sits well below those for an in-house role.
That ranking surprises people, because most published developer interview advice was written for product engineering teams at technology companies. If you are writing the posting alongside the interview, the application developer job description templates cover the same split of duties, and the interview should mirror whichever version you publish.
The other assessment worth naming early is expectation fit. In-house application work is maintenance-heavy by nature, and a candidate who pictures a year of greenfield building will be restless by month six. Ask about the split directly rather than discovering it after the hire.
The Six Question Sets
The 40 questions are grouped into five competency sets plus a scorecard. Each set targets a different part of the role, and a strong candidate should hold up across all of them rather than only on the technical questions they have rehearsed most.
Requirements and Stakeholders
Can they translate?
Whether the candidate can turn a vague request from a non-technical colleague into something worth building. The skill that separates an in-house developer from a contractor.
Technical Craft and Code Quality
Can they build it well?
Depth in one stack, debugging method, testing judgment, and whether the code they leave behind can be maintained by whoever comes next.
Integrations, Data, and Legacy
Can they connect things?
Joining systems that were never meant to talk, handling data safely, and taking over code somebody else wrote. Most of the real work.
Shipping, Support, Maintenance
Will they keep it running?
Release and rollback, bug triage, monitoring, and how they treat a colleague who reports a problem badly. In-house roles are maintenance-heavy.
Behavioral and Situational
How do they operate?
Missed deadlines, technical disagreements, jumped queues, and career direction. Past behavior predicts performance better than stated intentions.
Scorecard (1 to 5 Rubric)
Score, do not guess
A rubric to rate each area with written evidence, so the decision survives the week after the interview. The asset most question lists skip.
Do Not Spend the Whole Hour on Craft
Technical craft is the easiest set to over-weight, because it feels like the real interview. For an in-house role, the sets that actually predict success are requirements and maintenance: whether the candidate can extract a real problem from a colleague, and whether they will still be answering support questions cheerfully in month nine. Broader technical interview questions cover the craft side in more depth if you need it, but budget at least half your time for the other four sets.
40 Questions and a Scorecard to Download
Download all six as a single file, or copy individual sets. Every question comes with a why ask line and a good answer line, so the person running the interview knows what they are listening for. The last file is the scorecard.
Download All Questions and the Scorecard
Five question sets by competency plus a 1-to-5 scoring rubric. All in one download.
Set 1: Requirements and Stakeholder Work
Whether the candidate can turn a vague request from a non-technical colleague into something worth building, and whether they push back when the request solves the wrong problem.
Requirements and Stakeholder Questions
APPLICATION DEVELOPER INTERVIEW: REQUIREMENTS AND STAKEHOLDER WORK
Candidate: __
Interviewer: __
Date: __
QUESTIONS TO ASK, AND WHY EACH ONE EARNS ITS PLACE
1. Tell me about an application you built for people who were not developers.
Why ask: most of this job is turning a business problem into working
software, and that starts with the conversation, not the code.
Good answer: names the users, the problem in their words, and what
measurably changed for them after release.
2. A department head asks for a feature you think solves the wrong problem.
What do you do?
Why ask: an in-house developer who builds every request as stated will
ship a pile of features nobody uses.
Good answer: asks what the person is actually trying to accomplish,
proposes an alternative, and defers to the business if overruled.
3. How do you capture requirements when nobody writes a spec?
Why ask: small companies rarely have a product manager or a written spec.
Good answer: describes a lightweight habit, a short written summary sent
back for confirmation, screenshots, or a walkthrough of the current
manual process before any code is written.
4. Walk me through how you decide what to build first.
Why ask: the developer will often be the only person setting priority.
Good answer: weighs business impact against effort, checks the assumption
with whoever asked, and is comfortable saying not yet.
5. Describe a time you told a stakeholder that something would take much
longer than they expected.
Why ask: estimate honesty is a bigger risk than coding speed.
Good answer: gives the reason in plain language, offers a smaller version
that ships sooner, and does not disappear until the deadline.
6. How do you demo work in progress to a non-technical audience?
Why ask: regular visible progress is what keeps an internal application
funded and used.
Good answer: shows the working feature against the original request,
not a slide about architecture.
7. What questions would you ask us in your first week?
Why ask: reveals whether the candidate starts with the business or with
the technology stack.
Good answer: asks who uses the application, what breaks most often, and
what the company actually measures.
8. Tell me about a project that was cancelled or shelved. What happened?
Why ask: internal work gets deprioritized constantly, and how someone
handles that predicts how they will handle it here.
Good answer: takes it without bitterness, and salvages something reusable.
NOTES
[Capture specific examples, named systems, and red flags here.]
Set 2: Technical Craft and Code Quality
Depth in one stack, debugging method, testing judgment, and whether the code they leave behind can be maintained by whoever comes next.
Technical Craft and Code Quality Questions
APPLICATION DEVELOPER INTERVIEW: TECHNICAL CRAFT AND CODE QUALITY
Candidate: __
Interviewer: __
Date: __
QUESTIONS TO ASK, AND WHY EACH ONE EARNS ITS PLACE
1. Which language and framework are you strongest in, and what have you
actually built in it?
Why ask: separates real depth from a resume keyword list.
Good answer: names the stack, names the application, and describes the
parts they personally owned.
2. Walk me through how you debugged a problem you could not reproduce.
Why ask: debugging is the single most common activity in application work
and the hardest to fake.
Good answer: describes narrowing the search, logs and instrumentation,
a hypothesis tested against evidence, and the actual root cause.
3. How do you decide what to test automatically and what to test by hand?
Why ask: a solo developer with no test safety net becomes the bottleneck
for every future change.
Good answer: tests the logic that would cost real money if wrong, keeps
the suite fast, and is honest that full coverage is not the goal.
4. What does good code look like to you when someone else has to maintain it?
Why ask: you are hiring the person who writes the code your next hire
inherits.
Good answer: talks about naming, small functions, readable structure,
and documentation for the parts that are surprising.
5. Tell me about a piece of your own code you later regretted.
Why ask: self-criticism is the cheapest available signal of real seniority.
Good answer: gives a specific decision, explains the cost it caused, and
says what they do differently now.
6. How do you review someone else’s code, or get your own reviewed, on a
very small team?
Why ask: the review habit disappears first when there is only one
developer, and the quality drop follows.
Good answer: proposes a practical substitute, a rotating reviewer, a
checklist, or a walkthrough with the person who requested the feature.
7. How do you handle a library or platform version upgrade?
Why ask: unmaintained dependencies are the most common way an internal
application quietly becomes a liability.
Good answer: treats upgrades as scheduled work, reads release notes,
upgrades in a branch, and knows how to roll back.
8. What have you learned in the last year, and how did you learn it?
Why ask: the stack you hire for today will not be the stack in four years.
Good answer: names something specific and concrete, not a conference talk
they watched.
NOTES
[Capture specific examples, named systems, and red flags here.]
Set 3: Integrations, Data, and Legacy Systems
Joining systems that were never meant to talk to each other, handling sensitive data safely, and taking over code somebody else wrote. Most of the real work sits here.
Integrations, Data, and Legacy Systems Questions
APPLICATION DEVELOPER INTERVIEW: INTEGRATIONS, DATA, AND LEGACY SYSTEMS
Candidate: __
Interviewer: __
Date: __
QUESTIONS TO ASK, AND WHY EACH ONE EARNS ITS PLACE
1. Describe an integration you built between two systems that were never
designed to talk to each other.
Why ask: joining purchased systems is the defining task of in-house
application work.
Good answer: names both systems, explains how records were matched, and
describes what happened when the data did not line up.
2. How do you handle an integration when the other system’s API goes down?
Why ask: an integration without a failure plan turns one outage into two.
Good answer: retries with backoff, a queue, alerting, and a way to replay
what was missed once the other side recovers.
3. Walk me through how you would design the database tables for [a process
we run today on a spreadsheet].
Why ask: this is the most realistic live exercise you can run without a
coding platform, and it uses your real business.
Good answer: asks clarifying questions first, sketches entities and their
relationships, and explains the tradeoffs out loud.
4. How do you find and fix a query that has become slow?
Why ask: internal applications get slow as data grows, and the developer
who owns them has to notice before users complain.
Good answer: measures before guessing, reads the query plan, and
considers indexes, data volume, and the access pattern.
5. Tell me about the worst legacy code you inherited. What did you do?
Why ask: whoever you hire is inheriting somebody’s legacy code, possibly
a founder’s.
Good answer: stabilized it first, learned it before rewriting, and made
changes incrementally with a business reason for each one.
6. How do you handle sensitive data, such as employee or customer records,
inside an application?
Why ask: an internal application usually holds exactly the data that is
most expensive to leak.
Good answer: least-privilege access, no production data in test
environments, encryption, and an audit trail.
7. What is your approach to a data migration you cannot repeat?
Why ask: one-way migrations are where small companies lose real records.
Good answer: rehearses on a copy, reconciles counts and totals afterward,
and keeps a rollback path until verification is done.
8. How would you document an integration so somebody else can support it?
Why ask: the bus factor on a one-developer team is one.
Good answer: a short written runbook covering what it does, what breaks,
and who to call, kept next to the code.
NOTES
[Capture specific examples, named systems, and red flags here.]
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Release and rollback, bug triage, monitoring, and how the candidate treats a colleague who reports a problem with no useful detail.
Shipping, Support, and Maintenance Questions
APPLICATION DEVELOPER INTERVIEW: SHIPPING, SUPPORT, AND MAINTENANCE
Candidate: __
Interviewer: __
Date: __
QUESTIONS TO ASK, AND WHY EACH ONE EARNS ITS PLACE
1. What share of your week has gone to maintenance and support versus new
features?
Why ask: in-house application roles are maintenance-heavy, and a candidate
expecting greenfield work will be unhappy within months.
Good answer: a realistic split with no apology for it, and evidence they
find the support work interesting rather than beneath them.
2. Walk me through how you release a change to production.
Why ask: a developer who cannot describe their own release process has
probably never owned one.
Good answer: version control, a staging check, a deploy step, and a
rollback plan they have actually used.
3. A user says the application is broken and gives you no detail. What next?
Why ask: this is a weekly event at a small company, and the response tells
you how the developer treats colleagues.
Good answer: asks calmly for what they were doing, reproduces before
diagnosing, and confirms the fix with the same person.
4. How do you decide whether a bug gets fixed today or next sprint?
Why ask: triage judgment protects you from a developer who either panics
at everything or ignores everything.
Good answer: weighs how many people are blocked, whether money or data is
at risk, and whether a workaround exists.
5. How do you know an application is healthy without waiting for a complaint?
Why ask: monitoring is the difference between a developer who runs the
application and one who reacts to it.
Good answer: names error tracking, uptime checks, or a simple dashboard,
and describes an alert they set up themselves.
6. Tell me about an incident you caused. What did you do in the first hour?
Why ask: everybody breaks production; the recovery pattern is what varies.
Good answer: restored service first, communicated early, and only then
investigated the cause and wrote up the lesson.
7. How do you handle being the only developer, with no one to ask?
Why ask: this will be the actual working condition at most small
businesses.
Good answer: has an outside network, uses documentation well, timeboxes
the struggle, and escalates before the deadline rather than after.
8. What would you want in place before you took a two-week vacation?
Why ask: it surfaces documentation, monitoring, and handover habits in a
single non-threatening question.
Good answer: a runbook, alerts routed to someone, and a short list of
known risks with instructions.
NOTES
[Capture specific examples, named systems, and red flags here.]
Set 5: Behavioral and Situational
Missed deadlines, technical disagreements, requests that jump the queue, and career direction. Past behavior predicts performance better than stated intentions.
Behavioral and Situational Questions
APPLICATION DEVELOPER INTERVIEW: BEHAVIORAL AND SITUATIONAL
Candidate: __
Interviewer: __
Date: __
QUESTIONS TO ASK, AND WHY EACH ONE EARNS ITS PLACE
1. Tell me about a time you missed a delivery date. What happened?
Why ask: estimate accuracy and honesty matter more than raw speed on a
team with no project manager.
Good answer: names the cause without blaming, describes when and how they
raised the flag, and what they changed afterward.
2. Describe a disagreement with a colleague about a technical decision.
Why ask: a solo developer with no ability to lose an argument gracefully
becomes a bottleneck for the whole company.
Good answer: separates the decision from the person, commits fully once
the call is made, and can name a time they were wrong.
3. Give an example of something you automated that was not asked for.
Why ask: initiative is what makes an in-house developer pay for
themselves.
Good answer: a small, specific improvement with a stated time saving and
a named beneficiary.
4. Tell me about the most frustrating user you have worked with.
Why ask: how a candidate talks about non-technical colleagues predicts how
your staff will experience working with them.
Good answer: describes the frustration honestly but with respect, and
ends with something that improved.
5. How do you handle a request that arrives directly from the owner and
jumps the queue?
Why ask: at a small business, this happens constantly, and it is the main
source of quiet resentment.
Good answer: makes the tradeoff visible, states what slips, and lets the
business decide rather than silently absorbing it.
6. Describe a time you had to learn an unfamiliar system fast.
Why ask: your stack will not match their last one exactly.
Good answer: describes a method, reading the code, tracing one request end
to end, or shadowing a user, plus how long it took.
7. What kind of work do you want to be doing in three years?
Why ask: a one-developer role has no ladder, and mismatch here is the
most common reason these hires leave.
Good answer: is specific and honest, and matches what this job can
realistically offer.
8. Why does this role interest you, given what we do?
Why ask: candidates who want a product engineering job at a technology
company will treat this as a stopgap.
Good answer: shows they read the posting, understood the business, and
are drawn to owning applications end to end.
NOTES
[Capture specific examples, named systems, and red flags here.]
Set 6: Interview Scorecard (1 to 5 Rubric)
Rate each area with a line of written evidence, so the decision still makes sense a week later. The asset most question lists leave out.
Application Developer Interview Scorecard (1 to 5 Rubric)
APPLICATION DEVELOPER INTERVIEW SCORECARD
Candidate: __
Interviewer: __
Date: __
Score each area from 1 (poor) to 5 (excellent). Write one line of evidence
from the interview next to every score, not a general impression.
SCORING AREAS
Requirements and stakeholder work Score: [ 1 2 3 4 5 ]
Communication with non-developers Score: [ 1 2 3 4 5 ]
Evidence: __
SUMMARY
Total score: ______ / 30
Overall recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: __
Interviewer signature: __
Weighting note: for an in-house role, communication and maintenance often
predict success better than raw coding depth. Decide the weighting before the
first interview, not after you meet a candidate you like.
Note: have every interviewer score independently before the group discusses,
so one strong opinion does not anchor the rest.
Judging Answers When Nobody on Your Side Codes
Grade the shape of the answer, not its technical content. A strong technical answer has a recognizable structure: what the candidate observed, what they suspected, how they narrowed it down, and the specific cause they found. You can hear whether that structure is there without understanding a single framework name.
Three questions do most of the work for a non-technical interviewer. Each one has a strong and a weak version that is audible to anyone.
Walk me through how you debugged a problem you could not reproduce.
Strong answer: A strong answer is a story with a shape: what they saw, what they suspected, how they narrowed it down, and the actual cause. You do not need to follow the technical detail to hear whether there was a method. Ask what the root cause turned out to be and listen for a specific answer.
Weak answer: A weak answer stays at the level of I looked at the logs and fixed it, or jumps straight to a rewrite without ever isolating the cause.
Explain something you built to me as if I were the person who requested it.
Strong answer: A strong answer avoids jargon without talking down, starts from the business problem, and checks whether you are following. This is the single most useful question for a non-technical interviewer, because the ability to explain clearly is also the skill you will depend on weekly.
Weak answer: A weak answer buries you in framework names and architecture, or gets visibly impatient when asked to simplify.
How would you design the tables for a process we run on a spreadsheet today?
Strong answer: A strong candidate asks questions before drawing anything: who owns the record, what happens when a value changes, what must never be deleted. Watch the questions, not the diagram. Curiosity about your business is the signal.
Weak answer: A weak answer starts drawing immediately, or produces a design without asking what the process is actually for.
Then buy one hour. A trusted senior developer from your network, or a contractor you already work with, sitting in on one technical conversation with your finalist will catch things no question list can. At the salary level involved, one paid hour is the cheapest insurance available.
What to Probe For (and Red Flags)
The listed questions open the door; the follow-ups are where you learn something. Push for the specific: the named root cause, the actual outcome, the tradeoff they chose and what it cost. Vagueness that survives two follow-ups usually means the candidate was nearby when the work happened rather than doing it.
Ownership signals
Describes a release and rollback they ran
Talks about users by role, not as tickets
Documented something without being told to
Depth signals
One stack described in real detail
A named root cause, not a vague fix
Can explain a decision they later regretted
Fit for an in-house role
Comfortable with a maintenance-heavy week
Wants access to users and end-to-end ownership
Realistic about a team of one
Red flags
Every past problem was somebody else’s fault
Wants to rewrite everything before learning it
Dismissive about supporting non-technical users
The most useful follow-up in a developer interview is simply what happened next. If a candidate mentions a rewrite, ask what it cost and whether it shipped. If they mention a bug, ask what the cause turned out to be. Adjacent role kits such as full stack developer questions and web developer questions are worth borrowing from when your posting leans that way.
How to Run the Interview
Run it as a structured process: the same core questions for everyone, one job-related exercise, scores written before discussion. The sequence below works for a single owner or a small panel, and it is deliberately short, because a slow process loses good developers.
Step
What to do
Time
1. Prepare
Pick sets that match your stack and workload; write the questions down
30 minutes, once
2. Screen
Confirm stack, availability, comp range, and interest in an in-house role
20 minute call
3. Structured interview
Ask the same core questions from all five sets, in the same order
45 to 60 minutes
4. Exercise
One short paid task or a design discussion about a real process of yours
2 to 3 hours, paid
5. Second opinion
One hour of an experienced developer’s time on your finalist
1 hour, paid
6. Score and decide
Rate each area 1 to 5 with evidence, independently, then compare
15 minutes each
Score immediately after each interview, while the answers are still specific in your memory. If more than one person interviews, everyone writes their scores before the group talks, so the most senior voice in the room does not set the answer for everyone else.
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
Fair, legal, and structured are the same practice described three ways. Asking every candidate the same job-related questions keeps you compliant, reduces bias, and produces better hires at once. Technical hiring needs this more than most, because unstructured developer interviews drift toward whatever the interviewer happens to know.
Ask about the job, not the person
Federal anti-discrimination law, enforced by the EEOC, prohibits basing hiring decisions on protected characteristics, and questions that touch them create risk even when they are asked as friendly small talk. Avoid age, race, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Developer interviews have a specific trap: graduation years, first computer stories, and where are you originally from all invite age and national origin inferences without any job-related purpose. Ask what the candidate has built and how they work instead. You may ask whether someone can perform the essential functions of the role and whether they are authorized to work in the United States. This is general information, not legal advice.
Use the same core questions for every candidate
A structured interview, where every candidate answers the same questions and is scored against the same rubric, predicts on-the-job performance better than a free-flowing conversation and reduces the chance the decision rests on rapport. For technical hiring this matters more than usual, because unstructured developer interviews drift toward whatever the interviewer happens to know, which rewards candidates who share the hiring manager’s background rather than candidates who can do the job. Write the questions before the first interview, ask them in the same order, and score immediately afterward. The six sets on this page are built to be used exactly that way.
Keep the technical exercise job-related and paid
If you use a work sample, keep it close to the actual job and short enough to be reasonable: a two to three hour scoped task, or a live walkthrough of a real problem you have already solved. Multi-day unpaid take-home projects filter for people with free evenings rather than people who are good, which narrows your pool along lines that have nothing to do with skill. Pay for anything substantial, give every candidate the identical task, and grade it against written criteria you set in advance. Never use a candidate’s exercise output in your production systems, and say so in the instructions.
Handle code samples and prior employers carefully
When a candidate shows you work from a previous job, do not ask for proprietary source code, screenshots of internal systems, or anything covered by their current confidentiality obligations, and stop them if they volunteer it. A candidate who freely shares a former employer’s code is showing you what they will do with yours. Public repositories, open-source contributions, and a verbal walkthrough of an architecture at a general level are all fair game. Confirm your own confidentiality and IP terms in writing before the new hire touches a repository. This is general information, not legal advice.
Structure Beats Rapport, Especially in Technical Hiring
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation, and asking the same job-related questions of everyone also keeps you within the EEOC rules against basing decisions on protected characteristics. In developer hiring the effect is amplified: without a written question set, interviewers default to the technologies they personally know, which rewards candidates who share their background rather than candidates who can do the job.
Keep the small talk off graduation years, first computers, and country of origin. Those feel like rapport and read like age and national origin questions. This is general information, not legal advice.
What This Hire Costs
Decide your target pay before the first interview, because it determines which candidates you can realistically close. Federal data does not track application developers separately: the occupation is Software Developers, SOC 15-1252, and the spread inside it is unusually wide.
Software Developers, National Wage Ladder
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers (SOC 15-1252) earned a median of $135,980 per year, or $65.38 per hour. The 10th percentile earned $82,460, the 25th $105,210, the 75th $171,980, and the 90th $214,670 (U.S. Bureau of Labor Statistics, OEWS national estimates). The Bureau also projects 15 percent growth for software developers, quality assurance analysts, and testers from 2024 to 2034, with about 129,200 openings a year.
The national median is weighted toward technology employers in expensive metros, so a distributor in Ohio should not anchor to it. Benchmark against employers of your size and location, pick a percentile deliberately, and publish a good-faith range wherever pay transparency laws apply.
One classification point belongs in the interview conversation rather than after it. Most application developer roles meet the computer employee exemption, but support-heavy versions may not, and the Department of Labor is explicit in Fact Sheet 17E that job titles never determine exemption status. Settle the classification before you make the offer.
Interviewing a Developer Without HR
At a technology company, a developer candidate is graded by three other developers with a recruiter coordinating scorecards. At a small business, the owner runs the interview alone, often with no one internal qualified to judge the technical answers. Here is how to close that gap without pretending it does not exist.
Nobody in the room can read the candidate’s code
At a technology company, a developer candidate is graded by three other developers. At a distributor, a clinic, or an agency hiring its first in-house developer, the interviewer is usually the owner or the operations lead, and there is no one internal qualified to judge the technical answers. That is a real constraint, not a reason to skip the technical questions. Ask the questions anyway and grade the shape of the answer: was there a method, a specific root cause, a named tradeoff. Then buy one hour of a trusted senior developer’s time, from your network or a contractor you already use, to sit in on a single technical conversation with your final candidate. One paid hour is the cheapest insurance available on a hire at this salary level.
You are interviewing for a team of one, with no ladder and no backup
The role you are filling has no senior developer to escalate to, no code review partner, and no obvious promotion path. Interview for that honestly rather than pretending the job is something it is not. Ask directly how the candidate handles being the only developer, what they would want in place before a two-week vacation, and what they want to be doing in three years. Candidates who need a peer group will say so, and that is useful information in both directions. The compensating attractions are real: end-to-end ownership, direct access to the people using the software, and visible impact on the business. Sell those, because you will not win on salary.
The interview is one step; the offer and access setup are where risk lives
Once you choose someone, the work shifts from evaluating to hiring well: a written offer, confidentiality and intellectual property terms signed before any repository access, system credentials granted deliberately, and a structured first 90 days so the new developer learns your business before rewriting anything. FirstHR covers that people side for a small business: send the offer and the confidentiality agreement for e-signature, run new hire paperwork through an onboarding workflow, assign access and policy tasks, and keep every signed document on the employee profile. To be clear on scope, FirstHR is an onboarding and HR platform, not a code repository, an IT provisioning tool, or a technical assessment platform, so pair it with those. Applicant tracking is coming soon to FirstHR.
The rest of our hiring templates cover the surrounding steps, from the posting through the reference check, if you are building the process from scratch. Applicant tracking is coming soon to FirstHR.
From Interview to Onboarding
The interview is one step. Once you choose someone, the risk moves to the paperwork and the access: a written offer letter, confidentiality and intellectual property terms signed before anyone touches a repository, and a structured first 90 days so the new developer learns your business before proposing to rewrite it.
Prepare the question set
Pick the sets that match your actual stack and workload, and ask the same core questions of every candidate so the comparison is fair.
Score on the rubric
Rate each area 1 to 5 with a line of written evidence, independently, before anyone in the group shares an opinion.
Send the offer and the IP terms
Confirm role, pay, and start date in writing, with confidentiality and intellectual property assignment signed before repository access.
Onboard and grant access deliberately
Give the new developer a structured first 90 days: systems access, a guided tour of the codebase, and a first shipped change in week two.
A good first month for a developer looks different from most roles: read-only access first, a guided tour of the systems, and one small change shipped in week two so they learn your release process on something low-stakes. Our developer onboarding guide lays out that sequence in detail.
FirstHR connects the offer, the confidentiality agreement, e-signature, access tasks, and the onboarding workflow in one place, and keeps every signed document on the employee profile, so a small business can run the whole hiring-to-onboarding handoff from one system. FirstHR is an onboarding and HR platform, not a code repository, an IT provisioning tool, or a technical assessment platform, so pair it with those. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess an in-house application developer on requirements, craft, integrations, maintenance, and behavioral evidence, in that order of weight.
Grade the shape of the answer, a method, a specific root cause, a named tradeoff, rather than technical content you cannot evaluate.
Ask what share of the candidate’s week has gone to maintenance versus new features, because in-house work is maintenance-heavy by nature.
Keep any work sample short, paid, job-related, and identical for every candidate, and grade it against criteria written in advance.
Buy one hour of an experienced developer’s time to sit in on a single technical conversation with your finalist.
Score each area 1 to 5 with written evidence before anyone discusses, and settle pay and FLSA classification before the offer.
Frequently Asked Questions
What questions should I ask an application developer in an interview?
Ask across six areas: requirements and stakeholder work, technical craft and code quality, integrations and data, shipping and maintenance, behavioral evidence, and a scored summary. Strong core questions include tell me about an application you built for people who were not developers, walk me through how you debugged a problem you could not reproduce, describe an integration between two systems that were never designed to talk, what share of your week has gone to maintenance versus new features, and tell me about a piece of your own code you later regretted. Each question should have a stated reason you are asking it and a note on what a good answer sounds like, so a non-technical interviewer can grade the response. This page includes 40 such questions in six downloadable sets plus a 1-to-5 scorecard.
How do I interview a developer if I am not technical myself?
Grade the shape of the answer rather than the technical content. A strong answer to a debugging question has a method behind it: what the candidate observed, what they suspected, how they narrowed it down, and the specific root cause they found. You can hear whether that structure is present without following the technology. Three questions work especially well for a non-technical interviewer: explain something you built as if I were the person who requested it, walk me through a bug you could not reproduce, and how would you design the tables for a process we run on a spreadsheet today. Then buy one hour of a senior developer’s time from your network to sit in on a single technical conversation with your finalist. One paid hour is inexpensive insurance on a hire at this salary.
Should I give an application developer candidate a coding test?
A short work sample is useful, but keep it close to the real job and keep it reasonable. A two to three hour scoped task, or a live walkthrough of a problem you have already solved internally, tells you far more than an algorithm puzzle unrelated to your systems. Multi-day unpaid take-home projects filter for candidates with free evenings rather than candidates who are good, so pay for anything substantial. Give every candidate the identical task, grade it against written criteria you set before the first submission, and never use candidate output in your production systems. For an in-house application role, a design discussion about one of your actual processes is often the single most predictive exercise you can run.
What is the difference between an application developer and a software engineer interview?
The occupation is the same, so the difference is in emphasis rather than in the classification. Federal data folds both titles into Software Developers, SOC 15-1252. An application developer interview at a non-technology company should weight requirements gathering, integrations between purchased systems, maintenance and support, and the ability to explain technical work to non-developers. A software engineer interview at a product company weights algorithms, systems design at scale, and product engineering practice more heavily. If you are hiring someone to own the applications your business runs on, interview for ownership, communication, and maintenance judgment, and treat deep algorithmic screening as the lower priority it actually is for that job.
What are the biggest red flags in an application developer interview?
Watch for four. First, every past problem was somebody else’s fault, which predicts how the candidate will describe your systems to the next employer. Second, wanting to rewrite everything before understanding it, which is how a small company loses a year of working software. Third, dismissiveness toward non-technical colleagues, which matters enormously in a role where users sit twenty feet away. Fourth, vagueness under follow-up: a candidate who cannot name a specific root cause, a specific tradeoff, or a specific outcome is describing work they did not personally do. One more to watch for on the compliance side is a candidate who volunteers a former employer’s proprietary source code, because that is a preview of how they will treat yours.
How much does an application developer cost to hire?
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), the median annual wage for software developers, the occupation that covers application developers, was $135,980, or $65.38 per hour. The spread is wide: the 10th percentile earned $82,460 and the 90th percentile earned $214,670. National medians are weighted heavily toward technology employers in expensive metros, so a non-technology company hiring an in-house application developer should benchmark against employers of similar size and location rather than the national figure. Decide your target percentile before interviewing, because it determines which candidates you can realistically close, and publish a good-faith range wherever pay transparency rules require one.
What questions are illegal to ask in a developer interview?
Avoid any question that probes characteristics protected under federal law, which the EEOC enforces: age, race, color, religion, national origin, sex, pregnancy or family plans, disability, and genetic information. Developer interviews have some specific traps that feel like rapport building. Asking what year did you graduate, what was your first computer, or where are you originally from invites age and national origin inferences with no job-related purpose. You may ask whether the candidate can perform the essential functions of the job and whether they are legally authorized to work in the United States. The simplest safeguard is asking the same job-related questions of every candidate and scoring them on the same rubric. This is general information, not legal advice.
How long should an application developer interview process take?
Two to three rounds is usually right for a small business. Round one is a 45 to 60 minute structured conversation using the question sets, covering requirements, craft, and maintenance. Round two is a technical exercise or a design discussion about one of your real processes, ideally with an experienced developer from your network in the room. Round three, when you need it, is a short conversation with the people who will actually use the application, because their reaction to how the candidate explains things is genuinely predictive. Move fast between rounds: strong developers hold multiple processes at once, and a small business that takes three weeks to schedule a second interview loses candidates to employers who took three days.
