Elasticsearch interview questions: a step-by-step guide

Elasticsearch interview questions: a step-by-step guide

When you're preparing for a search engineering role or conducting interviews, the depth of your Elasticsearch knowledge often separates strong candidates from the rest. We've found that the best candidates don't just know the theory—they understand how indexing, mapping, and shard management impact real production systems. This guide walks through the core Elasticsearch interview questions we ask at senior level, with practical context for why each answer matters.

What is an inverted index?

The inverted index is the fundamental data structure that makes Elasticsearch fast. Instead of storing documents and then searching through them, an inverted index maps terms (words) to the documents that contain them. When you index a document, Elasticsearch tokenizes the content, normalizes the terms, and builds a lookup table: term → list of document IDs.

Let's say you index three documents:

• Doc 1: "The coffee is hot"
• Doc 2: "Coffee makes me happy"
• Doc 3: "Hot weather today"

The inverted index for the term "coffee" looks like: coffee → [1, 2]. When you search for "coffee", Elasticsearch doesn't scan all three documents—it looks up the term directly and returns documents 1 and 2 instantly.

In production, inverted indexes also store metadata about each term occurrence: position in the document, frequency, and offsets. This enables features like phrase queries and highlighting. A candidate who understands this rarely struggles with performance tuning, because they grasp why full-text search works the way it does.

One nuance: the inverted index is immutable once written to disk. This is why Elasticsearch uses segments—multiple small immutable inverted indexes that get merged over time. It's also why updates are actually delete-then-insert operations at the segment level.

Text vs keyword: analyzed full-text vs exact values

This distinction trips up many candidates, but it's critical for production systems. The text field type analyzes content during indexing and searching. The keyword field type stores exact values without analysis.

For a field like product description, use text:

{
  "description": {
    "type": "text",
    "analyzer": "standard"
  }
}

When you index "The coffee maker is hot", the standard analyzer tokenizes it into: ["the", "coffee", "maker", "is", "hot"]. A search for "coffee maker" matches because both terms are in the inverted index. A search for "COFFEE" also matches because the analyzer lowercases terms.

For a field like user ID or status, use keyword:

{
  "status": {
    "type": "keyword"
  }
}

If you index the value "pending-review", it stays as one token: ["pending-review"]. A search for "pending" doesn't match; you must search for the full exact value. This is what you want for statuses, tags, and IDs.

A practical rule: if you'd filter by it (status = "active"), use keyword. If you'd search across it with partial matches (product titles, descriptions), use text. Many candidates miss the performance implication: keyword fields are also faster for aggregations and sorting because they're not stored in an analyzed form.

How do you change a mapping?

Once a field is indexed with a specific type, you can't change its mapping directly in Elasticsearch. Many candidates don't realize this constraint until production when they need to add a new analyzer to an existing field. The solution is a three-step process: create a new index with the updated mapping, reindex data, and swap aliases.

Here's the workflow. Start with your current index structure:

{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "standard"
      }
    }
  }
}

You need to change the analyzer for title to something more sophisticated. Step one: create a new index with the updated mapping:

PUT /products_v2
{
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "english",
        "fields": {
          "raw": {
            "type": "keyword"
          }
        }
      }
    }
  }
}

Step two: reindex from the old index to the new one:

POST _reindex
{
  "source": {
    "index": "products"
  },
  "dest": {
    "index": "products_v2"
  }
}

Step three: update your alias to point to the new index:

POST _aliases
{
  "actions": [
    {
      "remove": {
        "index": "products",
        "alias": "products_live"
      }
    },
    {
      "add": {
        "index": "products_v2",
        "alias": "products_live"
      }
    }
  ]
}

Using aliases means your application queries always point to products_live, so the swap is transparent. This is how we handle mapping changes without downtime. Strong candidates understand that reindexing is expensive—it reads every document and re-ingests it—so planning mapping changes upfront saves operational pain.

How do you size shards?

Shard sizing is where theory meets pragmatism. The common guidance is 10–50 GB per shard, but that's a starting point, not a rule. The real constraint is query latency and heap pressure.

Why these limits? Each shard is a Lucene index that runs on a single node. When you search, Elasticsearch queries all relevant shards in parallel and merges results. If shards are too large (say, 500 GB each), queries become slow because a single shard has too much data to scan. If shards are too small (say, 1 GB each with 100 shards), you create overhead: more shards mean more coordination, more merge activity, and higher memory consumption.

In practice, we work backward from your data volume and query requirements. If you have 1 TB of data and want to keep query p99 under 500 ms, you might target 30 GB shards, resulting in roughly 33 shards. If you have 100 GB and mostly do heavy aggregations (not phrase searches), you might go with 20–30 GB per shard.

Here's a sizing formula we use: Total Data Size / Desired Shard Size = Number of Shards. But also consider the primary node's heap: each shard holds some metadata in memory, and too many shards can exhaust heap even if individual shard sizes are reasonable.

Oversharding is a common mistake. A candidate who says "I'll create 100 shards to parallelize everything" doesn't understand the tradeoff. More shards increase coordination overhead and GC pressure. A smaller number of appropriately sized shards often outperforms a swarm of tiny shards.

Also factor in growth. If your index grows 20% per month, plan your shard count to accommodate 6–12 months of growth before you need to re-shard. This is why aliases and index templates matter: they let you roll over to a new index with better shard configuration when needed.

Common mistakes

• Not using aliases for client code. Hardcoding index names makes rolling over to new indices painful. Always query through an alias so you can repoint it without touching your application.
• Analyzing fields you should leave as keyword. Status codes, IDs, and user tags don't need full-text analysis. Using keyword saves disk space and query time.
• Ignoring heap memory when planning shards. Too many shards cause excessive memory overhead. Monitor heap usage during load tests and size accordingly.
• Attempting to modify mappings in place. Candidates sometimes try to update a mapping and reindex in the same request. Elasticsearch won't allow it. Always create a new index.
• Not testing reindex performance before production. A large reindex can lock resources. Test on a staging cluster with realistic data volume first.

Key takeaways

• The inverted index is the core data structure: it maps terms to documents, enabling fast lookups. Understanding it helps you grasp why Elasticsearch works and how to optimize queries.
• Use text for full-text search (analyzed, partial matches), and keyword for exact values (filtering, sorting, IDs). This distinction impacts both correctness and performance.
• To change a mapping, create a new index with the updated mapping, reindex data, and swap aliases. This pattern is the only safe way to evolve your schema in production.
• Size shards to 10–50 GB as a baseline, adjusted for query latency and heap constraints. Avoid oversharding; fewer, larger shards are usually better than many tiny ones.
• Always use aliases for client queries, test reindex operations on staging, and plan for growth when setting initial shard counts.