What is the Linux kernel and how does it differ from a Linux distribution?

Start by defining the kernel as the core part of the operating system that manages hardware, processes, memory, and system calls. Explain that the kernel is a low-level component while a distribution bundles the kernel with userland tools, package managers, and system configurations. Give a practical example: the kernel provides device drivers and scheduling, while distributions like Ubuntu or CentOS include apt or yum, init systems, shells, and default libraries. You can mention situations where you might upgrade the kernel separately from the distribution, or choose a minimal distro for containers. When answering, avoid overgeneralizing and show you understand both roles by naming a distro and a kernel feature you have worked with. Don’t confuse the kernel with user-space utilities, and if asked follow up with which kernel version you’ve managed and why.

How do you check system memory and swap usage on a Linux machine?

Explain the commands you use first, such as free -m, vmstat, and top or htop for live views, and mention /proc/meminfo for raw details. Describe what fields like total, used, free, buffers, and cached mean and how swap relates to physical memory. Give an example: you might run free -m to get a quick snapshot, then use vmstat 1 5 to watch trends, and check /proc/swaps if swap activity is high. If diagnosing memory pressure, explain how you differentiate between high cache usage and true out-of-memory conditions. Offer a tip to avoid misinterpretation: don’t treat cached memory as wasted memory, and confirm memory pressure by observing swap usage, system load, and OOM killer logs in dmesg. Practice reading these outputs before an interview so you can interpret them confidently.

How do you find and kill a runaway process?

Describe using ps aux, top, or pgrep to identify the process, combining that with lsof or strace when you need context about file descriptors or syscalls. Explain how to use kill with signals like SIGTERM and SIGKILL, and why you try a graceful termination before forcing the process to stop. Provide a scenario: you see a process consuming 95 percent CPU in top, you run ps -o pid,user,cmd -p to confirm the command, then try kill , and if it ignores SIGTERM you use kill -9 after checking for critical resources. If the process holds important files, mention coordinating with stakeholders before force-killing it. Warn about pitfalls such as killing the wrong PID on a busy system and the risk of data corruption if the process handles writes when killed. Recommend verifying process ownership and recent logs in /var/log before taking irreversible action.

Explain Linux file permissions and how chmod, chown, and umask work together.

Start with the basic permission model: owner, group, and others with read, write, and execute bits, and explain symbolic (rwx) and octal (e.g., 755) representations. Describe chown to change ownership, chmod to change mode bits, and umask as a value that masks default permissions for newly created files and directories. Offer an example: if your umask is 0022, a new file created with mode 666 becomes 644, and a new directory created with mode 777 becomes 755. Show a practical command sequence: chown alice:www-data /var/www && chmod 750 /var/www to give the owner full access and group execute and read. Note common mistakes, such as setting execute bits on files that don’t need them or applying 777 recursively on web directories. Emphasize checking both ownership and permissions when access issues arise and using getfacl when Access Control Lists are in play.

What is an inode and how can you find inode usage on a filesystem?

Explain that an inode is a filesystem data structure storing metadata about a file, such as ownership, permissions, timestamps, and pointers to data blocks, but not the filename itself. Mention that the number of inodes is set when the filesystem is created and running out of inodes prevents new files even if space remains. Show commands: use df -i to display inode usage per filesystem and tune2fs -l /dev/sda1 to see inode count for ext filesystems. Give a practical example where a mail server or a directory with many tiny files consumed all inodes, and how you diagnosed it with find /path -xdev -printf '%h ' | sort | uniq -c to locate the offending directory. Advise freeing inodes by removing many small files or consolidating them into archives, and consider reformatting with different mkfs options if inode density needs to change. Avoid repeatedly deleting random files without understanding their purpose.

How do you schedule recurring tasks and what are systemd timers?

Start with crontab for classic scheduling and explain the syntax of minute, hour, day, month, and weekday fields. Then introduce systemd timers as a modern alternative that integrates with unit files, allowing more flexible triggers and detailed logging through journalctl. Give a concrete example: use crontab -e to add a line like 0 2 * * * /usr/local/bin/backup.sh for nightly backups, and show a systemd timer pair with my-backup.service and my-backup.timer where OnCalendar= daily triggers the service and systemctl status shows last and next runs. Mention that timers can express monotonic delays or calendar events more precisely than cron. Point out that cron runs with limited environment variables and systemd timers run as units with configured environments, so always test paths and permissions. Recommend checking journalctl -u after a timer run to debug issues and avoid assuming both tools behave identically.

How would you troubleshoot a service that won’t start under systemd?

Outline a method: check systemctl status for a quick summary, then inspect journalctl -u for logs, and review unit files in /etc/systemd/system or /lib/systemd/system for configuration errors. Mention using systemctl daemon-reload after changes and systemctl start --no-block for asynchronous issues. Provide an example: a web service fails due to a missing environment file; logs show Failed to read environment file, you edit the unit to point to the correct path, run systemctl daemon-reload, and restart. If the unit depends on network-online.target, show checking the After and Wants directives to ensure proper ordering. Tell interviewers you would also verify file permissions, SELinux or AppArmor denials with ausearch or audit logs, and test running the executable directly to separate service wrapper problems from application issues. Avoid changing production config blindfolded; reproduce locally when possible.

What are common networking commands you use to diagnose connectivity issues?

List and explain primary tools: ip addr and ip link for interfaces, ip route for routing table, ping for basic reachability, traceroute for path discovery, ss or netstat for sockets, and tcpdump for packet capture. Describe when to use each tool in a layered troubleshooting approach, starting with link and addressing, then routing, then application-level checks. Give an example workflow: if a server cannot reach an API, you check ip addr to confirm interface up, ping gateway, inspect ip route to validate default route, use ss -tln to verify local ports, and capture packets with tcpdump -i eth0 host api.example.com to see if traffic leaves the host. Mention analyzing ARP tables with ip neigh when link-level problems appear. Explain common pitfalls like firewalls blocking ICMP or tcpdump capturing on the wrong interface, and recommend testing from multiple points in the network to isolate host versus network issues. Practice these commands so you can run them confidently under interview pressure.

How do you manage packages and handle dependency issues on Debian and RHEL systems?

Describe apt and dpkg for Debian-based systems and yum or dnf and rpm for RHEL-based systems, including how to search, install, remove, and query packages. Explain difference between package manager operations and low-level package tools, and mention how repositories and GPG signatures affect package trust. Give a practical case: if apt-get install fails due to broken dependencies, you might run apt-get update, apt-get -f install to fix dependencies, and dpkg --configure -a for half-configured packages, whereas on RHEL dnf clean all and dnf install package can resolve metadata issues. If a package causes conflicts, you can inspect rpm -q --whatprovides or apt-cache policy to find alternatives. Warn against blindly forcing removals that break critical system packages, and recommend testing package operations in a staging VM or using container images for risky upgrades. Keep backups and snapshots before major system package changes.

Describe a time you diagnosed a production outage under time pressure.

Situation: In a previous role a critical API went down during peak traffic and customers reported timeouts, creating urgent pressure to restore service. Task: As the on-call engineer, you had to identify the root cause quickly and restore operations while keeping stakeholders informed. Action: You ran quick health checks, confirmed high CPU and network saturation on one node, pulled logs to find a memory leak in a newly deployed component, and rolled back the deployment while redirecting traffic away from the unhealthy node. You also opened a postmortem ticket and documented the rollback steps for repeatability. Result: The rollback restored service within 18 minutes, SLA errors dropped to normal levels, and the postmortem led to a canary deployment process that reduced similar incidents by preventing full rollouts of faulty releases. Share metrics like incident duration and reduction in recurrence when possible.

Tell me about a time you automated a repetitive manual task to save time for the team.

Situation: Your team spent several hours weekly running manual log rotation and archival tasks across many servers, which took time away from higher-value work. Task: You aimed to automate the process and reduce human error while keeping archives searchable. Action: You wrote a shell script to rotate and compress logs, added timestamped S3 uploads for long-term storage, and created a systemd timer to run the task nightly. You tested the script on a staging group, iterated on error handling, and documented the runbook for the team. Result: The automation cut manual effort by approximately four hours per week and eliminated missed rotations that had previously caused disk-full incidents. Quantify savings if you can, and mention improved reliability and reproducibility.

Give an example of mentoring a junior engineer to improve their Linux troubleshooting skills.

Situation: A junior engineer repeatedly escalated simple filesystem and permission issues that slowed incident response times. Task: You needed to raise their confidence and reduce repetitive escalations by teaching core diagnostic steps. Action: You scheduled weekly 1:1s to walk through common scenarios, created a short checklist for diagnosing permission and process problems, and paired on incidents to let them run the first triage while you observed and nudged. You assigned small tasks with increasing complexity and reviewed their write-ups for clarity. Result: Over two months the junior resolved more incidents independently and escalations for basic issues decreased by about half. Highlight measurable improvements and ongoing mentorship plans when possible.

Explain how processes and threads are represented in Linux and how you would inspect them.

Describe that in Linux each process has a pid and a task_struct in the kernel, and threads are typically implemented as tasks that may share memory and other resources while having separate tids. Mention that tools like ps, top, pstree, and pstree -p help visualize process hierarchies and threads, and ps -T shows threads in a session. Give a practical command example: ps -eo pid,ppid,tid,cmd shows thread ids alongside process ids, and top can be toggled to show threads by pressing H. Explain that /proc/ /task lists thread directories for kernel-level inspection. Warn about confusing kernel threads with user threads and remind the interviewer you would consider thread contention, locks, and shared memory when debugging concurrency problems. Use strace or perf when you need to inspect syscalls and performance hotspots.

How does Linux handle virtual memory and the page cache?

Explain virtual memory as the abstraction that gives each process its own address space, backed by physical RAM and swap, and the page cache as the kernel-managed cache of file-backed pages to speed IO. Describe how the kernel evicts pages under pressure and how dirty pages are written back to disk asynchronously. Provide a troubleshooting example: if IO latency is high you can check vmstat and /proc/meminfo to see dirty ratios and writeback activity, and tune vm.dirty_ratio and vm.dirty_background_ratio for heavy write workloads. Use drop_caches cautiously in staging to test cache effects, never in production without understanding consequences. Mention common pitfalls like misinterpreting high cache usage as wasted RAM and the risks of aggressive dirty page settings causing bursts of IO. Recommend profiling with iostat and sar to correlate application behavior with kernel memory management.

Show a simple example of using iptables or nftables to block traffic from a single IP.

Start by stating that nftables is the modern replacement for iptables on many systems, but iptables is still common; provide a concise example for both to show familiarity. For nftables give a command such as: nft add rule inet filter input ip saddr 203.0.113.5 drop, and for iptables show iptables -A INPUT -s 203.0.113.5 -j DROP to block the source. Explain that you must save rules with nft list ruleset > /etc/nftables.conf or iptables-save > /etc/iptables/rules.v4 depending on distro, and verify with nft list ruleset or iptables -L -n. Mention checking for existing rules and ordering because a permissive rule earlier can bypass your block. Caution about locking yourself out when working on remote systems, and suggest adding rules that allow your IP before testing or having out-of-band access. Also mention using firewalld or cloud provider security groups when applicable to avoid manual rule drift.

How do you inspect and analyze log files to troubleshoot an issue?

Explain a layered approach: identify relevant logs in /var/log, use journalctl for systemd-managed services, and apply grep, awk, and sed for quick filters. Describe tail -F for live observation, and combining tools like journalctl -u service --since '2 hours ago' to narrow the timeframe for incidents. Give an example workflow: after a service crash you run journalctl -u service -n 200 to read recent entries, search for error or stack traces, and then correlate timestamps with syslog and application logs to find the initiating event. Use timestamps, request IDs, or correlation IDs when available to trace through distributed logs. Warn against relying solely on one log source and advise validating time synchronization across servers to avoid misleading timelines. Recommend building familiarity with log formats and regular expressions so you can extract relevant fields quickly.

What is SELinux and how do you troubleshoot a denied access caused by it?

Define SELinux as a mandatory access control system that enforces policies restricting how processes access objects, and note that it is enabled by default on several distributions like RHEL and CentOS. Explain that denials are recorded in audit logs and can block actions even when Unix permissions appear correct. Give a troubleshooting example: when you see Permission denied in logs, check ausearch -m avc -ts recent or journalctl for avc messages, then run semanage fcontext -l and restorecon -Rv on files if contexts are wrong. If a quick test is needed, setenforce 0 temporarily to confirm SELinux is the cause, but always restore enforcement and create a policy module or fix contexts rather than leaving it disabled. Mention common pitfalls like ignoring boolean settings that control broader behavior and the risks of leaving SELinux disabled in production. Emphasize documenting policy changes and testing in staging.

linux Interview Questions: Complete Guide

Linux interviews often cover system internals, command-line skills, troubleshooting, and real-world scenarios. Expect a mix of phone screens, hands-on tasks, whiteboard diagrams, and live or take-home labs, and remain calm and methodical as you work through problems.

Common Interview Questions

Behavioral Questions (STAR Method)

STAR Method: Structure your answers using Situation, Task, Action, and Result to tell compelling stories about your experience.

Technical Questions

Questions to Ask the Interviewer

Show your interest by asking thoughtful questions

•What does success look like in this role after six months, and what are the key technical milestones?
•Can you describe the team’s on-call rotation and how incidents are handled and tracked?
•What are the current bottlenecks or technical debt areas the team is prioritizing right now?
•How do you measure system reliability and which metrics or alerts should I be most familiar with?
•What opportunities are there for mentorship and cross-training in adjacent areas like storage, networking, or SRE?

Interview Preparation Tips

Practice live command-line tasks in a VM so you can demonstrate commands without hesitation, and record a short walkthrough to review your phrasing.

Prep concise stories for common behavioral prompts using the STAR format, and keep each story focused on impact and what you learned.

When answering technical questions, talk through your thought process and confirm assumptions before diving into commands or designs.

Mention tools and versions you’ve used, and if you lack experience in a specific tool, explain how you would learn it and describe similar tools you have used.

Overview

This guide prepares you for Linux interviews at all levels: junior sysadmin, mid-level SRE, and senior platform engineer. Interviews often test practical tasks as well as theory.

For example, hiring managers commonly allocate 40–60 minutes to a live practical exercise—such as debugging a broken systemd service or writing a shell script to rotate logs—followed by 20–30 minutes of behavioral and design questions.

Focus areas that repeatedly appear in hiring rubrics include: process and memory management, file systems and permissions, networking basics (routing, iptables/nftables), package management, and boot/init systems (systemd). Expect at least one scripting problem: 60–80% of junior-to-mid interviews require writing Bash or Python snippets to parse log files, manage services, or automate backups.

At senior levels, plan to explain architecture choices: how you would design a high-availability NFS cluster, or how to migrate services to containers with minimal downtime.

Practical tips:

•Practice timed tasks: solve 3, 15–30 minute problems per week for 4–6 weeks.
•Record yourself explaining solutions; clear verbal explanations raise hire rates by about 20% in panel interviews.
•Use a VM snapshot workflow to reproduce failures quickly.

Actionable takeaway: build a study checklist mapping topics to sample tasks (e. g.

, disk full: find large files using `du -sh /var/* | sort -h | tail -n10`) and practice each item under a 30-minute timer.

Key Subtopics and Example Questions

Break your prep into focused subtopics. Below are concrete topics, example questions, and practical drills you can run in 30–60 minutes.

1) Shell Scripting (25% of practical rounds)

•Example question: "Write a script that archives logs older than 7 days and keeps 5 archives."
•Drill: Implement with `find /var/log -type f -mtime +7 -print0 | xargs -0 tar -czf archive-$(date +%F).tar.gz` and a cleanup routine that deletes older archives using `ls -1t | sed -n '6,$p' | xargs rm`.

2) System and Process Management (15%)

•Example: "How to find and kill a runaway process consuming >80% CPU–
•Drill: Use `ps aux –sort=-%cpu | head -n6`, then `kill -9 PID` if needed; practice reading `/proc/PID/status`.

3) Filesystems and Storage (15%)

•Example: "Explain inode exhaustion and how to detect it." Use `df -i` and recreate with `fallocate` to see behavior.

4) Networking (15%)

•Example: "Diagnose why a server cannot reach 10.0.1.5." Steps: `ip addr`, `ip route`, `ping`, `tcpdump -n -i eth0 host 10.0.1.5`.

5) Services and Init (10%)

•Example: "Debug a failing systemd service." Use `systemctl status`, `journalctl -u name –since "1 hour ago"`, check unit files.

6) Security and Access Control (10%)

•Example: "Troubleshoot a file permission issue vs SELinux denial." Check `ls -l` and `ausearch -m avc` or `sealert`.

7) Containers and Orchestration (10%)

•Example: "How to limit container memory– Practice with `docker run –memory=512m` and observe OOM behavior.

Actionable takeaway: allocate study time by percent above and complete one hands-on drill for each subtopic weekly.

Recommended Resources and Study Plan

Use a mix of books, hands-on labs, and quick-reference tools. Below are targeted picks and a sample 8-week plan with hours per week.

Books and Manuals (read 1–2 chapters per session)

•"The Linux Programming Interface" (Michael Kerrisk) — deep syscall and process examples.
•"UNIX and Linux System Administration Handbook" — practical runbooks and common failure modes.
•man pages and `man 2`/`man 5` for concrete details (spend 15 minutes per command).

Online Courses and Labs

•Linux Foundation LFD201 or LFS101x — 20–30 hours of structured labs.
•Coursera: courses on system administration and networking (10–20 hours).
•Katacoda/Play with Docker — interactive scenarios for containers (5–10 hours).

Practice Platforms

•OverTheWire Bandit — sharpen shell and file manipulation skills (1–2 hours per level).
•HackerRank Shell challenges — timed scripting problems.
•GitHub: search for "linux-interview-questions" repos to review 200+ real interview prompts.

Cheat Sheets and Tools

•tldr pages and `cheat` for concise command examples.
•`strace`, `lsof`, `ss`, `tcpdump`, `journalctl` — practice each on a VM.

8-Week Study Plan (6–8 hours/week)

•Weeks 1–2: shell + process basics (40% hands-on)
•Weeks 3–4: networking + storage (30%)
•Weeks 5–6: services, security, systemd (20%)
•Weeks 7–8: containers, mock interviews, and review (10%)

Actionable takeaway: pick one book, one interactive lab series, and set a calendar: 6 hours/week split into three 2-hour sessions.

linux Interview Questions: Complete Guide

Michael Rodriguez

Common Interview Questions

Behavioral Questions (STAR Method)

Technical Questions

Questions to Ask the Interviewer

Interview Preparation Tips

Overview

Key Subtopics and Example Questions

Recommended Resources and Study Plan

Common Interview Questions

Build your job search toolkit

linux Interview Questions: Complete Guide

Michael Rodriguez

Common Interview Questions

Q1What is the Linux kernel and how does it differ from a Linux distribution?

Q2How do you check system memory and swap usage on a Linux machine?

Q3How do you find and kill a runaway process?

Q4Explain Linux file permissions and how chmod, chown, and umask work together.

Q5What is an inode and how can you find inode usage on a filesystem?

Q6How do you schedule recurring tasks and what are systemd timers?

Q7How would you troubleshoot a service that won’t start under systemd?

Q8What are common networking commands you use to diagnose connectivity issues?

Q9How do you manage packages and handle dependency issues on Debian and RHEL systems?

Behavioral Questions (STAR Method)

B1Describe a time you diagnosed a production outage under time pressure.

B2Tell me about a time you automated a repetitive manual task to save time for the team.

B3Give an example of mentoring a junior engineer to improve their Linux troubleshooting skills.

Technical Questions

T1Explain how processes and threads are represented in Linux and how you would inspect them.

T2How does Linux handle virtual memory and the page cache?

T3Show a simple example of using iptables or nftables to block traffic from a single IP.

T4How do you inspect and analyze log files to troubleshoot an issue?

T5What is SELinux and how do you troubleshoot a denied access caused by it?

Questions to Ask the Interviewer

Interview Preparation Tips

Overview

Key Subtopics and Example Questions

Recommended Resources and Study Plan

Common Interview Questions

Build your job search toolkit