Fundamental software engineering interview questions: fresher to experienced

Whatever language you write, most software interviews open with the same handful of questions. They are easy to underestimate. Candidates who can solve algorithm puzzles still lose offers by rambling through "tell me about yourself" or by being unable to explain their own project. This guide covers the fundamentals, in roughly the order they appear in an interview. For each one you get what the interviewer is really checking, a structure for your answer, and (where it helps) a small code example that was run to confirm it. The advice applies from a first job to a senior role; only the depth changes.

Part 1: the people questions

1. "Introduce yourself."

What they check: can you communicate clearly and briefly, and do you know what is relevant to this job? It sets the tone for the next 40 minutes.

Structure (about 60 to 90 seconds):

1. Who you are professionally: your name, your current role or degree.
2. Education, in one line, if you are early in your career.
3. Relevant experience: the technologies and kinds of work that match the job, with one or two concrete results.
4. Why this role: what you are aiming for next and why this company fits it.

Include: the field you are interviewing for, your strongest relevant skills, and a short, specific goal. Leave out: family details, personal problems, a long life story, every technology you have ever touched, and weaknesses. Do not read your CV aloud; say what the CV does not. Prepare it in writing, practise it aloud until it sounds natural rather than memorised, and adapt the second half to each company.

Example for a fresher: "I'm a final-year computer science student. I've spent the last year building web projects in PHP and MySQL, including an inventory system that my college lab now uses. I enjoy working on back-end logic and databases, and I'm looking for a developer role where I can learn from a team and take on real features."

2. "Explain your projects."

What they check: did you actually build it, and do you understand it? This is where made-up experience collapses, because the follow-up questions go one level deeper than any CV.

Structure for each project:

• The problem in one sentence: who needed it and why.
• Your role: what you personally built (be precise about "I" and "we").
• The technology and why you chose it.
• One hard problem you faced and how you solved it.
• The result: users, time saved, what you would change today.

Present projects in a sensible order (most relevant or most recent first), and be able to describe the database tables, how a request flows through the code, how you tested it and how it was deployed. Be truthful. Claiming work you did not do is the quickest way to lose trust; saying "I did not build the payment part, a teammate did, but I read through it and understand that it works like this..." is respected. Keep a link to the code or a live demo ready.

3. "What are your strengths and weaknesses?"

Choose strengths that are relevant and provable with an example ("I debug methodically: last month I traced a slow page to 200 repeated queries and cut it to 5"). For weaknesses, name a real but non-critical one and show what you are doing about it ("I used to avoid writing tests; I now write them for every bug I fix"). Avoid clichés ("I work too hard") and avoid anything that disqualifies you for the job.

4. "Why do you want to leave your current job?" / "Why this company?"

Talk about what you are moving towards (growth, a technology, bigger problems), not what you are running from. Never criticise a former employer. Research the company's product so you can say something specific.

Part 2: technical fundamentals

5. "What is object-oriented programming?"

Programming that organises code into objects that bundle data with the functions that work on it, built from classes. Name and briefly explain the four pillars: encapsulation (hide the internals, expose a safe interface), abstraction (show what it does, not how), inheritance (reuse and specialise a class) and polymorphism (one interface, many behaviours). Give one example from your own project. Language-specific details are in the Python OOP overview and the PHP interview questions.

6. "What is MVC?"

Model-View-Controller is a way to split an application into three responsibilities:

• Model: the data and business rules (database access, validation of business logic).
• View: what the user sees (HTML templates).
• Controller: receives the request, asks the model for what is needed, and chooses the view.

The benefit is separation: designers can change views without touching business rules, and models can be tested without a browser. A request flows browser, route, controller, model (database), controller, view, browser. Laravel, Django, Rails and CodeIgniter all follow variations of it. A good answer adds a limitation: "fat controllers" that hold business logic defeat the purpose, so logic belongs in models or service classes.

7. "What is a unit test? Explain in detail."

A unit test checks the smallest testable piece of code (a function or a method) in isolation, automatically, and reports pass or fail. It matters because it catches mistakes at once, protects against breaking old behaviour when you change code (regression), documents what the code should do, and makes refactoring safer.

A good unit test is fast, independent, repeatable and focused on one behaviour. A common structure is Arrange (set up the input), Act (call the code), Assert (check the result). In Python with the built-in unittest:

import unittest

def discount(price, percent):
    if not 0 <= percent <= 100:
        raise ValueError("percent must be between 0 and 100")
    return round(price * (1 - percent / 100), 2)

class DiscountTests(unittest.TestCase):
    def test_normal_discount(self):
        self.assertEqual(discount(200, 10), 180.0)

    def test_zero_percent_keeps_price(self):
        self.assertEqual(discount(99.99, 0), 99.99)

    def test_invalid_percent_rejected(self):
        with self.assertRaises(ValueError):
            discount(100, 150)

unittest.main(argv=["x"], exit=False)

Running it printed Ran 3 tests ... OK. The third test shows an important habit: test the failure cases too. In PHP the standard tool is PHPUnit or Pest, in JavaScript Jest or Vitest, in Java JUnit.

Know the vocabulary: integration tests check that several parts work together (code plus database); end-to-end tests drive the whole application like a user; mocks and stubs replace real collaborators (the e-mail service) so a unit test stays isolated; test-driven development means writing the failing test first; coverage measures how much code the tests run, which is a guide, not a goal.

8. "What are validations and where do you use them?"

Validation checks that data is acceptable (required, the right type, in range, correct format, unique) before you use or store it. Do it in several places, for different reasons:

• In the browser (HTML attributes, JavaScript) for fast, friendly feedback. This can be bypassed, so it is a convenience only.
• On the server for correctness and security. This is the one that counts: never trust input from outside.
• In the database with constraints (NOT NULL, UNIQUE, CHECK, foreign keys) as the last line of defence.

<?php
function validateSignup(array $in): array {
    $errors = [];
    $name = trim($in['name'] ?? '');
    if ($name === '' || mb_strlen($name) > 50) { $errors['name'] = 'Name is required (max 50 characters).'; }
    if (!filter_var($in['email'] ?? '', FILTER_VALIDATE_EMAIL)) { $errors['email'] = 'Enter a valid e-mail address.'; }
    $age = filter_var($in['age'] ?? '', FILTER_VALIDATE_INT, ['options' => ['min_range' => 18, 'max_range' => 100]]);
    if ($age === false) { $errors['age'] = 'Age must be a whole number from 18 to 100.'; }
    return $errors;
}
print_r(validateSignup(['name' => 'Asha', 'email' => 'asha@example.com', 'age' => '30']));
print_r(validateSignup(['name' => '', 'email' => 'not-an-email', 'age' => '12']));

The first call returned an empty array (valid); the second returned errors for all three fields. Return specific messages, keep the user's input in the form, and remember that validating (is it acceptable?) is different from escaping (making it safe to display) and from sanitising.

9. "What do you understand by functional and imperative programming?"

Imperative programming tells the computer how to do something with a sequence of steps that change state (variables, loops). Functional programming describes what to compute by combining functions, preferring pure functions (the same input always gives the same output and nothing else changes) and avoiding shared mutable state. Most real code mixes both. Functional ideas that help everywhere: map, filter, reduce, immutability, and small functions without side effects, which are easy to test.

orders = [{"total": 250, "paid": True}, {"total": 99, "paid": False}, {"total": 400, "paid": True}]

# imperative
paid = 0
for o in orders:
    if o["paid"]:
        paid += o["total"]

# functional
paid_f = sum(o["total"] for o in orders if o["paid"])
print(paid, paid_f)      # 650 650

10. "What is an API, and how do you use or build one?"

An API (application programming interface) is a defined way for one piece of software to talk to another. On the web it is usually a REST API: you send an HTTP request (GET /orders/42) and receive data, normally JSON. Know the HTTP methods (GET reads, POST creates, PUT/PATCH updates, DELETE removes), common status codes (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable, 500 Server Error) and how authentication works (API keys, tokens). Be ready to describe an API you consumed or built. Worked examples: building and calling a JSON API in PHP, the eBay Browse API and Google's Translation API.

11. "Explain what a server is and how to deploy code on one."

A server is a computer (or a program on it) that waits for requests and sends responses: a web server (Apache, Nginx) serves pages, an application server runs your code (PHP-FPM, Gunicorn, Node), and a database server stores data. Deploying means getting your tested code onto that machine and making it live. A sound answer describes a repeatable process: code in Git, a build step (install dependencies, compile assets), configuration through environment variables, a database migration, restarting or reloading the app, a check that it works, and a way to roll back. Compare manual FTP uploads with Git-based or CI/CD deployment, and see deploying from Git to shared hosting for a worked example.

12. "What is the difference between a database and a file? Why SQL?"

A database gives you structured storage with querying, indexing, constraints, transactions and concurrent access. A plain file offers none of that safely. Be ready for follow-ups on joins, indexes, transactions and normalisation; the top 20 SQL topics lists what senior interviews expect.

13. "What is version control and how do you use Git?"

Version control records every change to your code so you can see history, work in parallel on branches, merge, and go back. Know clone, add, commit, push, pull, branch, merge, rebase (and when not to), how to resolve a merge conflict, what a pull request is, and revert versus reset. A short, honest description of your team workflow (feature branches, code review, protected main) earns credit.

14. "How do you debug a problem?"

A repeatable method impresses more than any single trick: reproduce it, read the error message and stack trace (the last lines first), narrow the cause (binary search through the code, print or log values, use a debugger), form a hypothesis and test it, fix the root cause, add a test so it cannot return, and note what you learned. Mention tools you use: browser dev tools, log files, a debugger, EXPLAIN for slow queries.

Part 3: matching depth to your level

Level	What interviewers want to hear
Fresher	clear basics, small projects you can explain fully, willingness to learn, and good habits (Git, tests, reading error messages)
2 to 4 years	ownership of features, comfort with one framework and a database, debugging skill, understanding of why you used a design
5+ years	design judgement and trade-offs, performance and security awareness, mentoring and code review, handling ambiguity, and stories with measurable results

For experienced candidates, a story in the "situation, action, result" form beats any definition. "A report page took 12 seconds. I profiled it, found 400 queries from an N+1 pattern, replaced them with one join and an index, and it dropped to 300 ms" tells the interviewer more than three correct definitions.

Practical tips for the day

1. Research the company and the job description. Match two or three of your skills to its needs.
2. Prepare 3 stories (a hard bug, a disagreement or failure, a thing you are proud of) using situation, action, result.
3. Think aloud on technical questions. Interviewers evaluate your reasoning, and a half-finished idea shared clearly often beats silence.
4. Ask for clarification before answering ambiguous questions.
5. It is fine to say "I don't know." Follow it with how you would find out. Bluffing is penalised more than a gap.
6. Ask questions at the end: about the team, the code review process, how success is measured. It shows you are choosing too.
7. Practise out loud with a friend or a recording, and run through the code you will be asked to write by typing it, not just reading it.
8. Follow up with a short thank-you message.

Where to practise next

Build the habit of verifying answers by running code. The free Python, PHP and MySQL courses on this site include exercises, and the interview collections for MySQL, Python and PHP freshers let you check yourself. If you are getting ready for a certificate exam first, read how to prepare for a programming exam and how to add your certificate to LinkedIn and your CV.