Sign in
PapaHR · Mike Pritula Academy · Roles

Software Developer: Role Profile, KPIs and Interview Questions

Find a software developer role profile, key performance indicators (KPIs) and hiring materials. Use them to agree on business outcomes and assess how independently a candidate can work.

Build the profile for your company Open in PapaHR for free →

Job profiles, hiring, onboarding and reviews are in PapaHR. Free for up to 25 employees.

  1. Take the profile below or build your own with the builder.
  2. In PapaHR the profile turns into a job ad, an onboarding plan and probation goals.
  3. After 90 days, review the person against the same KPIs and competencies.

Job profile

Why the role exists

Build and maintain software that helps customers and reduces manual work for the business.

Result in a year

Agreed changes are working for users, critical scenarios have automated tests, and another developer can understand the code and continue the work.

Place in the structure

  1. Reports toEngineering Manager; in a small team, the project's technical lead.
  2. Direct reportsNone
  3. Works withProduct manager — user value and acceptance criteria, Project manager — deadlines, dependencies and task priorities, Software tester — test scenarios and reproducing defects, Designer — interface behaviour and unclear states, Customer support — user problems after release, Information technology (IT) specialist — access and development environment
Key result areas
  1. Users receive the agreed changes — Development plan completionExample: 100% of the agreed plan completed.
  2. Completed work passes acceptance without rework — First-pass acceptance rateExample: 100% of tasks accepted at their first review.
  3. Automated tests protect important scenarios — Automated testing plan completionExample: 100% of planned scenarios protected by working tests.
  4. Defects are fixed within agreed deadlines — On-time defect resolutionExample: 100% of defects due for resolution fixed on time.
  5. The team can maintain released changes — Release documentation readinessExample: 100% of planned documentation ready for release.
Requirements

Experience: Independent changes to a live product, matching the role's seniority.

Formal: Ability to explain your code and decisions; relevant degree optional.

Should know

  • The team's programming language and libraries
  • Data storage and integrity checks
  • Version control and collaborative development
  • Automated software testing methods
  • Error handling, access permissions and protecting secrets
  • Build, release and rollback procedures

Should be able to

  • Read existing code before changing behaviour
  • Reproduce defects and verify their causes
  • Write tests for important scenarios and constraints
  • Explain technical decisions in language the business understands
  • Estimate work with unknowns and dependencies
  • Hand over changes with testing and maintenance instructions
Competencies at three levels

Understanding the problem

Prevents time being spent on features that do not solve users' problems.

  1. Restates the task and clarifies unclear requirements before starting.basic
  2. Agrees scenarios, constraints and completion criteria before estimating delivery.solid
  3. Identifies unnecessary work and proposes a simpler route to the required outcome.strong

Clear, maintainable code

Reduces the cost of future changes and reliance on one person.

  1. Follows the project structure and addresses code review feedback.basic
  2. Separates component responsibilities and explains design choices.solid
  3. Simplifies complex areas gradually while preserving working product behaviour.strong

Quality and testing

Protects users from broken functionality and reduces repeated fixes.

  1. Checks the main scenario and adds tests with guidance.basic
  2. Independently checks boundaries, invalid data and related scenarios.solid
  3. Chooses tests by failure impact and addresses causes of recurring incidents.strong

Finding defect causes

Helps restore the product without speculative changes or recurring failures.

  1. Collects failure conditions and reproduces the problem in a safe environment.basic
  2. Tests hypotheses using evidence and verifies the fix by retesting.solid
  3. Isolates failures across components and proposes ways to prevent recurrence.strong

Ownership of delivery

Makes delivery dates clearer and carries changes through to a working release.

  1. Reports blockers and checks completion against the task's acceptance criteria.basic
  2. Includes testing and release in estimates and flags delays early.solid
  3. Agrees scope reductions when risks arise and verifies results after release.strong

Collaboration

Enables constructive technical discussions and code handovers without losing knowledge.

  1. Explains their code and asks colleagues specific questions.basic
  2. Gives useful feedback and discusses solutions without personal criticism.solid
  3. Helps the team agree on solutions and shares knowledge through joint work.strong
Builder

Build the profile for your company

Tick what this person does at your company. On the right is the ready profile: copy it or open it in PapaHR.

Software Developer

Build and maintain software that helps customers and reduces manual work for the business.

Duties
  1. Clarify user needs and acceptance criteria before writing code
  2. Break changes into small, testable tasks
  3. Estimate delivery dates and flag delay risks early
  4. Write clear code using the team's chosen technologies
  5. Check normal scenarios, errors and edge cases
  6. Cover important logic with automated tests
  7. Review colleagues' changes and address feedback on your code
  8. Prepare releases and a way to restore the previous version
  9. Find the causes of failures and fix defects
  10. Document setup, limitations and maintenance of changed components
  11. Integrate external services and handle connection failures
  12. Migrate data between versions and verify its integrity
  13. Improve slow operations after measuring their causes
  14. Set up automated checks before release
  15. Join an agreed on-call rota for product incidents
  16. Coach junior developers through shared tasks
  17. Assess technical constraints of new product ideas
Open the profile in PapaHR

Software developer KPIs

  1. Development plan completion — Accepted planned tasks / agreed planned tasks × 100%. Mistake: Treating unequal tasks equally; hiding delays through retrospective plan changes.weight 30% · month
  2. First-pass acceptance rate — Tasks accepted without rework / tasks first reviewed × 100%. Mistake: Excluding rejected tasks; accepting code without checking acceptance criteria.weight 25% · month
  3. Automated testing plan completion — Planned scenarios with working tests / planned scenarios × 100%. Mistake: Increasing test counts without checking important scenarios and invalid inputs.weight 20% · month
  4. On-time defect resolution — Defects fixed on time / defects due for resolution × 100%. Mistake: Counting unverified fixes; leave the measure uncalculated when no defects are due.weight 15% · month
  5. Release documentation readiness — Release-ready documents / documents in release plan × 100%. Mistake: Counting documentation that does not let a colleague run or test the change.weight 10% · month
Calculator

Work out the KPI bonus

Enter how much of each target was met, in percent, and the bonus at 100%. You can change the weights.

KPIWeight, %Achieved, %Share
Development plan completion
First-pass acceptance rate
Automated testing plan completion
On-time defect resolution
Release documentation readiness
KPI total
Bonus
Sum of weights

The weights are an example. They should add up to 100%.

Interview questions

Scorecard

Run the interview and get the result

Score each answer from 1 to 5 and the total is worked out by competency. Keep this page open on your phone during the interview.

Understanding the problem

Describe a task with incomplete requirements. What did you clarify, what did you do yourself, and how did you verify the result?

✓ Listen for: Specific questions, agreed scenarios, personal actions and a verified outcome.

⚑ Red flag: Started coding without clarification, then blamed the requester.

Tell me about a time you proposed writing less code. What problem were you solving, and what happened?

✓ Listen for: Understood the need, compared options, agreed a simpler approach and checked its value.

⚑ Red flag: Removed required behaviour without consulting the task owner.

Clear, maintainable code

Describe changing unfamiliar code. How did you understand it, what did you change, and how did you preserve existing behaviour?

✓ Listen for: Investigated dependencies, limited changes, added checks and explained the result.

⚑ Red flag: Rewrote a large section without checking dependencies.

Which decision of yours later made maintenance harder? What did you change, and what became easier?

✓ Listen for: Acknowledges a specific problem, explains the fix and its effect on colleagues.

⚑ Red flag: Cannot identify a poor decision of their own.

Quality and testing

Describe a change that broke related functionality. How did you discover it, fix it and prevent it happening again?

✓ Listen for: Identifies the missed scenario, the fix and a test detecting the original defect.

⚑ Red flag: Considers testing solely the tester's responsibility.

Tell me how you chose tests with limited time. Which risks mattered, and how did the release go?

✓ Listen for: Prioritised critical scenarios, tested errors and communicated remaining risks.

⚑ Red flag: Only tested the successful scenario and told nobody.

Finding defect causes

Describe a difficult defect you fixed. Which hypotheses did you test, and what evidence confirmed the cause?

✓ Listen for: Reproduction, observations, systematic hypothesis testing and verification of the fix.

⚑ Red flag: Changed several things at once without knowing what helped.

Describe an incident you could not reproduce locally. What information did you collect, how did you investigate, and what happened?

✓ Listen for: Checked environment and inputs, collected logs and investigated differences.

⚑ Red flag: Closed the report because it worked on their machine.

Ownership of delivery

When was your delivery estimate wrong? How did you notice, who did you tell, and how did you finish the task?

✓ Listen for: Early warning, clear cause, revised plan and an agreed result.

⚑ Red flag: Only reported the delay after missing the deadline.

Describe a release you owned. What did you prepare, what did you check afterwards, and what was the outcome?

✓ Listen for: Release criteria, rollback method, operational checks and coordination with support.

⚑ Red flag: Considers work complete as soon as code is handed over.

Collaboration

Describe a code review disagreement. What did each side propose, how did you reach agreement, and what did you decide?

✓ Listen for: Discussed consequences, used evidence and recorded the agreement.

⚑ Red flag: Used seniority to force agreement or criticised colleagues personally.

Tell me about handing a component to another developer. What did you prepare, and how did you check they could work independently?

✓ Listen for: Explained the structure, documented setup and checked the colleague could make a change.

⚑ Red flag: Sent a code link and considered the handover complete.

Score at least one answer and the result shows up here. ·
Track candidates in PapaHR

Test task

Reserve stock without partial deductions · 2 hours

Write a small function in a language agreed with the candidate. Inputs are stock levels and order lines containing a product code and quantity. Combine duplicate product lines. Quantities must be positive integers, and products must exist. If stock is sufficient, return updated stock levels. On any error, return a clear reason without changing the inputs. No database or interface is needed. Add automated tests, setup instructions and a short explanation of your decisions. Demonstrate a successful order, duplicate lines, an unknown product, invalid quantities and insufficient stock. Note any limitations if you run out of time. Use sample data only.

How to assess it

  • All requirements met; duplicate product lines combined
  • An error in one line prevents all stock deductions
  • Input data remains unchanged regardless of the result
  • Tests cover successful orders, errors and boundary values
  • Clear code without unnecessary components or dependencies
  • Instructions allow execution; limitations are stated clearly

Ready job ad

Software Developer at [company name]

We build [product] for [users]. We need a developer to own [area of responsibility].

What you will do

  • Develop [product components] using [language and technologies]
  • Agree feature behaviour with [product owner]
  • Write automated tests for important logic
  • Review colleagues' code and act on feedback
  • Fix defects and verify behaviour after release
  • Maintain setup instructions and change documentation

What we need

  • Development experience in [language] at [seniority level]
  • Ability to understand existing code
  • Experience collaborating through version control
  • Ability to write tests and investigate defects
  • Willingness to discuss deadlines, constraints and user value

What we offer

  • Salary: $[salary], [review arrangements]
  • Hours: [schedule], working arrangement: [format]
  • Location: [city]
  • Team: [team structure], reporting to: [manager's role]
  • Equipment and access: [provision arrangements]
  • Learning and feedback: [format and frequency]

In PapaHR this text becomes a job opening with a careers page and a candidate pipeline.

90-day onboarding plan

Before day one

  1. Send joining schedule and team contactsHR
  2. Prepare equipment and access with appropriate permissionsIT
  3. Choose a small first task with acceptance criteriaManager
  4. Check project setup instructions for the new starterMentor

Day one

  1. Demonstrate the product and main user actionsManager
  2. Explain secret storage and access request proceduresIT
  3. Run the project and automated checks in the development environmentNew hire
  4. Explain code review and release proceduresMentor

First week

  1. Complete the first task and add a verification checkNew hire
  2. Review the first change and explain feedbackMentor
  3. Demonstrate error logs and restoring the previous versionMentor
  4. Agree probation period goals and assessment methodsManager

30 days

  1. Release a small change under the mentor's supervisionNew hire
  2. Investigate a defect from reproduction to verified fixNew hire
  3. Discuss estimate accuracy and reasons for delaysManager
  4. Check access and team support are sufficientHR

60 days

  1. Independently clarify and complete a task of agreed complexityNew hire
  2. Add tests for risky scenarios in the changeNew hire
  3. Assess the usefulness of the new starter's code review feedbackMentor
  4. Compare results with probation period goalsManager

90 days

  1. Present released changes and evidence that they workNew hire
  2. Have another developer run the component using the new starter's instructionsMentor
  3. Assess independence, quality and delivery against the agreed planManager
  4. Discuss probation period outcomes and further developmentManager

Probation period goals

  1. Learn the workflow from project setup to releaseBy day 30, runs the project independently; a change is released with the mentor and verified.
  2. Independently carry agreed tasks through to acceptanceBy day 90, the agreed plan is complete; every task meets its acceptance criteria.
  3. Protect important changed scenarios with automated testsBy day 60, tests cover every agreed scenario and detect a deliberately introduced defect.
  4. Hand over maintenance knowledge for a changed componentBy day 90, a colleague runs the component and verifies a change using the prepared instructions.

Career path

Junior Software Developer

Completes small tasks with clear requirements and regular guidance from a mentor.

To move up: Clarify and complete routine tasks independently, write tests and address review feedback.

Software Developer

Owns the complete change: clarification, code, testing, release and maintenance.

To move up: Resolve ambiguous tasks, identify dependencies and help colleagues improve their solutions.

Senior Software Developer

Designs complex changes, reduces technical risk and develops other engineers.

To move up: For management, develop team planning, feedback and delegation skills.

Engineering Manager

Owns team outcomes, people development and a reliable release process.

To move up: Expand responsibility for technical direction as the business and team grow.

Questions for a 1:1 meeting

  1. Which current task still has an unclear user outcome?
  2. Which dependency could delay delivery, and how can I help?
  3. Where do we most often rework code after acceptance, and why?
  4. Which part of the product feels riskiest to change without more checks?
  5. Which manual release step takes the most time?
  6. Which code review comments keep recurring, and what would help?
  7. What maintenance knowledge about the component currently lives only with you?
  8. Which task would you like next to develop your independence?

Mistakes in hiring and managing

  1. Hiring from a technology checklist without discussing the candidate's decisions.
    Better: Examine a specific change: problem, code, checks, constraints and outcome.
  2. Measuring productivity by lines of code or small tasks closed.
    Better: Assess accepted changes, work complexity and quality after release.
  3. Changing requirements while keeping the original deadline without discussion.
    Better: Reagree scope, deadline and priority; keep a history of plan changes.
  4. Making the tester solely responsible for the developer's defects.
    Better: Include developer checks and automated tests in task completion criteria.
  5. Making one strong developer the sole owner of code and releases.
    Better: Use peer reviews, document setup and regularly share component maintenance.
HR in money

What a bad hire costs: Software developer

The same calculation as in PapaHR «HR in money»: the cost of hiring plus the salary for the months the new hire worked at half capacity.

One leaver
A year

In the first months a new hire delivers about half the result, so the company pays the other half of the salary for learning. In PapaHR the calculation uses your real leavers.

Questions and answers

What is the difference between a software developer and a programmer?

Job adverts often use these titles for the same role. Define whether the person will only write code or also clarify needs, test and release changes. State this in the role profile and advert.

How can a non-technical manager assess a software developer?

Ask about a past task: what was needed, what the candidate personally did and how they checked the outcome. Have an experienced developer assess and discuss the technical solution. Agree assessment criteria before interviewing.

Which performance measures work for software developers?

Start with agreed plan completion, acceptance and checks of important scenarios. Account for task complexity, new requirements and external delays. Lines of code do not show the value of a change.

Does a software developer need a technical degree?

The role requires understanding code, finding defects and releasing working changes. A degree alone does not demonstrate these abilities. Assess skills through tasks relevant to your product.

Can one developer handle an entire product?

First define the development, support and release workload. If one person handles everything, arrange code review and a way to hand over maintenance. Otherwise, leave or departure can stop product changes.

Hire, onboard and review in one system

PapaHR is free for up to 25 employees: job profiles, openings, onboarding, goals, 1:1 meetings and reviews.

Open the profile in PapaHR I have an account

Similar roles