Interview questions to ask while hiring a LAMP developer

A LAMP developer interview has to test four systems, not one language. LAMP is Linux, Apache, MySQL, and PHP, and a candidate can write clean PHP and still have no idea why the site fell over at 2am. The 35 questions below are grouped by what each one proves, and every question says what a strong answer sounds like so you can score it in the room.

The stack is not a legacy curiosity. PHP runs 69.9% of all websites whose server-side language is known, and 18.9% of respondents to Stack Overflow's 2025 developer survey said they work with PHP, alongside 40.5% who work with MySQL. So most LAMP hiring is maintenance-heavy work on systems that already carry revenue. That should change what you ask.

TL;DR

• Screen for stack skills with a scored test first, then spend interview time on judgement, not trivia a candidate can memorise overnight.
• Ask about the four components separately. Strong PHP plus weak Linux is the most common gap on this stack, and resumes hide it.
• The fastest seniority filter in 2026 is one version question: PHP 8.1 and earlier are end of life, so what a candidate last shipped on tells you whether they do current work or maintenance work.
• Security and performance questions separate people faster than syntax questions. Prepared statements, file uploads, and slow-query hunting are where real experience shows.
• Write down what evidence each competency needs before you write the questions. The table further down does this for you.

What does a LAMP developer actually do?

A LAMP developer builds and runs web applications on four open-source layers: Linux as the operating system, Apache as the web server, MySQL as the database, and PHP as the language. The job is full-stack on the server side. They write application code, design and tune the schema, configure the web server, and keep the whole thing patched and running.

The variant you will hear most often is LEMP, which swaps Apache for Nginx. Plenty of candidates have run both, and a developer who can explain when they would pick one over the other is telling you something useful about how they think about traffic. Do not treat the swap as a knowledge gap.

Pay expectations are worth setting before you write the posting. The U.S. Bureau of Labor Statistics reports a median annual wage of $92,650 for web developers as of May 2025, with employment projected to grow 5 percent from 2025 to 2035 and about 13,600 openings a year over that decade. Pay for LAMP work sits in that band, higher where the role owns the server layer too.

How do you screen LAMP skills before the interview?

Run a scored skills test before anyone books an interview slot. Test PHP, MySQL, and Linux separately so the report shows you where the candidate is strong instead of one blended number. Then use the interview for the things a test cannot see: how they reason under pressure, how they explain a failure, and how they work with people who did not write the code.

Testlify's LAMP developer test covers the stack end to end, and you can pair it with the PHP skills assessment, the Linux administration test, or the SQL test when the role leans one way. Coding questions run in an embedded VS Code editor, support multiple-file projects, and take up to 20 test cases that can be hidden from the candidate, with SQLite database test cases for query work. There is also a vibe coding question type, which lets a candidate direct AI tools to a working solution instead of typing syntax by hand. On a stack where most real work is reading and fixing someone else's code, that is closer to the job than a whiteboard.

Pro tip: set one hidden test case that only passes if the candidate handles a null or an empty result set. Most submissions that look correct fail it, and the ones that pass are worth an interview.

25 general LAMP developer interview questions

These cover Linux, Apache, MySQL, and PHP in roughly that order, then move into operations. Ask 8 to 10 of them, not all 25. Pick the ones that match the system the person will actually inherit.

1. How do you set up a LAMP stack on a Linux server?

Look for: a real sequence with package manager commands, config file paths, and a firewall step, not a recital of four product names. Candidates who have only ever used a one-click installer usually stall here.

2. How would you secure an Apache web server?

Look for: turning off unused modules, TLS with a redirect from plain HTTP, correct file permissions, and hiding the server version banner. A good answer names the tradeoff between .htaccess convenience and the performance cost of per-directory overrides.

3. How would you optimize a slow MySQL database?

Look for: reading the slow query log first, then EXPLAIN on the worst offenders, then indexes. Anyone who opens with "add more indexes" before measuring is guessing, and over-indexing a write-heavy table is a real cost.

4. What are the most common PHP security holes, and how do you close them?

Look for: SQL injection, cross-site scripting, and cross-site request forgery, each with a named fix: prepared statements, output escaping, and per-form tokens. Injection has sat at the top of application security lists for years and still ships in new code.

5. What is the .htaccess file for, and when would you avoid it?

Look for: rewriting URLs, access control, and custom error pages, plus the fact that Apache reads it on every request. The senior answer is to move the rules into the main config when you control the server.

6. A PHP page takes 8 seconds to load. Walk me through finding out why.

Look for: a method, not a tool list. Profile first with something like Xdebug, check the query count for an N+1 pattern, look at external API calls, then check server resources. Candidates who jump straight to "add caching" are hiding a diagnosis they cannot do.

7. When would you choose MySQL over another database, and when would you not?

Look for: honest tradeoffs. Mature replication and cheap hosting on one side; weaker support for complex analytical queries and JSON-heavy documents on the other. A candidate who says MySQL is always the right answer has not used anything else.

8. How do you configure virtual hosts in Apache?

Look for: separate config files per site, document root, ServerName and ServerAlias, and enabling the site properly rather than editing the default. Ask what they do about the certificate for each host.

9. Describe a server migration you have run.

Look for: the unglamorous parts. Database dump and restore, file sync, config differences, DNS time to live lowered in advance, and a rollback plan. If nothing went wrong in their story, they probably were not the one doing it.

10. How does session handling work in PHP, and where does it break?

Look for: session storage on disk by default, and why that breaks the moment you put two servers behind a load balancer. The fix, moving sessions to a shared store, is the answer you want to hear.

11. How would you put a LAMP application behind a load balancer?

Look for: health checks, shared sessions, shared file uploads, and a single source of truth for the database. Naming a balancer is the easy half; knowing what breaks when you add a second app server is the half that matters.

12. When do you write procedural PHP and when do you write classes?

Look for: a practical line rather than a lecture on paradigms. Small scripts and glue code stay procedural, application logic gets structured. Watch for candidates who treat one style as morally correct.

13. How do you handle errors and logging in production PHP?

Look for: exceptions with a global handler, errors never displayed to users, structured logs going somewhere searchable, and alerting on the ones that matter. Ask what they log on purpose and what they deliberately do not.

14. Apache is fine at 100 users and falls over at 1,000. What do you change?

Look for: which multi-processing module is in use, worker and connection limits, KeepAlive settings, compression, and putting a cache in front. The strongest answers check whether the bottleneck is Apache at all before tuning it.

15. What is a prepared statement, and why does it matter?

Look for: query and data sent separately so user input is never parsed as SQL. Ask them to say it in one sentence. Anyone who can explain it plainly has almost certainly written one.

16. How would you build a REST API in PHP?

Look for: routing, correct HTTP verbs and status codes, JSON responses, authentication, and rate limiting. Framework choice matters less than whether they return 404 and 422 correctly instead of 200 with an error message inside.

17. How do you set up TLS on Apache?

Look for: obtaining and installing the certificate, the virtual host config, redirecting plain HTTP, and automatic renewal. Renewal is the part people forget, and forgetting it is what takes a site down on a Saturday.

18. How do you manage dependencies in a PHP project?

Look for: Composer, the difference between the manifest and the lock file, and why the lock file belongs in version control. Ask how they handle a package that stops being maintained.

19. What is the difference between MyISAM and InnoDB?

Look for: transactions, foreign keys, and row-level versus table-level locking. The useful follow-up is whether they have ever had to convert a legacy table, and what broke when they did.

20. What do you monitor on a LAMP server, and what wakes you up?

Look for: a short list they would actually act on. Error rate, response time, database connections, disk space, and certificate expiry. A candidate who monitors everything and alerts on everything has never been on call.

21. How do you handle file uploads safely?

Look for: validating type by content rather than extension, size limits, renaming the file, and storing it outside the web root. Uploads are the single most common way a PHP application gets taken over.

22. Where do LAMP applications usually get slow?

Look for: the database first, nearly always. Then unindexed queries, N+1 loops, no object cache, and images served without compression. Good candidates rank these by how often they see them.

23. How do you run several sites from one server without them interfering?

Look for: virtual hosts, separate document roots, separate database users, and separate PHP-FPM pools or users so one compromised site cannot read another's files. Isolation is the point, not just routing.

24. How would you implement login and password storage?

Look for: a modern hashing function with a work factor, never a plain hash, plus session regeneration after login, rate limiting, and a safe reset flow. If they mention writing their own crypto, stop and dig in.

25. How do you back up MySQL, and when did you last restore one?

Look for: scheduled dumps or snapshots, off-server storage, and a tested restore. The restore half of the question is the one that matters. A backup nobody has restored is a guess.

5 code-based LAMP developer interview questions

Give these as short written tasks, 15 to 20 minutes each, ideally before the interview so you can discuss the code instead of watching someone type. Every one of them has a wrong answer that still runs, which is what makes them useful.

1. Connect to MySQL with PDO and fetch one row by id. Look for a prepared statement, exception mode turned on, and credentials that are not hardcoded in the file.
2. Write a query that returns active users who have not logged in for 30 days. Look for correct date handling and an index-friendly condition rather than a function wrapped around the indexed column.
3. Write an .htaccess rule that sends all HTTP traffic to HTTPS. Look for a 301 rather than a 302, and no redirect loop when the site sits behind a proxy.
4. Write a file upload handler for profile images. Look for content-based type checking, a size cap, a generated filename, and storage outside the web root. This is the task that separates careful developers from fast ones.
5. Update a user's email by id, safely. Look for a parameterised update, a check that the row exists, and something sensible when the new address is already taken.

How do you tell a senior from a mid-level candidate?

Seniority on this stack is not about knowing more syntax. It shows up in the size of the system someone has been responsible for and in how they talk about things going wrong. These five questions get at that.

1. Which PHP version did your last production application run on, and who decided? PHP 8.1 and everything before it is past end of life, and 8.2 leaves security support on 31 December 2026. A candidate still on 7.4 is not disqualified, but their answer tells you whether they drive upgrades or wait for them.

2. Tell me about a LAMP application you inherited. What was wrong with it? Listen for specifics and for fairness about the people who wrote it. Contempt for the previous team is a reliable warning sign.

3. Describe the worst production incident you were part of. You want the timeline, the diagnosis, the fix, and what changed afterwards. Junior candidates describe the bug. Senior ones describe the process that let it ship.

4. What is the largest table you have worked with, and what did it force you to do differently? Numbers matter here. Someone who has dealt with 200 million rows has opinions about migrations, index rebuilds, and archiving that cannot be faked.

5. How do you hand work to a front-end developer or a designer? Most LAMP roles sit between infrastructure and interface. Look for someone who documents endpoints, agrees on data shapes early, and does not treat handover as an interruption.

Which competencies should each question prove?

Questions are only as good as the evidence they produce. The Testlify Competency-to-Evidence Matrix maps every role to the competencies that matter, then connects each competency to measurable evidence through assessments, simulations, interviews, references, and structured feedback. Start with the role, not with a test. Here is that map for a LAMP developer.

Weighting is yours to set. For a role that inherits a live system, security and debugging should outweigh framework knowledge. For a greenfield build, flip it.

When should you ask these questions?

Put the skills test first, right after the application. It costs the candidate 30 to 45 minutes and it costs you nothing in interview time, so the shortlist you invite has already proved it can do the work. Score it before anyone reads a resume, which keeps the first filter about ability rather than where someone worked.

Use the first interview for the general and seniority questions, picking 8 to 10 that match the system the person will own. Use the second for the code tasks, discussed rather than performed, plus whoever they will work with day to day. Two rounds is enough for almost every LAMP role. Teams that add a third usually do it because nobody wrote down what evidence they needed, which is the problem the matrix above solves.

One caveat worth saying plainly: none of this predicts anything if the assessment is harder than the job. A test full of obscure syntax will filter out good maintenance engineers and select for people who prepare for tests. Keep the tasks close to the work.

Hire LAMP developers on evidence, not resumes

Set up a scored LAMP assessment, send it with the application form, and interview only the candidates whose results clear your bar. Building one from the tests linked above takes an afternoon, and a broader backend developer assessment works when the brief is wider than LAMP. If the role leans toward a framework, the PHP Laravel developer job description and the MySQL developer template will help you write the posting first. Book a demo to see the coding and proctoring setup on your own role.

Key takeaways

• Test the four layers separately. Linux, Apache, MySQL, and PHP are different skills, and a blended score hides the gap you will pay for later. A candidate strong in PHP and weak in Linux is the most common profile on the market, which matters because most LAMP roles own the server as well as the code.
• Screen before you interview. A scored test costs a candidate under an hour and saves your team several. It also moves the first filter from resume keywords to demonstrated ability, which is the only part of the process you can defend if a rejected candidate asks why.
• Ask about versions. PHP 8.1 and earlier are out of support and 8.2 loses security fixes at the end of 2026. What a candidate last shipped on, and whether they pushed for the upgrade, separates people who drive maintenance from people who inherit it.
• Weight security and performance above syntax. Prepared statements, file upload handling, and slow-query diagnosis are where experience is visible. Syntax questions are the easiest thing in this article to memorise and the least useful thing to select on.
• Decide what evidence you need before you write questions. Map each competency to the artifact that proves it, then pick questions that produce that artifact. Interviews that skip this step end up measuring confidence, and confidence is not a competency on this stack.
• Keep the assessment close to the job. If the test is harder or more obscure than the daily work, you will select for test preparation instead of engineering, and the good maintenance candidates will drop out before the interview.

FAQs