10 Technical Interview Questions for IT Professionals

You've got the interview on your calendar, a job description full of tools you partly know, and a browser history full of scattered definitions. That's normal. Strong technical interviews rarely test whether you can recite a textbook. They reveal how you reason, communicate tradeoffs, diagnose failures, and turn vague requirements into a working solution.

Start by clarifying what the role needs. A help desk, backend, data, and site reliability role will weight these Technical Interview Questions for IT very differently, even when the wording sounds similar. Use the ten questions below to find gaps across operating systems, programming, data, networking, security, and infrastructure, then practice the weak spots out loud.

That structure matters for the interviewer too. The U.S. Office of Personnel Management defines a structured interview as one that uses consistent rules for eliciting, observing, and evaluating responses, and greater structure is associated with higher validity and stronger rater reliability in the meta-analytic research on interview structure. In practical terms, you're likely to face comparable prompts scored against predefined criteria, not a free-form chat.

So prepare repeatable answer frameworks, not memorized paragraphs. State your assumptions, explain your reasoning, name the tradeoff, and say how you'd test it. For structured practice, Interview Pilot offers guided mock interviews, role-specific question banks, and real-time answer suggestions for technical and non-technical interviews across more than 99 languages.

1. What Is the Difference Between a Process and a Thread

A process is an independent instance of a running program with its own memory space, file handles, and system resources. A thread is a unit of execution inside that process, and threads in the same process share memory and resources. That one distinction drives most of the follow-up questions on isolation, speed, and risk.

Processes give you isolation. If one crashes, it usually doesn't corrupt another process's memory, which is why Chrome has historically run tabs in separate processes. Threads give you cheaper concurrency, which is why Java and C# servers commonly use thread pools for concurrent requests. The cost is shared state, and shared state is where race conditions live.

How to Structure the Answer

Open with the definitions, compare memory and failure isolation, then give a concrete case. Apache with the prefork MPM leans on multiple processes, while Nginx uses an event-driven worker model. If the team works in Python, mention the Global Interpreter Lock, because it limits thread-based CPU parallelism even though threads still help with I/O.

• Isolation: Processes fail separately, threads can corrupt shared data.
• Cost: Creating a process is heavier than creating a thread.
• Control: A mutex or lock prevents two threads updating shared state at once.

Expect a follow-up asking you to walk through a race condition. Describe the interleaved updates, the wrong result, and where the lock belongs. For deeper rehearsal, work through these operating system interview questions and answers and answer each one in the same definition, comparison, example shape.

2. Explain Big O Notation and Analyze the Time and Space Complexity of an Algorithm

Interviewers aren't asking for a math lecture. They want to hear you predict how your code behaves when input grows, then improve it. Big O notation describes that growth as an upper bound, ignoring constant factors, for time and for extra memory.

Start from a brute-force answer and optimize out loud. Detecting duplicates with nested loops is O(n²), while a hash set brings it to O(n) time at the cost of O(n) space. Two Sum with a hash map follows the same trade, and reversing a linked list in place is O(n) time with O(1) extra space.

This category still dominates screening. Programming and algorithms appeared in 65% of technical assessments in SHL's analysis of 1.9 million coding-simulation responses. That doesn't mean puzzles are the whole job. It means you need to explain correctness, edge cases, and complexity clearly under time pressure.

What Gets You Follow-Up Credit

Binary search is O(log n) because each step halves the search space. Merge sort guarantees O(n log n) time and uses O(n) extra space. A hash map lookup is O(1) on average, but that assumption weakens when many keys collide.

Talk before you code, state complexity after you code, then test edge cases. Timed practice helps more than silent reading, and these software engineer technical interview questions and answers work well as a timed set.

3. Write a SQL Query to Find the Second-Highest Salary and Explain JOIN Types

Clarify before you type. Ask whether duplicate salaries count as one distinct value or as separate rows, because the correct query changes with the answer. That question alone signals practical experience, since real salary, sales, and transaction tables are full of duplicates.

One approach uses a subquery that finds the maximum salary below the overall maximum. A cleaner modern approach uses a window function such as DENSE_RANK, orders salaries descending, and selects rank two. Explain the tradeoff plainly. The subquery is portable and easy to read for a single value, while the window function extends naturally to ranking within each department.

Practical rule: State your assumption about duplicates before you write the query, then say how the query changes if the interviewer wants the other interpretation.

Joins are the usual follow-up. An INNER JOIN returns matching rows only, a LEFT JOIN keeps every row from the left table and fills gaps with NULLs, and RIGHT and FULL OUTER joins extend that idea in the other directions. A CROSS JOIN pairs every row with every row, which is rarely what you want by accident.

Ground each type in work. Analysts use a LEFT JOIN to find customers who've never placed an order. Data engineers rank products by sales within category with window functions, and finance teams pair GROUP BY with HAVING to filter aggregated totals. Practice both solutions in SQLite or PostgreSQL until you can explain duplicate rows and NULLs without pausing.

4. Explain ACID Properties and How Database Indexes Improve Performance

Use a bank transfer and this question gets easy. Money leaves one account and arrives in another, or neither change happens. That is Atomicity. Consistency means the transaction moves the database from one valid state to another, Isolation keeps concurrent transactions from interfering unpredictably, and Durability means a committed change survives a crash.

PostgreSQL and MySQL InnoDB are widely used ACID-compliant engines, and interviewers listen for whether you connect the guarantees to a failure. What happens if the server dies after the debit but before the credit? A strong answer names the transaction boundary and explains rollback in plain language.

Where Indexes Help and Where They Hurt

A B-tree index keeps keys sorted so the database can find matching rows without scanning the whole table. E-commerce platforms index order IDs and customer emails because account and order lookups happen constantly. Reads get faster, but every insert and update also has to maintain the index, and the index consumes storage.

• Good candidates: Columns used in frequent lookups, joins, and sorting.
• Weak candidates: Low-cardinality columns where most rows share a few values.
• Heavy write workloads: Extra indexes can slow writes more than they help reads.

Be ready to compare a clustered index, which determines the physical order of rows, with a non-clustered index, which is a separate lookup structure pointing to rows. Don't claim indexes always help. Interviewers score the caveat as highly as the definition.

5. What Is the Difference Between REST and GraphQL and What Does Idempotent Mean

REST organizes resources around URLs and uses HTTP methods such as GET, POST, PUT, PATCH, and DELETE. It's predictable, cache-friendly, and easy to reason about for straightforward resources. GraphQL exposes a single endpoint where the client requests exactly the fields it needs, which helps when different screens need very different shapes of the same data.

Neither wins everywhere. REST can over-fetch or force several round trips for a complex screen. GraphQL can complicate caching, authorization, and query cost control. GitHub offering both a REST API and a GraphQL API is a useful example because it shows the choice depends on client needs, not fashion.

Idempotency is where this becomes operational. An idempotent operation can be repeated without changing server state beyond the first successful result. GET, PUT, and DELETE are designed that way, while POST usually isn't.

Stripe makes the risk concrete. If a payment request times out, the client doesn't know whether the charge succeeded, so a blind retry could charge the customer twice. An idempotency key lets the server recognize the retry and return the original result instead of creating a duplicate charge.

Know PUT versus PATCH cold. PUT replaces the resource with the supplied representation, while PATCH applies a partial change. Interviewers often use that distinction to test whether you have designed APIs or only consumed them.

6. What Happens When You Type a URL Into a Browser and Press Enter

Treat this as a map, not a memory test. Give the stages in order first, then invite the interviewer to pick where to go deeper. That keeps you from drowning in detail on DNS while never reaching rendering.

The browser checks its cache, then resolves the hostname through DNS, often with help from the operating system and a resolver cache. It opens a TCP connection, negotiates TLS for HTTPS, and sends an HTTP request. A CDN or load balancer may handle the request before it reaches the application server, which queries data, builds a response, and sends it back.

The short video below works well for tracing that sequence before you practice it aloud.

Then the browser parses HTML, requests CSS, JavaScript, fonts, and images, builds the page, and renders it. Cloudflare and Akamai cache static assets at edge locations to cut latency, and streaming services such as Netflix and YouTube rely on CDNs and modern HTTP versions for delivery. Those examples show you understand why the layers exist.

Mention caching at each layer, including browser, DNS resolver, and CDN. Open your browser's Network panel and trace a real page load before the interview. Naming what you'd inspect when a page is slow turns a recitation into a debugging story.

7. Explain the Difference Between TCP and UDP and When to Use Each

Anchor this in a choice. Would you rather receive every byte in order, or receive data fast enough that a late packet is useless? TCP chooses ordered, reliable, connection-oriented delivery with flow and congestion control. UDP chooses low overhead and no delivery guarantee.

Web traffic over HTTP/1.1 and HTTP/2 runs on TCP because a page or API response with missing bytes is broken. Video calls and online games commonly favor UDP because retransmitting an old frame or position update wastes time. DNS queries typically use UDP for speed and fall back to TCP for large responses.

Details That Strengthen the Answer

Explain the three-way handshake if asked. The client sends SYN, the server replies with SYN-ACK, and the client confirms with ACK before data flows. That setup, plus acknowledgments and retransmission, is the cost of TCP's reliability.

Mention QUIC to show current awareness. HTTP/3 runs over QUIC on UDP, rebuilding reliability and encryption above UDP to reduce connection setup delays. Don't present UDP as unreliable in a careless sense. Present it as a deliberate trade where the application decides what loss it can tolerate.

The diagram below revisits the URL request flow from the previous question, which helps you place transport choices inside the full request path.

8. Explain the Difference Between Authentication and Authorization and How OAuth 2.0 and JWT Fit In

A hotel key card makes this distinction stick. Checking in and proving who you are is authentication. Which floors and rooms that card opens is authorization. Mixing those two up is the most common avoidable mistake on this question.

OAuth 2.0 is an authorization framework that lets an application access resources on behalf of a user without taking the user's password. OpenID Connect builds identity on top of it, which is how a sign in with Google flow both identifies the user and grants scoped access. A JWT is a compact, signed token format often used to carry claims such as user ID, roles, and expiry.

Authentication answers who you are. Authorization answers what you're allowed to do. A valid token doesn't grant unlimited permission.

Role-based access control shows authorization in practice. Finance staff can open financial reports, while other authenticated employees can't. Banking apps add multi-factor authentication before authorizing high-value transactions, because the risk of the action changes the required proof.

Explain token lifetimes without being prompted. Access tokens should be short-lived, with refresh tokens handling renewal, so a leaked token has a limited window. If passwords come up, say they're hashed with a slow, salted algorithm, never stored in plain text and never reversibly encrypted. Hashing verifies a password without keeping a readable copy.

9. Compare Containers and Virtual Machines and Explain the Role of Docker and Kubernetes

Start with the problem every developer knows. The app works on your laptop and breaks on the server because a library, runtime, or setting differs. A container image packages the application with its dependencies so it runs consistently across environments.

A virtual machine virtualizes hardware and runs a full guest operating system. That gives strong isolation and lets you run different operating systems on one host, but it's heavier to start and maintain. A container shares the host operating system kernel and isolates the application process, so it starts faster and uses fewer resources, with a different isolation boundary.

Docker Builds and Runs and Kubernetes Operates

A Docker image is the packaged template. A container is a running instance of that image. Developers use Docker Compose to run a web app, database, and cache together locally, which is a clean example for an interview.

Kubernetes operates containers across a cluster. It schedules workloads, restarts failed instances, scales them, and exposes them through services. At a high level, a pod holds one or more containers, a deployment manages desired replicas and updates, and a service gives those pods a stable network endpoint.

Don't oversell orchestration. A single small service may not justify Kubernetes complexity, and saying so shows judgment. Google's internal container infrastructure informed Kubernetes design, and Spotify has publicly described using Kubernetes for its microservices platform, but scale and team capacity should drive the choice.

10. Design a URL Shortener as a System Design Interview Question

Don't draw boxes first. Clarify requirements. Do links expire, can users choose custom aliases, do you need click analytics, and is this read-heavy? Services such as Bitly and TinyURL look simple, but redirects, abuse prevention, and analytics change the design quickly.

Then estimate scale in rough terms and state your assumptions. Propose a write path that accepts a long URL, generates a short code, stores the mapping, and returns the short link. Propose a read path that looks up the code, ideally from cache, and redirects the user.

The central tradeoff is code generation. Hashing the long URL is simple but collisions need handling and the same URL produces the same code unless you add variation. Encoding a counter-based ID avoids collisions and produces short codes, but it needs a reliable way to generate unique IDs across servers and can make codes predictable.

Bottlenecks Interviewers Probe

Popular links create hot reads, so cache them close to users and protect the database during traffic spikes. Analytics writes shouldn't slow the redirect, so record click events asynchronously. Rate limiting and malicious URL checks matter because shorteners attract abuse.

Practice with a timer and a whiteboard, then review against a rubric. These system design templates for structuring your answers give you a repeatable order for requirements, estimates, data model, architecture, and tradeoffs. Interviewers reward a clear, evolving design more than a perfect first sketch.

10 Essential Technical Interview Questions Comparison

Topic	🔄 Complexity	⚡ Resource Requirements	📊 Expected Outcome	Ideal Use Cases / Roles	⭐ Key Advantage
Process vs. thread	Moderate; compare isolation, sharing, and synchronization	OS fundamentals; concurrency examples	Explains execution, fault isolation, and performance tradeoffs	Backend, systems, and mobile engineering interviews	💡 Demonstrates understanding of concurrency and resource sharing
Big O and algorithm complexity	Moderate to high; analyze time and auxiliary space	Data structures and algorithm practice	Identifies scalability and complexity bottlenecks	Coding interviews across software and data roles	⭐ Provides a standard way to compare algorithm efficiency
SQL salary query and JOIN types	Moderate; handle ties, edge cases, and dialect differences	SQL practice database; subqueries and window functions	Produces correct rankings and explains row matching	Data analyst, data engineer, backend, and business roles	📊 Tests practical database querying in a focused exercise
ACID and database indexes	Moderate; explain transaction guarantees and index tradeoffs	Database fundamentals; transaction and query examples	Shows how reliability and query performance are managed	Backend, database, data, and fintech roles	⭐ Connects data integrity with performance considerations
REST, GraphQL, and idempotency	Moderate; compare API styles and request semantics	HTTP and API design fundamentals	Supports informed API choices and safe retry behavior	Backend, full-stack, and mobile development	💡 Highlights client needs, caching, and duplicate-request risks
Browser URL request lifecycle	Moderate to high; connect networking and rendering stages	Networking, HTTP, TLS, DNS, and browser basics	Explains page loading end to end	Web, cloud, DevOps, and network roles	📊 Demonstrates broad systems understanding
TCP vs. UDP	Low to moderate; contrast reliability and latency	Transport-layer networking fundamentals	Matches protocols to application needs	Networking, backend, systems, and game development	⚡ Clarifies reliability-versus-latency tradeoffs
Authentication, authorization, OAuth 2.0, and JWT	Moderate; distinguish identity, access, and token roles	Security fundamentals; OAuth/OIDC concepts	Supports secure access-control explanations	Security, backend, cloud, and full-stack roles	⭐ Reinforces essential security boundaries and standards
Containers, VMs, Docker, and Kubernetes	Moderate to high; distinguish runtime, isolation, and orchestration	Container and cloud fundamentals; deployment examples	Explains packaging, isolation, scaling, and management	DevOps, cloud, SRE, and backend roles	⚡ Shows how to deploy consistent, scalable applications
URL shortener system design	High; clarify requirements, estimate scale, and compare architecture choices	Distributed systems concepts; diagrams and rough calculations	Produces a scalable design with explicit tradeoffs	Senior software, backend, and distributed-systems interviews	📊 Covers APIs, storage, caching, and scaling in one exercise

Build a Practice Plan That Improves Your Answers

Turn this list into a preparation cycle rather than a reading exercise. First, pick only the questions relevant to your target role and rate each one by difficulty based on your current knowledge. A backend candidate should weight APIs, databases, and system design heavily, while an infrastructure candidate should spend more time on networking, operating systems, containers, and the URL request flow.

That targeting reflects how employers assess people. Technical discussions were used by 75.27% of hiring teams and live-coding interviews by 49.82% in the 2025 CoderPad and CodinGame State of Tech Hiring data. You're preparing to talk through decisions as much as you're preparing to write code. Record yourself answering each question aloud for a few minutes, then compare your response against the examples, tradeoffs, and common mistakes above.

Practice Real Work Not Only Puzzles

Broaden beyond algorithm drills. In HackerRank's 2025 Developer Skills Report, 78% of developers said technical assessments do not align with real-world tasks and 66% preferred practical coding challenges. Prepare for debugging a failing deployment, reviewing a questionable code change, designing observability for a service, and explaining a tradeoff to a nontechnical stakeholder.

Early-career candidates should take that seriously. You may lack production incidents, but you can still show structured investigation. State what you'd check first, what evidence would change your mind, and how you'd verify a fix. That reasoning is observable, and observable reasoning is what a structured rubric can score.

There's evidence behind that approach. Structured interviews reached validity values of 0.50 versus 0.40 for unstructured interviews when predicting job performance in the meta-analysis summarized in the structured interview research. Questions that represent situations encountered on the job carry stronger content validity. Memorizing isolated puzzle solutions is weaker preparation than practicing transferable reasoning on role-relevant problems.

Run Timed Rehearsals and Review Against Criteria

Mix foundational, applied, and design prompts in each session. Answer a process and thread question, write and explain a query, then design a small system. Force yourself to handle a follow-up you didn't expect, because follow-ups are where memorized answers collapse.

• Score clarity: Did you define terms before using them and keep the answer ordered?
• Score tradeoffs: Did you name a cost, a failure mode, and a case where you'd choose differently?
• Score verification: Did you mention tests, logs, metrics, or a concrete check?
• Score candor: Did you admit limits and explain how you'd find out?

Use Interview Pilot's searchable question bank and AI mock sessions to simulate those follow-ups and identify gaps across roles. Keep the sessions short and frequent, review the recording the same day, and rewrite only the weakest answer. A strong technical answer is concise, structured, candid about tradeoffs, and grounded in real implementation details, and you'll get there faster by rehearsing decisions than by rereading definitions.

---

Pick three questions from this list that match your target role, answer them aloud today, then run a timed mock session with follow-ups in Interview Pilot to pressure-test your tradeoffs and explanations. Its role-specific question bank, guided mock interviews, and real-time answer suggestions across more than 99 languages help you turn shaky knowledge into clear, structured answers before the live interview.