Elasticsearch interview questions

The index and the analyzer

• What is an inverted index, and why does it make full-text search fast?
• What does an analyzer do? Character filters, a tokenizer, token filters - lowercasing, stemming, stop words.
• The classic bug: a query returns nothing because the field was indexed with a different analyzer than the query used. Mentioning `_analyze` to debug it is the strong answer.
• `text` versus `keyword` - analysed for search against exact for filtering, sorting and aggregating. Mapping a field wrong here is the most common Elasticsearch mistake.
• Can you change a mapping after the fact? Not for an existing field - you reindex, usually behind an alias.

Queries and relevance

• Query context versus filter context - filters are cacheable and do not score, which is why you put date ranges and term filters there.
• `match` versus `term` - and why `term` on an analysed field usually returns nothing.
• `bool` with must, should, must_not and filter.
• How is relevance scored, at a high level, and how would you tune it? Boosting fields, function scores.
• Why did this document not come back? Debug with `explain`.

Cluster, shards and performance

• Shards and replicas - what each is for, and why the primary shard count is fixed at index creation.
• What is over-sharding, and why is it a problem? Overhead per shard, which adds up badly.
• What happens when a node fails?
• Why is a search slow? Deep pagination, expensive aggregations, wildcard-leading queries, or unbalanced shards.
• Why is deep pagination expensive, and what do you use instead? `search_after`.
• Bulk indexing and refresh interval when loading large volumes.

When it is the wrong tool

Elasticsearch is a search and analytics engine, not a primary datastore - it has no transactions, and it should be populated from a system of record you can rebuild from. Candidates who treat it as a database are the ones this question is for. The broader data ground is in data engineer interview questions.

How deep it goes by level

• Junior: the fundamentals above, explained clearly. Nobody expects production scars yet, and saying what you have not done reads better than bluffing.
• Mid-level: the same ground plus an index you have designed and reindexed. Expect follow-ups asking why you made a choice rather than whether you know the syntax.
• Senior: cluster sizing, relevance tuning against real user behaviour, and a production search incident. The recall questions get shorter and the judgement questions get longer.

Whatever the level, say your answers out loud rather than reading them. Most of what candidates lose in a Elasticsearch interview is lost between knowing something and explaining it under observation - the method is in how to use AI for interview prep.

Where CoPilot Interview fits

Disclosure: we build an interview assistant, so treat this as a disclosed pitch. CoPilot Interview is a native Windows and macOS app that puts suggested answers on your own screen in about two seconds, across coding, system design and behavioral rounds, with a permanent free tier that needs no credit card.

Frequently asked questions

What are the most common Elasticsearch interview questions?

What an inverted index is, how analyzers transform text, the difference between `text` and `keyword` mappings, query versus filter context, shards and replicas, and diagnosing a slow search.

What is the difference between text and keyword in Elasticsearch?

`text` fields are analysed - tokenised, lowercased and stemmed - which makes them searchable as prose but unsuitable for exact matching, sorting or aggregation. `keyword` fields are stored verbatim for exact term queries, filtering and aggregations.

Why does my Elasticsearch query return no results?

Most often a mismatch between how the field was analysed at index time and how the query treats it - a `term` query against an analysed field is the classic case, since the stored tokens are lowercased or stemmed. Use the `_analyze` API to compare.

Should Elasticsearch be used as a primary database?

No. It lacks transactional guarantees and is designed as a search and analytics layer populated from a system of record. You should always be able to rebuild an index from the source of truth, which is why reindexing behind an alias is standard practice.