Application Developer interview questions and how to answer them
Application developer interviews test whether you can keep a business's software working while you change it. Expect fewer algorithm puzzles than a product company would throw at you, and more SQL, more old code, and more questions about the people who use what you build. Here's what each round is looking for and how to answer the questions that come up again and again.
What happens in each round
- 1
Recruiter or HR screen
What happens
That your stack matches the posting, that you can explain your current work without jargon, and that your expectations on hybrid work and on-call fit the team.
- 2
Hiring manager conversation
What happens
How you handle users, vague requests and production problems. Many managers here were developers on the same system, so they'll ask about the messy parts of your last job.
- 3
Technical exercise
What happens
A take-home or live task that looks like real work: a small feature on a web API with a database, a SQL query against a schema they hand you, or a bug to find in existing code.
- 4
Panel with developers and a business analyst
What happens
Whether the team wants to share a codebase with you, how you review code, and whether the analyst thinks you'd listen before you build.
Questions you're likely to get
1.Walk me through an application you've built or maintained, end to end.
Why they ask
They want to see if you understand the whole thing, from the screen a user clicks to the table the data lands in, not just the part you touched.
How to answer
- Start with who used it and what problem it solved for them
- Name the stack plainly: front end, API layer, database, how it was deployed
- Pick one piece you built and explain a decision you made in it
- Mention one thing you'd change if you rebuilt it
2.Write a query that returns each customer's most recent order.
Why they ask
Almost every business app is a database with screens on top. This checks whether you can write real SQL without an ORM holding your hand.
How to answer
- Ask whether ties on order date are possible before writing anything
- Use a window function like ROW_NUMBER partitioned by customer, or a join to a grouped subquery
- Explain why you picked that approach and how it behaves on a large table
- Say which index would help
3.You've inherited a large module with no tests and the original author is gone. A change is due next week. What do you do?
Why they ask
This is the actual job at a lot of companies hiring for this title. They want to know you won't either freeze or rewrite everything.
How to answer
- Read the code path the change touches and trace it with the debugger before editing
- Write a few characterization tests around current behavior so you'll know if you break it
- Make the smallest change that meets the request
- Flag the risk to your lead and note what you'd clean up later, separately
4.A department head says the app is broken, but you can't reproduce it. What's your next step?
Why they ask
They're checking patience and method. This happens constantly with internal users who describe symptoms, not causes.
How to answer
- Go watch them do it, in person or on a screen share
- Check the logs and the exact account, browser and data they're using
- Look for what's different about their setup: permissions, a specific record, a cached version
- Close the loop with them either way, even if it turns out to be a training issue
5.How do you design a REST API for a feature like expense approvals?
Why they ask
Most application work is building endpoints that other screens and systems call. They want to see clean resource thinking and attention to permissions.
How to answer
- Name the resources and the main routes, such as expenses and approvals
- Pick sensible status codes and say how errors come back
- Cover who's allowed to approve and where that check lives
- Mention how you'd version it if other apps depend on it
6.Tell me about a production issue you handled.
Why they ask
Business apps break during business hours, in front of people. They want to know you stay calm and communicate while you fix it.
How to answer
- Set the scene briefly: what broke and who was affected
- Explain how you narrowed it down, with the actual tools you used
- Say how you kept users or your manager updated while you worked
- End with what changed afterward so it didn't happen again
7.How do you handle a request that's vague, like "make the report better"?
Why they ask
Users often ask for a solution when they have a different problem. The business analyst on the panel especially cares about this one.
How to answer
- Ask what they do with the report and what's slowing them down
- Restate the need in your own words and confirm it
- Sketch or mock the change before building it
- Agree on what done looks like so the ticket can actually close
8.What does a good pull request look like to you, and what do you look for when reviewing one?
Why they ask
Teams maintaining one codebase for years live or die on review habits. This tells them how you'll work with them every day.
How to answer
- Small, focused changes with a description that explains why
- Tests that cover the change, or a note on why they're missing
- In review, you look at correctness and data handling before style
- You leave comments as questions or suggestions, not verdicts
9.How would you speed up a page that takes too long to load?
Why they ask
Slow screens are the most common complaint internal users have. They want a method, not a guess.
How to answer
- Measure first with browser dev tools and server logs to see where the time goes
- Check the database side: missing indexes, too many queries, pulling far more rows than shown
- Look at paging, caching and whether the work can move to a background job
- Measure again after the change and tell the users
10.How do you keep sensitive data safe in an app like this?
Why they ask
Business apps hold payroll, patient or customer data. They need to trust you with it.
How to answer
- Use parameterized queries to prevent SQL injection
- Check permissions on the server, never just by hiding a button
- Keep secrets out of the repo, in a vault or the platform's secret store
- Log access to sensitive records without logging the data itself
11.Why do you want to work on internal or business applications rather than at a product company?
Why they ask
They've hired people who wanted startup work and left quickly. They want to know you'll be happy here.
How to answer
- Say what you actually like: seeing the users, solving real operational problems, a stable stack
- Be honest about the tradeoffs you're accepting
- Tie it to something specific in their posting or business
12.Tell me about a time you disagreed with a requirement.
Why they ask
They want developers who speak up when something won't work, and then commit once a decision's made.
How to answer
- Describe the requirement and the specific problem you saw with it
- Explain how you raised it, with the person and the evidence
- Say what was decided and how you handled it if you lost the argument
Mistakes that sink good candidates
Talking down about legacy code or the people who wrote it, since the panel may include them
Treating users as the problem when you describe support stories
Claiming a skill from the posting you can't discuss when they follow up on it
Skipping clarifying questions on the technical exercise and building the wrong thing fast
Need more Application Developer interviews to prep for?
HeroApply applies to Application Developer jobs that match you, every day. 852 jobs are open today.