IT interview questions and answers

Structure: role and context, daily work, scale, impact, then the link to the new role.

Sample answer: "I am a [title] with [X] years of experience. I work at [company type], where I look after [environment, for example a multi-account AWS setup running Kubernetes]. My typical day covers three things. First, keeping systems healthy: I check dashboards and alerts, and handle incidents and tickets. Second, delivery: I maintain CI/CD pipelines, review Terraform changes, and support releases. Third, improvement work: cost savings, security fixes, and automation to remove manual steps. Recently I [achievement with a number, for example cut deployment time from 40 to 10 minutes]. I also [mentor juniors or write runbooks]. I want to take on [bigger scope the new role offers]."

Tips:

• Mention real tools (Terraform, Kubernetes, GitHub Actions, CloudWatch or Prometheus) and the scale (services, environments, traffic).
• Show ownership and results, not only tasks.
• Mention networking, DNS, certificates or monitoring only if the job needs them.

What they are checking: Whether your real responsibilities, scale and impact match the level you claim.

RUN executes a command at build time and bakes the result into an image layer. CMD sets the default command when a container starts, and can be overridden on the docker run line. ENTRYPOINT sets the fixed program of the container. Anything you pass after the image name is added to it as arguments.

• Use RUN for installing packages and building code.
• Use CMD for default arguments or a default command.
• Use ENTRYPOINT with CMD when the image behaves like a command: ENTRYPOINT is the program, CMD holds default arguments.
• Prefer the exec (JSON array) form so signals reach your process.

RUN pip install -r requirements.txt
ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8000"]

docker run img --port 9000 replaces only CMD, so the container runs python app.py --port 9000.

What they are checking: Whether you understand build time versus run time and how overriding works.

On a directory, execute (x) means you can traverse it: cd into it and access items inside by name. Read (r) means you can list its names.

• r only (e.g. chmod 400 dir): ls dir shows names. But you cannot cd into it, read file details, or open files inside.
• x only: you can cd and open a file if you know its exact name, but cannot list.
• r + x: the normal read-only access (r-x): list and enter.
• w + x: needed to create, delete or rename files in it.

So to cd into a folder you need x on it and on every parent directory. Read permission alone is not enough to enter or properly list contents.

What they are checking: Whether you understand that directory permissions differ from file permissions

For most teams I choose Terraform, but the right answer depends on context.

Terraform strengths:

• Multi-cloud and many providers (Kubernetes, Cloudflare, Datadog, GitHub), one workflow.
• Easy-to-read HCL, many ready-made modules, and plan shows the exact changes.
• State gives you flexibility (import, move, run on one resource).
• Loops and expressions are more powerful (for_each, dynamic).

CloudFormation strengths:

• Made by AWS, with no state file to manage (AWS keeps it). It has automatic rollback on failure, drift detection (finding manual changes), and StackSets for many accounts.
• New AWS features often arrive first, and it works closely with Service Catalog and SAM.

Downsides: with Terraform you must secure and lock the state yourself. With CloudFormation you are limited to AWS, and templates can be long.

My choice: Terraform for multi-cloud or platform work. CloudFormation or CDK when the company uses only AWS and wants built-in rollback and control.

What they are checking: Whether you can compare tools by their good and bad points, not just name a favorite.

I start with top or htop for live CPU and memory, then use targeted commands.

top                      # live CPU/memory per process (press M or P to sort)
ps aux --sort=-%cpu | head    # top CPU consumers
free -h                  # memory and swap
df -h                    # disk usage per filesystem
du -sh /var/log/*        # folder sizes
uptime                   # load average
kill <PID>               # polite stop (SIGTERM)
kill -9 <PID>            # force kill (SIGKILL), last resort

Find a process by name with pgrep -a nginx or ps aux | grep nginx. Check logs with journalctl -u <service>. For storage problems, df -h shows which filesystem is full and du pinpoints the folder.

What they are checking: Whether you have day-to-day Linux troubleshooting habits

A list is mutable and a tuple is immutable. That is the core difference, and everything else follows from it.

• Tuples are slightly smaller and faster to create, and they signal "this does not change".
• A tuple containing a list is still not fully frozen: t = (1, [2]) allows t[1].append(3).
• A single-item tuple needs a comma: (5,).

What they are checking: Whether you know mutability matters (hashing, dict keys), not just the bracket style

A mutable object can be changed in place after creation, an immutable one cannot. Changing an immutable value really creates a new object.

• Immutable: int, float, bool, str, tuple, frozenset, bytes.
• Mutable: list, dict, set, bytearray, and most user-defined class instances.

s = "abc"
print(id(s))
s += "d"          # new string object, id changes
print(id(s))

l = [1, 2]
print(id(l))
l.append(3)       # same object, id unchanged
print(id(l))

Why it matters: Mutable objects can be changed by anyone who holds them. This causes hard-to-find bugs (for example mutable default arguments). Immutable objects are safe to share and can be dict keys.

What they are checking: Understanding of object identity, and what it means for function arguments and hashing

== compares values (it calls __eq__). is compares identity: do both names point to the same object in memory?

a = [1, 2]
b = [1, 2]
print(a == b)   # True, equal values
print(a is b)   # False, two different objects
c = a
print(c is a)   # True

• Use == for value comparison almost always.
• Use is for singletons: x is None, x is True.
• Do not use is for numbers or strings. CPython keeps small integers (-5 to 256) and some strings in a cache. So is may seem to work, then fail on larger values.

What they are checking: Whether you avoid the small-integer cache trap and know to use is None

They let a function accept a variable number of arguments. *args collects extra positional arguments into a tuple, and **kwargs collects extra keyword arguments into a dict. The names are convention, the stars are the syntax.

def show(a, *args, **kwargs):
    print(a, args, kwargs)

show(1, 2, 3, x=10, y=20)   # 1 (2, 3) {'x': 10, 'y': 20}

nums = [1, 2, 3]
opts = {"sep": "-"}
print(*nums, **opts)          # unpacking at the call site: 1-2-3

Order in a signature: positional parameters, *args, keyword-only parameters, **kwargs. They are common in decorators and wrappers that must forward any arguments to the wrapped function.

What they are checking: Can you use packing and unpacking, and do you know the parameter order

A decorator is a callable that takes a function and returns a new function. It usually adds work before or after the original call. @decorator above a function is shorthand for func = decorator(func).

import functools, time

def timed(fn):
    @functools.wraps(fn)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        try:
            return fn(*args, **kwargs)
        finally:
            print(f"{fn.__name__} took {time.perf_counter() - start:.4f}s")
    return wrapper

@timed
def work(n):
    return sum(range(n))

work(1_000_000)

Points to mention: closures keep a reference to fn. functools.wraps preserves the name and docstring. Decorators are applied at definition time. Typical uses are logging, timing, caching, auth checks and retries.

What they are checking: Closures, first-class functions and whether you remember functools.wraps

Severity is how badly a defect hurts the system (technical impact). Priority is how soon it must be fixed (business urgency). Testers usually set severity. The product owner or manager sets priority.

A misspelled logo or brand name is the classic low severity, high priority case. Nothing breaks, but the business wants it fixed right away.

What they are checking: Can you explain technical impact and business urgency with examples

A defect moves through states from discovery to closure:

1. New: the tester logs the bug.
2. Assigned / Open: the lead or triager accepts it and gives it to a developer.
3. In progress: the developer works on a fix.
4. Fixed: the code change is done and merged.
5. Ready for retest: the fix is deployed to the test environment.
6. Retest: the tester checks the fix. If it passes, the bug becomes Verified and then Closed. If not, it is Reopened and goes back to the developer.

Side paths: Rejected / Not a bug, Duplicate, Deferred (fix moved to a later release), Cannot reproduce / Need info. Names differ per tool (Jira workflows can be changed), but the idea is the same.

What they are checking: Do you know the full flow, including the reopen, duplicate and deferred paths

SDLC (Software Development Life Cycle) covers the whole product journey: requirements, design, development, testing, deployment, maintenance. STLC (Software Testing Life Cycle) is the testing-only sequence inside it:

1. Requirement analysis
2. Test planning
3. Test case design and test data preparation
4. Test environment setup
5. Test execution and defect reporting
6. Test closure (reports, lessons learned)

QA is not only a phase after development. In a good process, QA reviews requirements early (called shift left). QA plans while design happens and tests during development. QA also supports the release and production monitoring.

What they are checking: Do you see QA as a continuous activity and not a final gate

Retesting confirms one known defect. Regression looks for unknown side effects.

What they are checking: Can you tell these four apart without mixing them up

Equivalence partitioning (ECP) splits inputs into groups that the system should treat the same. Then you test one value per group. Boundary value analysis (BVA) tests at the edges of those groups, where bugs are common.

Example: an age field accepts 18 to 60.

• Partitions: below 18 (invalid), 18 to 60 (valid), above 60 (invalid). ECP tests values like 10, 35, 70.
• BVA tests 17, 18, 19 and 59, 60, 61.

Together they give good coverage with few cases. You need 6 boundary tests plus one per partition, instead of 40+ values. Also add non-numeric, empty and negative inputs as separate invalid groups.

What they are checking: Can you pick real values and explain why the test count is smaller

All three functions number the rows inside a window. They differ only in how they treat ties.

• ROW_NUMBER() gives a unique sequence (1,2,3,4). It breaks ties in any order.
• RANK() gives tied rows the same number, then skips numbers (1,2,2,4).
• DENSE_RANK() gives tied rows the same number with no gaps (1,2,2,3).

SELECT name, salary,
       ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn,
       RANK()       OVER (ORDER BY salary DESC) AS rnk,
       DENSE_RANK() OVER (ORDER BY salary DESC) AS drnk
FROM employees;

Use ROW_NUMBER to remove duplicates. Use DENSE_RANK for "Nth highest" questions. Use RANK when the gaps after ties matter.

What they are checking: Do you know how each function treats ties, and can you pick the right one?

The safest way is DENSE_RANK. It handles ties and works for any Nth value.

SELECT DISTINCT salary
FROM (
  SELECT salary, DENSE_RANK() OVER (ORDER BY salary DESC) AS r
  FROM employees
) t
WHERE r = 2;

Other ways to do it:

-- Offset approach
SELECT DISTINCT salary FROM employees ORDER BY salary DESC OFFSET 1 LIMIT 1;

-- Subquery approach
SELECT MAX(salary) FROM employees WHERE salary < (SELECT MAX(salary) FROM employees);

Note one difference. The window version returns no row (not NULL) when there is no second value. The MAX version returns NULL. Say which result the caller wants.

What they are checking: Can you handle ties, and do you know more than one way?

GROUP BY collapses rows into one row per group. A window function calculates a value across related rows but keeps every input row.

-- One row per department
SELECT dept, AVG(salary) FROM employees GROUP BY dept;

-- Every employee row, plus the department average beside it
SELECT name, dept, salary,
       AVG(salary) OVER (PARTITION BY dept) AS dept_avg
FROM employees;

• PARTITION BY sets the group. ORDER BY sets the order inside the group. A frame (ROWS BETWEEN ...) sets which rows are used.
• Window functions run after WHERE, GROUP BY and HAVING. So you cannot filter on them in WHERE. Put the query in a CTE or subquery instead.

What they are checking: Do you know that a window keeps rows and GROUP BY collapses them, and do you know the run order?

Number the duplicates with ROW_NUMBER over the columns that make a row a duplicate. Then delete every row after the first.

DELETE FROM customers
WHERE ctid IN (
  SELECT ctid FROM (
    SELECT ctid,
           ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at) AS rn
    FROM customers
  ) t
  WHERE rn > 1
);

ctid is the physical row id in PostgreSQL. It works even when the table has no primary key. In other databases, use the primary key or another unique id.

For a very large table, copying is often faster. Build a clean copy with SELECT DISTINCT ON (email) ... or the ROW_NUMBER filter, then swap it in. After that, add a unique constraint so the problem cannot come back.

What they are checking: Can you remove duplicates safely and stop them coming back?

Group by the columns that define a duplicate. Keep only the groups with more than one row.

SELECT email, COUNT(*) AS cnt
FROM customers
GROUP BY email
HAVING COUNT(*) > 1;

To see the full duplicate rows, join back or use a window count:

SELECT *
FROM (
  SELECT c.*, COUNT(*) OVER (PARTITION BY email) AS n
  FROM customers c
) t
WHERE n > 1;

Be clear about what a duplicate means. It could be the same email, or the same email and name. Also think about NULLs. For a unique constraint, NULLs are not equal to each other. But GROUP BY puts all NULLs in one group.

What they are checking: Can you find duplicates and say exactly what a duplicate is?

Supervised learning trains on labeled data. Each input has a known target. The model learns to predict the target for new inputs. Unsupervised learning uses data with no labels. It finds patterns by itself.

• Supervised: classification (spam or not spam) and regression (house price). Algorithms: linear and logistic regression, decision trees, SVM, neural networks.
• Unsupervised: clustering (customer groups), dimensionality reduction (PCA), and anomaly detection. Algorithms: k-means, DBSCAN, PCA.
• Semi-supervised and self-supervised sit in between. Semi-supervised uses a small labeled set plus lots of unlabeled data. Self-supervised makes labels from the data itself. This is how language models are pretrained.

The real difference is the cost of labels and how you check results. Supervised models have a clear score against the true answers. Unsupervised results need domain judgement or indirect (proxy) metrics.

What they are checking: Clear definitions with one example of each. Also that labels drive cost and how you evaluate.

Bias is error from assumptions that are too simple. It causes underfitting. Variance is error from being too sensitive to the training data. It causes overfitting. Expected test error is roughly bias squared plus variance plus irreducible noise.

• High bias: the model is too simple. Error is high on both train and test data (a straight line on curved data).
• High variance: the model memorizes noise. Train error is low but test error is much higher (a deep tree with no pruning).
• Tradeoff: a more complex model lowers bias but raises variance. You look for the complexity where total error is lowest.

Ways to fix it: more data and regularization reduce variance. More features or a richer model reduce bias. Ensembles also help: bagging cuts variance and boosting cuts bias.

What they are checking: Whether you can link the idea to checking a model by its train and test error.

Overfitting is when a model learns the noise and odd details of the training set. It scores well on training data but poorly on new data.

Detect it with the gap between train and validation scores. A learning curve helps too. Validation error goes up while training error keeps going down.

Prevent it with:

• More (or more varied) training data, and data augmentation
• A simpler model, pruned trees, or fewer features
• Regularization (L1, L2, dropout, weight decay)
• Early stopping on a validation metric
• Cross validation for honest model selection
• Ensembling such as bagging

Fix the cause first. If there is data leakage or a tiny dataset, tuning hyperparameters will not help.

What they are checking: A way to find the problem first, then several fixes that match it. Not a memorized list.

Both add a penalty on the size of the weights to the loss. This discourages complex models.

Elastic Net mixes both. The penalty strength is a hyperparameter. It is alpha in scikit-learn. In logistic regression, C is its inverse. Scale the features first, because the penalty depends on the size of the weights.

What they are checking: Whether you know why L1 gives sparse results (the geometry) and why you must scale features.

Each set has its own job. This keeps the performance estimate honest.

• Training set: fit the model parameters.
• Validation set: choose hyperparameters and compare models. You look at it many times, so its score becomes a little too optimistic.
• Test set: use it once at the end. It tells you the expected real-world performance.

Common splits are 70/15/15 or 80/10/10. With small data, use cross validation instead of a fixed validation set. Keep the time order for time series. Stratify for imbalanced classes. Split by group (user, patient) when rows from one entity are related. Otherwise leakage makes the scores too high.

What they are checking: Understanding of leakage and why the test set must stay untouched.

A business analyst (BA) connects the business and the technical team. They understand a business problem. They turn it into clear requirements that can be tested. They make sure the final solution really solves the problem.

Typical work:

• Ask stakeholders what they need, through interviews, workshops, and watching the work.
• Analyse and write down requirements (user stories, use cases, process models).
• Find gaps, risks, and conflicts early, and suggest options with trade-offs.
• Help developers and testers with questions, and help run UAT (user acceptance testing).
• Track changes and keep every requirement linked to a business goal.

A BA owns the quality of the analysis. The value is not in taking notes. The value is in asking why, questioning assumptions, and recommending a solution.

What they are checking: Do you see the role as analysis and advice, not just writing documents?

They record requirements at different levels, for different readers.

In practice, a BRD explains why the project is needed. An FRD describes what the solution does. An SRS is the detailed agreement that developers build from and testers check against. Many agile teams replace all three with a backlog of user stories and a short vision document.

What they are checking: Can you place each document in the right level of requirements?

Elicitation means drawing requirements out of stakeholders. Common techniques:

• Interviews: one to one. Good for depth and sensitive topics.
• Workshops (JAD sessions): group sessions that align many stakeholders quickly.
• Observation (job shadowing): watch the real work to find steps that people forget to mention.
• Document analysis: read existing manuals, reports, and policies.
• Surveys and questionnaires: reach many people at low cost.
• Prototypes and wireframes: let users react to something they can see.
• Brainstorming and focus groups: collect ideas.
• Reverse engineering of an old system.

Use a mix. Interviews plus observation usually show the gap between what people say and what they do.

What they are checking: Do you know many techniques, and can you match them to situations?

A user story is a short description of a need from the user's point of view: "As a <role>, I want <goal>, so that <benefit>."

A good story follows INVEST:

• Independent: can be built without depending on another story.
• Negotiable: details are discussed, not fixed.
• Valuable: gives value to a user or the business.
• Estimable: the team can size it.
• Small: fits within a sprint.
• Testable: has clear acceptance criteria.

Example story: "As a patient, I want to reschedule an appointment online, so that I do not need to call the clinic". The story starts a conversation. It is not a full specification.

What they are checking: Do you know INVEST and the "so that" part?

Acceptance criteria are the specific conditions a story must meet to be accepted. You can test each one. They remove doubt about what "done" means.

They are often written in Given/When/Then form:

• Given a registered user is on the login page
• When they enter a valid email and password
• Then they land on the dashboard

Add negative cases and edge cases too. A wrong password shows an error and does not say which field was wrong. After five failed attempts the account locks for 15 minutes.

Good criteria are pass or fail. They cover the normal path, errors, and limits. You can turn them directly into test cases.

What they are checking: Can you test your criteria, and do they include negative cases?

I follow the same steps every time, so I do not guess:

1. Define the problem. Ask what is wrong, when it started, what changed, who is affected, and what error message appears.
2. Reproduce it if possible. Check the scope: one user, one machine, or everyone.
3. Make a guess (hypothesis). Start with the simplest and most likely causes, such as the cable, power, a restart, or a recent change.
4. Test one change at a time. Write down the result.
5. Fix it and check with the user.
6. Document the cause and the fix in the ticket for next time.

If I cannot fix it within the SLA (the agreed time limit) or my permission level, I escalate. I pass on everything I tried, so the next person does not repeat the steps.

What they are checking: Clear, step-by-step thinking instead of random trial and error

First I ask when it became slow, whether it is everything or one app, and what changed. Then I check:

• Task Manager: CPU, memory, disk, and startup use. Find the process that uses the most.
• Disk space. Low free space slows Windows. A disk at 100% on an old HDD points to a hardware problem.
• Startup programs and background apps. Remove or turn off the ones that are not needed.
• A malware scan with the approved antivirus.
• Waiting Windows updates and driver updates. Restart if the PC has been on for weeks.
• Heat and dust or fans, if the laptop is hot.
• The network, if only web or cloud apps are slow.

If RAM is always full, or the drive is a failing HDD, I suggest an upgrade (more RAM or an SSD).

What they are checking: A practical checklist for finding the cause

I start at the bottom of the network layers and go up:

1. Physical: the cable is plugged in, Wi-Fi is on, airplane mode is off, and the link lights are on.
2. Is it only this device? Try another device on the same network.
3. ipconfig /all: does the device have a valid IP, subnet, gateway, and DNS? An address like 169.254.x.x means DHCP failed.
4. ping the default gateway. Then ping an outside IP such as 8.8.8.8. Then ping a domain name.
5. If the IP works but the name does not, it is a DNS problem. Use nslookup and ipconfig /flushdns.
6. Check proxy or VPN settings, the firewall, and problems that affect only the browser.
7. Restart the router or switch. If many users are affected, escalate to the network team.

What they are checking: Troubleshooting the network layer by layer

DHCP (Dynamic Host Configuration Protocol) gives devices an IP address, subnet mask, default gateway, and DNS servers automatically. Nobody has to set up each machine by hand.

The steps are called DORA:

1. Discover: the client sends a broadcast to find a server.
2. Offer: a DHCP server offers an address.
3. Request: the client asks for the offered address.
4. Acknowledge: the server confirms. The client gets a lease (the right to use the address) for a set time.

Addresses are leased and renewed. A reservation ties an address to a device's MAC address. This is useful for printers.

What they are checking: Basic networking knowledge

DNS changes domain names into IP addresses. When you type a URL, this happens:

1. The browser and the OS check their caches.
2. If the answer is not there, the request goes to the DNS resolver you set up.
3. The resolver asks the root, TLD (.com), and authoritative name servers if needed. It returns the IP.
4. The browser opens a TCP connection to that IP (with TLS for HTTPS).
5. It sends the HTTP request and shows the response.

Common records: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT (verification, SPF). Test with nslookup example.com.

What they are checking: Do you understand how a name becomes an IP address?

A project moves through five process groups: initiating, planning, executing, monitoring and controlling, and closing.

• Initiating: define the business need, write the project charter, find the stakeholders, and get approval to start.
• Planning: define the scope and the WBS, estimate effort and cost, build the schedule, and plan risks, communication, quality and people.
• Executing: build the team, do the work, manage what stakeholders expect, and hold regular meetings.
• Monitoring and controlling: compare progress with the baseline, manage risks and changes, report status, and fix problems.
• Closing: get acceptance, hand over to operations, release the team, write down lessons learned, and archive records.

In software projects these groups overlap. In agile, the cycle repeats every sprint or release.

What they are checking: Do you know a clear project lifecycle, and can you explain what happens in each phase?

A project charter is a short document that formally approves the project. It gives the project manager the right to use resources. The sponsor usually issues it.

Typical contents:

• Project purpose and business case
• Goals and measurable success criteria
• High-level scope and main deliverables
• Major milestones and a rough timeline
• Summary budget
• Key stakeholders, sponsor and project manager
• High-level risks, assumptions and constraints
• Approval signatures

It is short (one to three pages) and stays stable. The project plan is detailed and changes often. Without a charter, the team has no agreed reason for the project.

What they are checking: Can you tell the difference between approval of a project and detailed planning?

The charter approves the project at a high level. The plan describes how the work will be done.

The plan is a set of smaller plans: scope, schedule, cost, quality, resource, communication, risk and procurement. It also has baselines for scope, schedule and cost.

What they are checking: Do you know both documents and why each one exists?

Scope management defines what is in and out of the project. It makes sure only that work gets done.

• Collect requirements and write a clear scope statement with exclusions.
• Break the scope into a work breakdown structure (WBS).
• Get written sign-off on the scope baseline.
• Send every new request through change control. Log it, check the effect on time, cost and quality, and get approval from the sponsor or change board.
• Check deliverables with the customer at acceptance points.

To control scope, compare the actual work with the baseline. Say "yes, with this impact" or "not now". Never quietly accept extra work.

What they are checking: Do you protect scope with a process instead of random yeses?

A WBS breaks the total scope into smaller, easy-to-manage deliverables. It shows what must be produced, not when or by whom.

• Level 1 is the project. Level 2 is the major deliverables or phases. Lower levels break these into work packages.
• Work packages are small enough to estimate, assign and track (often 8 to 80 hours of effort).
• The 100 percent rule: the WBS includes all the work in scope and nothing outside it.
• A WBS dictionary describes each element.

Example for a website: Design, Development (frontend, backend, database), Testing, Deployment, Training. The WBS is used for estimates, schedules and the budget.

What they are checking: Can you break down scope, and do you know why a WBS is used?

Give a story of 60 to 90 seconds in three parts: who you are, what you have built, and why you want this role.

Sample answer: "I am [your name]. I recently finished my [degree] at [your college]. During my degree I became interested in [web development / data / testing]. I built projects such as [project name], a [one-line description] using [technologies]. It taught me [skill]. I also did an internship at [company], where I [contribution]. I am comfortable with [two or three skills] and I learn quickly. Now I want a [role] position where I can use these skills in a real team and grow. That is why this opening at [company] interests me."

Keep it professional. Skip family and hobbies unless they matter for the job. End by linking your story to the role.

What they are checking: Can you give a clear, relevant summary in under two minutes?

Use present, past, future: your current role, your main achievements, and why you want this next step.

Sample answer: "I am a [role] with [number] years of experience in [domain]. Right now at [company], I lead/own [area]. There I [achievement with a number, for example cut release time by 40 percent]. Before that I worked on [previous experience], which gave me depth in [skills]. I enjoy [what motivates you: solving production problems, mentoring, building systems that scale]. Now I want a role with bigger [scope / ownership / technical challenges]. Your team's work on [area] fits that well."

Stay at about two minutes. Use numbers for your results. Do not read your CV line by line.

What they are checking: Can you tell a focused career story that shows impact?

Match your strengths to what the job needs, and show proof.

Sample answer: "You need someone who can [key requirement from the job description]. I have the base for it. I know [skills], and I showed them in [project/internship], where I [result]. I learn quickly and take feedback well. I do my work to a high standard. I will bring energy and ownership to the team, and with some guidance I will become productive fast."

If you have experience, replace the base with proven results: "In my last role I delivered [result]. This is similar to what this role needs." Do not criticize other candidates.

What they are checking: Can you connect your skills to what the employer needs?

Choose two or three strengths that matter for the job. Give one example for each.

Sample answer: "My main strengths are problem solving and quick learning. In my final-year project I had to add a payment API that I had never used. I read the documentation, built a small prototype, and finished on time. I am also a good team player. I communicate clearly and ask for help early. And I am careful about deadlines."

Pick real strengths, such as technical skills, learning speed, communication, ownership, or debugging. Do not make general claims without proof. Do not list more than three.

What they are checking: Do you know yourself, and can you back your claims with proof?

Name a real weakness that is not critical for the job. Show that you are working on it, and share your progress.

Sample answer: "I used to hesitate to ask for help. I spent too long stuck on a problem. I saw that this delayed one of my projects. Now I set a time limit. If I am stuck for 30 minutes after trying the documentation and a search, I ask a teammate. This has made me faster."

Other honest examples: public speaking (you joined presentations), polishing work too much (you set time limits), or giving work to others (for experienced people). Avoid fake weaknesses such as "I work too hard". Also avoid a weakness that the job really needs you to be good at.

What they are checking: Do you know your own limits, and do you want to improve?