Hadoop interviews test whether you understand how data is stored and processed across a cluster, and whether you know what has changed since the early days. This guide gives you 46 Hadoop interview questions and answers, from basics to scenario questions, for freshers and experienced candidates.
Every answer starts with a short, direct response you can say aloud, followed by a table, a command or a small Python example that you can run. The page separates Hadoop 1, 2 and 3 clearly, because mixing them is the most common mistake in interviews, and it marks which ecosystem tools are active, dormant or retired.
The guide has seven parts: 8 on Hadoop basics, 6 on HDFS, 6 on YARN, 9 on MapReduce, 6 on the Hadoop ecosystem, 5 on Hadoop 3 and operations and 6 scenario questions. For more depth, read the separate HDFS, Hive and Flume interview pages.
| Section | Questions |
|---|---|
| Hadoop Basics (Freshers) | Q1 to Q8 |
| HDFS Overview (Freshers and Intermediate) | Q9 to Q14 |
| YARN (Intermediate) | Q15 to Q20 |
| MapReduce (Freshers and Intermediate) | Q21 to Q29 |
| The Hadoop Ecosystem (Intermediate) | Q30 to Q35 |
| Hadoop 3 and Operations (Experienced) | Q36 to Q40 |
| Scenario Questions (Experienced) | Q41 to Q46 |
Start with what Hadoop is, why it exists and what its core parts do. Keep the answers short, and be careful to separate Hadoop 1 from Hadoop 2 and 3.
Apache Hadoop is an open source framework for storing and processing very large datasets across clusters of ordinary machines. It solves two problems: storing data too big for one machine, using HDFS, and processing it in parallel close to where it is stored, using MapReduce and other engines on YARN. It is built to survive machine failures.
Hadoop has four core modules. HDFS is the distributed file system for storage. YARN is the resource manager that schedules jobs and allocates cluster resources. MapReduce is the original batch processing engine. Hadoop Common holds the shared libraries and utilities that the other modules need.
| Component | Role | Introduced |
|---|---|---|
| HDFS | Distributed storage | Hadoop 1 |
| MapReduce | Batch processing | Hadoop 1 |
| YARN | Resource management and scheduling | Hadoop 2 |
| Hadoop Common | Shared libraries and tools | Hadoop 1 |
The three Vs are volume, which is the size of the data, velocity, which is the speed at which data arrives, and variety, which is the range of formats such as tables, text, logs, images and sensor data. Two more are often added: veracity, which is trust in the data, and value. Hadoop was designed mainly for volume and variety.
A relational database stores structured data in tables, usually on one large server, and is built for transactions and fast queries with SQL. Hadoop stores any kind of data on many cheap machines, scales by adding nodes, and is built for batch analysis of huge volumes. It is not designed for low latency transactions.
| Point | Hadoop | Relational database |
|---|---|---|
| Data types | Structured, semi structured and unstructured | Mostly structured |
| Scaling | Add nodes (scale out) | Bigger server (scale up) |
| Schema | Applied when reading | Defined before writing |
| Best for | Large batch analysis | Transactions and fast lookups |
| Hardware | Commodity machines | Often specialised servers |
A cluster is a set of machines that work together as one system. Master nodes run the coordinating services, which are the NameNode and the ResourceManager. Worker nodes, also called slave nodes, run the DataNode and the NodeManager, which store data blocks and run the tasks. Most machines in a cluster are workers.
Data locality means moving the computation to the node that holds the data, not moving the data to the computation. Moving a program is far cheaper than moving terabytes across the network. The scheduler tries to run a task on a node with the block, then on the same rack, and only then on a remote rack.
What the interviewer is listening for: You explain that network bandwidth is the scarce resource, and you give the order of preference: same node, same rack, other rack.
Hadoop 1 had HDFS and MapReduce with a JobTracker and TaskTrackers. Hadoop 2, generally available in late 2013, added YARN and a standby NameNode for high availability. Hadoop 3, generally available in December 2017, added erasure coding, support for more than one standby NameNode and many other improvements. The 3.x line is current.
The JobTracker and TaskTracker belong to Hadoop 1. In Hadoop 2 and 3 they are replaced by the ResourceManager, NodeManager and ApplicationMaster.
The 3.x line is current, with 3.5.0 released in April 2026 and 3.4.3 as a stable maintenance release. Check the official release page for the latest version, because releases change. The supported Java version depends on the release, so check the requirements page before you install or upgrade.
What the interviewer is listening for: You say that you would check the release notes and the supported Java list, and you do not quote an old version number from memory.
HDFS has its own interview page with more depth. These questions cover what a Hadoop interview usually asks.
HDFS, the Hadoop Distributed File System, splits each file into large blocks and stores copies of every block on different DataNodes. A NameNode keeps the metadata: the file names, the directory tree and where each block lives. Files are written once and read many times, and appended to, but not edited in the middle.
The default block size is 128 megabytes, set by dfs.blocksize, and it can be changed per file. Blocks are large to keep the metadata small and to make reading mostly sequential, so the time spent seeking is small against the time spent reading. A last block takes only the space it needs.
A 500 MB file makes 4 blocks, the last one only 116 MB, and it takes 1500 MB of raw disk space with three copies. A short last block does not waste a full block of disk.
The NameNode is the master that holds the file system namespace and the mapping of files to blocks, in memory, and decides where blocks go. DataNodes are workers that store the blocks, serve reads and writes, and send heartbeats and block reports to the NameNode. The NameNode never holds the data itself.
| Node | Stores | Reports to |
|---|---|---|
| NameNode | Metadata: namespace and block locations | Clients and DataNodes talk to it |
| DataNode | The actual blocks on local disks | Sends heartbeats and block reports to the NameNode |
The replication factor is the number of copies of each block, three by default. With rack awareness, the first replica goes on the writer node, the second on a node in a different rack, and the third on another node in that second rack. This survives a node or rack failure while limiting cross rack traffic.
With high availability, an active NameNode and one or more standby NameNodes share the edit log through a quorum of JournalNodes, and failover can happen automatically through ZooKeeper based failover controllers. Hadoop 3 allows more than one standby. The old Secondary NameNode is not a hot standby. It only merges the edit log into the image.
What the interviewer is listening for: You say the Secondary NameNode is not a backup, and you mention JournalNodes.
Each file, directory and block is an object in NameNode memory, taking roughly 150 bytes as a rule of thumb. Millions of tiny files therefore use a lot of NameNode memory and create many short tasks. Fix it by combining files into larger ones using formats such as SequenceFile, Avro or Parquet, HAR archives, or by compacting regularly.
YARN questions show whether you understand Hadoop 2 and 3, and not just the old design.
YARN stands for Yet Another Resource Negotiator. It separates resource management from processing, so the cluster can run many kinds of applications, such as MapReduce, Spark and Tez, on the same data and hardware. In Hadoop 1 the JobTracker did both jobs, which limited scalability and locked the cluster to MapReduce.
The ResourceManager is the cluster wide authority that allocates resources among applications. A NodeManager runs on each worker, launches containers and reports usage. An ApplicationMaster is started for each application, negotiates containers from the ResourceManager and coordinates its tasks until the application finishes.
| Daemon | Scope | Job |
|---|---|---|
| ResourceManager | Whole cluster | Scheduling and resource allocation |
| NodeManager | One node | Runs containers, monitors resources |
| ApplicationMaster | One application | Requests containers and runs the job |
A container is an allocation of resources on one node, mainly memory and virtual cores, in which a task runs. The ResourceManager grants containers, and the NodeManager launches and monitors them. A container that uses more memory than it was given is killed.
YARN has three schedulers. The FIFO scheduler runs jobs in submission order and suits a single user. The Capacity scheduler divides the cluster into queues with guaranteed shares and is the usual choice in shared clusters. The Fair scheduler shares resources so that all running jobs get an equal share over time.
| Scheduler | Idea | Best for |
|---|---|---|
| FIFO | First in, first out | Small, single user clusters |
| Capacity | Queues with guaranteed capacity | Shared multi tenant clusters |
| Fair | Equal share over time | Mixed short and long jobs |
The client submits an application to the ResourceManager, which starts an ApplicationMaster in a container. The ApplicationMaster asks for more containers, the NodeManagers launch the tasks there, and the tasks report progress to the ApplicationMaster. When the work ends, the ApplicationMaster reports the result and its container is released.
Set the memory a NodeManager can give to containers, the minimum and maximum container sizes, and the memory for map and reduce tasks, then set the task Java heap to a bit under the container size. A heap larger than the container causes kills. Leave memory for the operating system, and watch for failures from memory use.
MapReduce is still asked about in most Hadoop interviews, even where Spark is used in practice. Be able to walk through the flow of a word count.
MapReduce is a programming model for processing data in parallel. In the map phase, each task reads an input split and emits key value pairs. The framework then shuffles and sorts these so all values for one key arrive together, and the reduce phase combines them into the final result. It is a batch model with disk writes between stages.
After map tasks emit pairs, an optional combiner reduces the output locally. A partitioner then decides which reducer gets each key, and the data is sorted by key and copied to the reducers, which is the shuffle. Reducers merge the sorted streams and group values by key before the reduce function runs.
A combiner is a local reducer that runs on the output of a map task to shrink the data sent across the network. It is safe only when the operation is commutative and associative, such as sum, count or maximum. An average cannot use the reducer as its combiner directly, because averaging averages gives a wrong answer.
A partitioner decides which reducer receives each map output key. The default hashes the key and takes the remainder when divided by the number of reducers, so equal keys always go to the same reducer. A custom partitioner is used to balance a skewed key or to send related keys together.
A block is the physical unit of storage in HDFS, and an input split is the logical chunk of data given to one map task. A split usually matches a block, but a split can respect record boundaries, so a record that crosses a block boundary is read in full. The number of splits sets the number of map tasks.
The number of mappers equals the number of input splits, which depends on the data size and the input format. The number of reducers is set by the developer, with a job setting, and is not chosen by the framework from the data. Too few reducers slow the job, and too many create small outputs and overhead.
Speculative execution starts a duplicate of a slow task on another node, and takes the result of whichever copy finishes first, killing the other. It protects a job from one slow machine, called a straggler. It can waste resources, so many teams turn it off for reducers that write to external systems.
The input format defines how input is split and how records are read. TextInputFormat reads lines, with the byte offset as the key. SequenceFileInputFormat reads binary key value files, and others read Avro, ORC or Parquet. The output format defines how results are written. Choose a splittable, compressed format for efficiency.
MapReduce writes the intermediate results of each stage to disk and reads them back, so a pipeline of many steps pays this cost repeatedly. Spark keeps data in memory between steps and builds a plan of the whole job, which makes iterative algorithms and interactive queries much faster. MapReduce remains stable for very large one pass batch jobs.
| Point | MapReduce | Spark |
|---|---|---|
| Intermediate data | Written to disk | Kept in memory where possible |
| Programming model | Map and reduce only | Rich operators and SQL |
| Iterative work | Slow | Fast |
| Streaming | Not supported | Structured Streaming |
| Typical use today | Legacy batch jobs | Most new analytics |
Know what each tool is for and which ones are still active.
Hive provides SQL on large data. Spark provides fast general processing. HBase is a wide column store on HDFS. Sqoop moves data between Hadoop and relational databases, though it has been retired. Kafka carries streaming data. Oozie and Airflow schedule workflows, and Ranger and Atlas handle security and metadata.
| Tool | Purpose | Status |
|---|---|---|
| Hive | SQL on large data | Active, version 4.x |
| Spark | Fast batch and streaming processing | Active, version 4.x |
| HBase | Random access wide column store | Active |
| Kafka | Event streaming | Active, version 4.x |
| Flume | Log collection | Dormant since 2024 |
| Sqoop | Database import and export | Retired, moved to the Apache Attic |
Hive is a data warehouse layer that turns SQL like queries into jobs on Tez or Spark and reads data stored in HDFS or object storage. It is built for large scans and batch analysis, with high latency, and not for fast row by row transactions. The schema is applied on read in many cases.
Sqoop transferred data between relational databases and Hadoop. The project was retired to the Apache Attic, so for new work use Spark JDBC reads, Kafka Connect or change data capture tools, and managed ingestion services. Mention Sqoop only to explain older pipelines.
Text files such as CSV and JSON are simple but large and slow. Avro is a row based binary format with a schema, good for ingestion. Parquet and ORC are column based formats with compression, which are best for analytics because queries read only the columns they need. SequenceFile is an older binary key value format.
| Format | Layout | Best for |
|---|---|---|
| CSV or JSON | Text rows | Simple exchange |
| Avro | Binary rows with schema | Ingestion and streaming |
| Parquet | Binary columns | Analytics, wide tables |
| ORC | Binary columns | Hive analytics |
Common codecs are gzip, which compresses well but is not splittable, Snappy, which is fast and used inside Parquet and ORC, bzip2, which is splittable but slow, and LZ4 and zstd. A splittable format lets several mappers read one file in parallel. A large plain gzip file is read by a single mapper.
Many companies now run the same engines on cloud object storage and managed services, such as Amazon EMR, Google Dataproc or Azure HDInsight, and keep data in S3, GCS or ADLS in place of HDFS. The skills carry over, since the engines are the same. HDFS remains common in on premise clusters.
These questions confirm that your knowledge goes past the Hadoop 2 era.
Erasure coding stores data with parity pieces instead of full copies, so it can rebuild lost data at a much lower storage cost. With the common Reed Solomon 6 plus 3 scheme, 6 data blocks and 3 parity blocks use 1.5 times the data size, against 3 times for triple replication. It suits cold data that is rarely read.
The trade off is that reads of damaged data and recovery cost more network and CPU, and some features, such as hflush, behave differently for erasure coded files.
Federation lets a cluster run several independent NameNodes, each managing a part of the namespace, while sharing the same pool of DataNodes. It scales the namespace beyond what one NameNode memory can hold and isolates workloads. Router based federation adds a unified view over several namespaces.
To add a node, install Hadoop, configure it, start the DataNode and NodeManager, and add it to the include file if used, then refresh the nodes. To remove one safely, add it to the exclude file and refresh, which decommissions it so that its blocks are copied elsewhere before shutdown. Then run the balancer to even the data.
Use Kerberos for strong authentication, and set file permissions and access control lists in HDFS. Use Apache Ranger or a similar tool for central authorisation, encrypt data in transit and use HDFS transparent encryption at rest with a key management server. Audit access, and keep the cluster on a private network.
Use the NameNode and ResourceManager web interfaces, the job history server and a monitoring system such as Ambari, Cloudera Manager or Prometheus with Grafana. Watch under replicated blocks, DataNode health, disk use, container failures and queue use. Read the daemon and container logs, and run fsck to check file health.
Explain your approach in steps, and name the command or tool you would use.
A single reducer is a bottleneck, because all map output funnels into it. Increase the number of reducers and check the partitioner for key skew, since one hot key can still send most data to one reducer. Add a combiner if the operation allows, and compress the map output to cut shuffle traffic.
First find out why, usually millions of small files. Compact them into larger files or formats such as Parquet, archive old data, delete unneeded files and raise the heap size as a short term step. For long term growth, use federation to split the namespace. Add monitoring on the object count.
After the heartbeat timeout, the NameNode marks the DataNode dead and starts copying the blocks it held from the other replicas to new nodes, so the replication factor returns to its target. Check the fsck report for under replicated and missing blocks, repair or replace the node and bring it back, then run the balancer.
Check the scheduler queue limits. Under the Capacity scheduler, a queue may have reached its maximum capacity or user limit even when other queues are idle. Check whether memory per container is set too high for the nodes, or whether the ApplicationMaster limit is reached. Adjust queue capacities or container sizes.
Inventory the data, jobs and dependencies. Copy data to object storage with DistCp or a transfer service, keep the formats such as Parquet, and run the same jobs on managed Spark or Hive. Replace HDFS paths and Kerberos with cloud storage paths and identity roles. Validate results in parallel, then cut over workload by workload.
What the interviewer is listening for: You plan in stages, validate results side by side and keep a rollback path.
Land the logs in object storage or HDFS in Parquet, using Kafka or a collector for ingestion, then process with Spark, which is faster than classic MapReduce. Partition the data by date, query with Hive or Spark SQL, and schedule with Airflow. Keep MapReduce only for existing jobs that already work.
Yes, in a changed role. Many companies still run Hadoop clusters, and the ideas of HDFS, YARN and distributed processing sit behind cloud data platforms. Newer projects often use Spark on object storage, so employers look for people who know both the Hadoop foundations and the modern tools.
Prepare HDFS architecture, block size and replication, YARN, the MapReduce flow and the Hadoop 3 changes first. Then Hive, Spark, file formats and scenario questions on small files and failures. Experienced roles add security, tuning and cloud migration.
Learn the 3.x line and know what changed from 2.x, mainly erasure coding and multiple standby NameNodes. Many older clusters still run 2.x, so understand the older design as well. Check the Apache release page for the latest version.
Not for most data roles. Hadoop is written in Java and MapReduce jobs are often written in Java, but you can use Hive, Spark with Python or Scala, and Hadoop streaming. Basic Java helps you read logs and understand configuration.
Run a single node or small multi node cluster in containers or virtual machines, load a dataset into HDFS, run a word count, and query it with Hive. Then break things on purpose by stopping a DataNode, and watch the replication recover.
Use this plan if you have about a month before your interview.
| Week | Focus | What to do |
|---|---|---|
| Week 1 | HDFS and basics | Set up a small cluster. Practise HDFS commands and explain blocks, replication and the NameNode aloud. |
| Week 2 | YARN and MapReduce | Run a word count, trace its flow, and study YARN daemons and schedulers. |
| Week 3 | Ecosystem and Hadoop 3 | Learn Hive, Spark, file formats, erasure coding, federation and security. |
| Week 4 | Scenarios | Practise the scenario questions and the cloud migration answer. |
If you want to practise these questions with a trainer and work on hands on projects, you can book a free demo class for the Prwatech Big Data course and Hadoop course. It covers HDFS, YARN, MapReduce, Hive, Spark and hands on projects.
Contact the learning team for current batch dates and fees.
Written by Mithun Ray, data engineering trainer at Prwatech. Reviewed by Avishekh Verma. Last updated October,2026.