IT Interview Questions

Note: IT covers an enormous range, so the interviewer is placing you. Be concrete about scale and scope rather than describing yourself as "technical".

Cover:

• The organisation and estate. How many users, how many sites, and what you supported — desktops, servers, network, cloud services, or a mix.
• Your scope. First-line support, second or third line, systems administration, or infrastructure. Where escalations went, and what you owned end to end.
• The technologies. Windows and Active Directory, Linux, Microsoft 365 or Google Workspace, networking, and any cloud platform. Be honest about depth versus familiarity — inflated claims collapse on the first technical follow-up.
• What you improved. Automating a repetitive task, documenting something undocumented, reducing recurring tickets by fixing a root cause, or completing a rollout or migration.

Numbers help: ticket volume handled, users supported, or systems managed.

Describe a method, since IT interviews care far more about how you think than what you have memorised.

• Define the problem precisely first. What exactly happens, what was expected, when did it start, who is affected, and is it reproducible. "It does not work" is not a problem statement, and getting to a precise one solves a surprising number of issues immediately.
• Find out what changed. An update, a configuration change, a password expiry, a certificate renewal, or new hardware. Most things that used to work and now do not were changed by someone.
• Narrow the scope systematically. Is it one user or many, one machine or all, one application or everything, one site or the whole network? Each answer eliminates whole categories of cause.
• Work in layers. For anything network-related, work up from physical connectivity to IP, to DNS, to the application. Skipping to the complicated explanation before checking the simple one wastes hours.
• Change one thing at a time, and note what you tried.
• Search deliberately — the exact error text, and vendor documentation before forum answers.

Note: Saying you know when to escalate, and that you escalate with the diagnostic work already done rather than passing on a bare ticket, is a strong and practical point.

The skill is translation without condescension.

• Start from what they care about, not from the mechanism. A user does not want to know about DNS propagation; they want to know when their email will work and what to do meanwhile.
• Use an analogy only if it holds, and abandon it once it stops helping. A stretched analogy creates a wrong mental model that causes confusion later.
• Drop the jargon, but do not oversimplify to the point of inaccuracy. People notice when they are being managed rather than informed.
• Check understanding by asking them to tell you what they will do, rather than asking "does that make sense?", which almost always gets a yes.
• Give them the action. Most non-technical people need to know what to do and when it will be resolved — the explanation is context, not the point.

Note: A strong version involves explaining a security requirement people found annoying — MFA, or a password policy — where you had to get genuine buy-in rather than just compliance. Explaining why something protects them personally works far better than citing policy.

Give a triage framework rather than saying you work hard.

• Assess impact and urgency quickly. How many people are affected, how critical is the system to the business, and is the situation deteriorating. A whole department unable to work outranks one person's individual issue, regardless of who escalated loudest.
• Security incidents go first. Delay compounds the damage.
• Check whether they are related. Several simultaneous reports are frequently one underlying failure, and recognising that turns three problems into one.
• Communicate to everyone waiting. A realistic timeframe stops people chasing, which itself consumes time. Silence produces escalation.
• Delegate and escalate early. Involving someone else while there is still time is far better than at the point of failure.
• Apply a workaround to buy time where one exists, so people can work while you fix the cause properly.

Note: Being clear that priority is set by business impact rather than by seniority of the person asking — while handling that diplomatically — is what interviewers are checking for. So is recognising when to say you cannot do everything and ask which should wait.

How you learn: vendor documentation and release notes for the platforms you run, a home lab or free cloud tier for hands-on practice, and certifications where they fill a structured gap. Be honest that certifications demonstrate knowledge rather than experience — claiming otherwise is easily exposed.

What is worth prioritising:

• Fundamentals first. Networking, operating systems, identity, and how DNS actually works underpin everything and do not go out of date. Someone who understands these can learn any specific product.
• Automation and scripting. PowerShell or Python is now close to essential — the manual work IT used to do is increasingly expected to be scripted, and it is the clearest way to move beyond repetitive tasks.
• Cloud platforms, because almost every environment now includes them.
• Security, which has become part of every IT role rather than a separate specialism.

How you apply it: pick one thing you do repeatedly and automate it. That produces a demonstrable result, teaches the skill properly, and is something concrete to talk about in an interview.

Note: Naming the specific next thing you intend to learn and why gives a much more credible answer than listing everything you have looked at.

The OSI model describes networking in seven layers, each serving the one above.

• 7. Application — protocols users interact with: HTTP, SMTP, DNS, FTP.
• 6. Presentation — encoding, encryption, and compression. TLS is usually placed here.
• 5. Session — establishing and managing connections between applications.
• 4. Transport — end-to-end delivery. TCP (reliable, ordered, connection-oriented) and UDP (fast, connectionless, no delivery guarantee). Ports live here.
• 3. Network — logical addressing and routing between networks. IP addresses, routers, and ICMP.
• 2. Data Link — delivery within a single network segment. MAC addresses, switches, and VLANs.
• 1. Physical — cables, connectors, radio, and electrical signalling.

Why it matters practically: it gives you a troubleshooting order. Work up from the bottom — is it physically connected, does it have an IP address, can it reach the gateway, does DNS resolve, does the application respond. Jumping to layer 7 when the cable is unplugged is the mistake the model prevents.

Note: The TCP/IP model is the one actually implemented, with four layers — Link, Internet, Transport, Application. OSI survives because it is a better teaching and diagnostic framework. Being able to say that shows understanding rather than memorisation.

• IP address — the device's identity on the network, such as 192.168.1.50. IPv4 is 32 bits; IPv6 is 128 bits and exists because IPv4 addresses ran out.
• Subnet mask — divides the address into a network portion and a host portion. With 255.255.255.0 (or /24), the first three octets identify the network. This is how a device decides whether a destination is local — deliverable directly — or remote and must go via the router.
• Default gateway — the router's address, where traffic destined for other networks is sent. Without it a device can reach its own subnet but nothing beyond, which presents as "local network works, internet does not".
• DNS server — resolves names to addresses. Without working DNS almost everything appears broken even though connectivity is fine — the classic symptom is that a site fails by name but works by IP.

Private ranges — 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 — are not routable on the internet, which is why NAT translates them to a public address at the router.

Note: A 169.254.x.x address is worth recognising instantly. It is APIPA, self-assigned when the device could not reach a DHCP server — so the problem is DHCP or physical connectivity, not the device's configuration.

TCP is connection-oriented and reliable. It establishes a connection with a three-way handshake, numbers every segment, acknowledges receipt, retransmits what is lost, and delivers data in order. It also manages flow and congestion. The cost is overhead and latency.

UDP is connectionless. It sends datagrams with no handshake, no acknowledgement, no retransmission, and no ordering guarantee. It is faster and lighter, and the application must handle any loss itself.

How to choose: TCP where every byte must arrive — web pages, email, file transfer, database connections. UDP where timeliness beats completeness — live voice and video, gaming, and DNS, where a single small query and reply is cheaper than establishing a connection.

Common ports worth knowing:

• 20/21 FTP, 22 SSH and SFTP, 23 Telnet (insecure, should be disabled)
• 25 SMTP, 587 SMTP submission, 465 SMTPS
• 53 DNS (UDP normally, TCP for large responses and zone transfers)
• 67/68 DHCP, 69 TFTP
• 80 HTTP, 443 HTTPS
• 110 POP3, 143 IMAP, 993 IMAPS
• 389 LDAP, 636 LDAPS
• 3306 MySQL, 1433 SQL Server, 5432 PostgreSQL
• 3389 RDP, 445 SMB

Note: RDP and SMB should never be exposed directly to the internet — both are routinely scanned for and are common ransomware entry points.

DNS translates names into IP addresses. When a client looks up a name:

• It checks its local cache, then the hosts file.
• It queries its configured resolver, which checks its own cache.
• If not cached, the resolver queries a root server, which directs it to the top-level domain servers, which direct it to the domain's authoritative name servers, which return the record.
• The result is cached for the record's TTL.

Record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail servers), TXT (SPF, DKIM, verification), NS (authoritative servers), PTR (reverse lookup).

Troubleshooting, in order:

• Can you reach the IP directly? If yes, the problem is definitively DNS rather than connectivity.
• nslookup or dig against the configured server, then against a public one such as 8.8.8.8. A difference isolates it to internal DNS.
• Check the client's DNS settings with ipconfig /all or resolv.conf. A domain-joined machine pointing at a public resolver cannot resolve internal names — an extremely common misconfiguration.
• Flush the cache — ipconfig /flushdns — since stale entries persist after a record changes.
• Check the TTL if a record was recently updated. What people call propagation is really cache expiry.

Active Directory Domain Services is Microsoft's directory service — a central database of users, computers, and groups providing authentication and authorisation across a Windows network. Its value is one identity instead of separate accounts on every machine.

The structure:

• Forest — the top-level security boundary containing one or more domains.
• Domain — an administrative boundary with its own policies.
• Organisational Unit (OU) — a container for organising objects, and the target for Group Policy and delegated administration.
• Domain Controller — a server hosting the directory and handling authentication using Kerberos.

Group Policy applies configuration centrally — password policy, drive mappings, software deployment, security settings — which is what makes managing thousands of machines practical. Policies apply in the order Local, Site, Domain, OU, with later overriding earlier.

Authentication versus authorisation:

• Authentication proves who you are. Something you know, something you have, or something you are. Multi-factor means two different categories.
• Authorisation determines what you may do once authenticated — group membership, file permissions, and rights.

Note: Being able to log in but not access a share is an authorisation problem, not an authentication one. Making that distinction quickly is what makes access troubleshooting efficient.

Three devices operating at different layers, and the difference is how intelligently they forward traffic.

• Hub — Layer 1. Repeats every incoming signal out of every other port with no intelligence. Every device sees all traffic, collisions are frequent, and bandwidth is shared. Hubs are obsolete and should never appear in a modern network; they are asked about to test whether you understand why switches replaced them.
• Switch — Layer 2. Learns which MAC address is on which port and forwards frames only to the correct destination port. This eliminates collisions, gives each port full bandwidth, and is the standard building block of a local network. Managed switches add VLANs, which segment one physical switch into separate logical networks, plus port security, link aggregation, and monitoring.
• Router — Layer 3. Connects different networks and forwards packets between them based on IP addresses and a routing table. It is the boundary of a broadcast domain, and it is where NAT, firewalling, and DHCP services usually live in smaller networks.

The simple distinction to state: a switch moves traffic within a network; a router moves traffic between networks.

Note: A Layer 3 switch blurs the line — it switches at wire speed and also routes between VLANs, which is how routing is typically done inside a modern campus network rather than sending everything through a separate router.

Redundancy protects against component failure — a duplicate disk, power supply, server, or link keeps the service running. It is about availability, and the copies are live and synchronised.

Backup protects against data loss — deletion, corruption, ransomware, or a bad change. The copies are separate in time as well as location.

The distinction that matters: RAID is not backup. A deleted file, a corrupted database, or an encrypted-by-ransomware volume replicates instantly across every disk in the array. Neither is synchronous replication to a second site. Believing redundancy provides backup is a common and expensive mistake.

A good backup strategy:

• The 3-2-1 rule — three copies, on two different media, with one off-site. It survives hardware failure, site loss, and most ransomware.
• Immutable or air-gapped copies. Now essential, because ransomware specifically targets backups. A backup reachable with the credentials the attacker stole is not a backup.
• Frequency matched to your RPO — how much data you can afford to lose.
• Retention matched to legal and regulatory requirements, including versions far enough back to predate a slow corruption.
• Monitoring, so a silently failing backup job is noticed before it is needed.

Note: The point to end on: an untested backup is not a backup. Regular restore drills, timed against the recovery objective, are what turn a policy into a capability — and a great many organisations discover theirs is unusable only when they need it.

Identity — where most attacks now begin:

• Multi-factor authentication everywhere, especially on remote access, email, and administrative accounts. This single control blocks the large majority of credential attacks.
• Least privilege. Users are not local administrators; administrators use a separate account for privileged work and a normal one for email and browsing.
• Prompt deprovisioning when people leave, ideally automated from HR.

Systems:

• Patch on a defined cycle, prioritising internet-facing systems and actively exploited vulnerabilities.
• Change all default credentials and disable unused services and accounts.
• Disable legacy protocols — SMBv1, TLS 1.0, and Telnet.
• Encrypt disks on laptops and mobile devices.

Network: segment so a compromise in one area does not reach everything; never expose RDP or SMB to the internet; and use a VPN or zero trust access for remote work.

Detection and recovery: centralised logging that an attacker cannot delete, endpoint detection, and tested backups that are immutable or offline.

People: phishing awareness training measured on reporting rate rather than click rate, and a culture where reporting a mistake is safe.

Note: Say that security is now part of every IT role rather than a separate team's problem. The most common breaches exploit basic gaps — an unpatched server, a missing MFA, a default password — not sophisticated attacks.

Cloud computing delivers computing resources on demand over the internet, paid for by consumption rather than purchased outright. The shift is from capital expenditure on hardware you must size for peak demand, to operating expenditure that scales with actual use.

The service models:

• IaaS — virtual machines, storage, and networking. You manage the operating system upwards. AWS EC2, Azure Virtual Machines.
• PaaS — the provider manages the OS and runtime; you deploy applications. Azure App Service, AWS Elastic Beanstalk.
• SaaS — a finished application. Microsoft 365, Salesforce.

The deployment models:

• Public cloud — shared infrastructure from a provider. Lowest cost, effectively unlimited scale, no hardware to manage. The trade-offs are less control and dependence on the provider.
• Private cloud — dedicated infrastructure, on-premises or hosted. Chosen for regulatory requirements, data residency, or specific performance needs. More control, higher cost, and you still manage the hardware.
• Hybrid cloud — both, connected. The most common reality: legacy or regulated workloads stay on-premises while new work goes to public cloud. Also used for burst capacity and disaster recovery.
• Multi-cloud — more than one public provider, for resilience, negotiating position, or because different providers suit different workloads.

Note: Two practical points worth raising: cloud is not automatically cheaper, and cost control requires active management; and the shared responsibility model means securing your data and configuration remains yours regardless of provider.

Virtualisation runs multiple isolated operating systems on one physical machine. A hypervisor sits between the hardware and the guests, allocating CPU, memory, storage, and network to each.

• Type 1 (bare metal) — runs directly on the hardware. VMware ESXi, Microsoft Hyper-V, KVM. Used in datacentres because there is no host operating system consuming resources or adding a failure point.
• Type 2 (hosted) — runs as an application on a host OS. VirtualBox, VMware Workstation. Used for development and testing.

Why it is used:

• Consolidation. Physical servers typically ran at very low utilisation; virtualisation puts many workloads on one machine, cutting hardware, power, cooling, and rack space substantially.
• Isolation. One virtual machine crashing does not affect the others.
• Snapshots. Capture a machine's state before a risky change and roll back in seconds — enormously valuable for patching and testing.
• Live migration. Move a running VM between hosts with no downtime, which makes hardware maintenance possible during working hours.
• Rapid provisioning from templates, in minutes rather than weeks.
• Disaster recovery. A VM is a set of files, so replicating it to another site is far simpler than rebuilding physical hardware.

Note: Containers are the natural follow-up — they virtualise the operating system rather than the hardware, sharing the host kernel, so they are far lighter and start in under a second, but with weaker isolation. The two are complementary, and containers usually run on virtual machines.