Real NLP interview questions & answers

Sir, first I will understand the task, and then build a preprocessing pipeline for that task. Typical steps — remove or normalize HTML, URLs and special characters. Handle punctuation and numbers based on whether they are useful. Normalize case if it makes sense. Tokenize. Handle spelling variations, contractions and abbreviations if needed. Apply stemming or lemmatization when it helps. Remove stopwords only when they are not useful. And finally convert the text into numbers — TF-IDF, n-grams or embeddings. The main point is, I will not blindly remove every number, punctuation mark or stopword, because they can carry useful information.

Yes sir, definitely. For example — "5 years experience," "20 percent discount," "2026 internship," "COVID-19," or in product reviews, "iPhone 17 Pro worth 5 star." Removing all numbers can remove important signals. So I check if the numbers have meaning, and then either keep them, normalize them, replace them with a special token, or remove them only when they are really irrelevant.

Yes. Instead of blindly using a regex that keeps only a to z, I decide what to keep based on the task. Things like COVID-19, 20 percent, rupees 999, C plus plus, or Python 3.12 carry meaning. So it's better to selectively normalize the unwanted characters and keep the meaningful tokens.

Stemming is faster and simpler — it uses rules to cut words to a root-like form. Lemmatization returns a proper dictionary base form, using more linguistic information. For example, "studies" becomes "studi" with stemming, but "study" with lemmatization. I choose based on the task, data size, accuracy needs and compute limits.

When we need a meaningful base word — like "better" to "good," "studies" to "study," "running" to "run." Stemming can create words that don't exist. But for very large text classification where speed matters, stemming is still useful.

Again, not by removing everything. In sentiment analysis, "Great!!!" — the exclamation marks show strong sentiment. In product reviews, "rupees 999," "5-star," "20 percent" may be important. For unidecode errors, I first check the source text and its encoding. Make sure the input is in the expected Unicode encoding, normalize Unicode if needed, handle malformed characters, transliterate only when it is appropriate, and validate the output. I avoid silently converting every character, because in multilingual text that can destroy information.

Traditional ones — one-hot encoding, bag of words, TF-IDF and n-grams. Dense ones — Word2Vec, GloVe, FastText, sentence embeddings and transformer embeddings. The choice depends on the problem, data size, how much meaning we need, and the model.

They are good baselines. Bag of words uses word counts. TF-IDF weights words by how important they are in a document compared to the whole corpus. N-grams capture word sequences — for "I love NLP," the bigrams are "I love" and "love NLP." I compare them experimentally with the same train-validation setup and the same metrics, instead of assuming one is always best.

It shows the relationship between terms and documents. Usually rows are terms, columns are documents, and the values are counts or a weight like TF-IDF. For example, the word "NLP" appears 2 times in doc 1 and 1 time in doc 2. It gives a numeric representation that traditional ML models can use.

If we represent a sentence by averaging all its word vectors, we lose word order, sentence structure, token-level context, and which words are important. For example, "dog bites man" and "man bites dog" can give almost the same average vector. Better options are TF-IDF-weighted embeddings, RNN or LSTM, CNN, transformer encoders, or sentence transformer models.

Word embeddings represent words as dense vectors of numbers. They are learned so that words used in similar contexts get similar vectors — like king and queen, or doctor and hospital. Unlike one-hot vectors, embeddings capture relationships between words.

Word2Vec is a neural method to learn word embeddings from context. It has two architectures. CBOW — continuous bag of words — predicts the target word from the surrounding words. For "the cat blank on the mat," it predicts "sat." Skip-gram does the opposite — it takes the target word and predicts the nearby words. For the target "cat," it predicts words like "the" and "sat." So CBOW is context to target, and skip-gram is target to context. CBOW usually trains faster, and skip-gram is better for rare words, because it creates more training examples from each word.

It depends on the domain. Pretrained embeddings are trained on huge corpora, so they help when my dataset is small. Training on my own data captures domain-specific words and usage, which helps with specialized terminology. So pretrained is not always better — it depends on domain similarity, corpus size, vocabulary and the task. I evaluate both and compare on validation performance.

Both give dense word vectors, but they train differently. Word2Vec learns through prediction tasks — CBOW and skip-gram — using local context. GloVe uses global word co-occurrence statistics across the whole corpus. Simple summary — Word2Vec is predictive and context-based, GloVe is based on global co-occurrence.

I start with TF-IDF features and compare models like logistic regression, Naive Bayes and SVM. For an imbalanced problem, I don't rely only on accuracy. I look at precision, recall, F1-score, the confusion matrix and class-wise performance.

First I measure the class distribution. Then options like class weights, oversampling, undersampling, data augmentation and threshold adjustment. And I evaluate with metrics suited for imbalance — precision, recall, F1 and PR-AUC — and check each class separately.

Step by step — data quality, label quality, class imbalance, preprocessing, feature engineering, the representation, the model, hyperparameters, and then error analysis. I look at the false positives and false negatives to understand why the model is failing.

Maybe, but not automatically. It helps when we have enough data, when the task depends on complex context, and when traditional features are not enough. Options are CNN, RNN, LSTM or transformers. But I always compare against a strong classical baseline first.

An RNN processes a sequence one token at a time and keeps a hidden state that carries information from previous tokens. That's why it suits sequential data. The problems are vanishing and exploding gradients, difficulty learning long-term dependencies, and it's sequential, so it's slow to train.

Yes, partly. Gradient clipping for exploding gradients, better weight initialization, the right activation functions, gating mechanisms, and truncated backpropagation through time. But for long-term dependencies, LSTM, GRU or transformers are usually more practical.

LSTM is long short-term memory. It has a forget gate, an input gate, an output gate, a cell state and a hidden state. The gates decide what information to forget, what to store and what to expose. This reduces the long-term dependency problem of a normal RNN.

Transformers use attention instead of recurrence. The flow is — input tokens become token embeddings, we add positional information, then self-attention, then a feed-forward network, and this is repeated in many layers to get the output representation. Because there is no recurrence, it can process tokens in parallel, which is much faster than RNNs.

Self-attention lets each token decide how much attention to give to every other token in the sequence. It uses query, key and value, and the formula is softmax of Q K transpose divided by square root of d k, multiplied by V. This builds contextual representations. Multi-head attention runs several attention heads in parallel. Each head can learn a different type of relationship. Then the outputs are concatenated and passed through a linear projection.

Transformers don't process tokens one by one like RNNs, so they don't naturally know the word order. But "dog bites man" and "man bites dog" mean different things. Positional information tells the model where each token is, so it can understand the order.

Token embeddings, positional information, multi-head attention, feed-forward network, residual connections and layer normalization. The encoder builds contextual representations of the input — like in BERT. The decoder generates tokens one by one — like in GPT-style models. And encoder-decoder models use the encoder to read the input and the decoder to generate the output, for sequence-to-sequence tasks.

In autoregressive generation, the decoder uses a causal mask, so a token cannot see future tokens. For example, in "I love machine learning," when predicting "machine," the model can use "I love," but not "learning." This prevents information leaking from the future during training.

They predict the next token based on the previous tokens. Input "I love," prediction "machine." Then "I love machine," prediction "learning." It continues token by token. Decoder-only transformers commonly use this.

Models that produce dense vectors for full sentences or longer text. They are used for semantic similarity, semantic search, clustering, retrieval and duplicate detection. For example, "I bought a car" and "I purchased an automobile" get similar embeddings even though the words are different.

The complete pipeline — parsing, chunking, embedding, a vector or hybrid index, retrieval, optional reranking, context construction, the LLM and the answer. And the design choices — chunk size and overlap, the embedding model, retrieval strategy, top-K, metadata filtering, reranking, context limits, citations and grounding, evaluation, latency and cost.

User query, then query preprocessing, then candidate retrieval using keyword search like BM25 and vector search, then optional reranking, then the top results. For semantic search, embeddings find documents by meaning, not just exact words. In production, I combine keyword and vector search.

Understand the business goal, inspect and label the data, explore it, check the class distribution, clean and preprocess, engineer features, split the data correctly, build a baseline, compare TF-IDF, n-grams and embeddings, train multiple models, evaluate with the right metrics, do error analysis, tune the best one, deploy, and then monitor and retrain. The important thing is explaining why I made each decision.

Words like "the," "is," "a" appear in almost every document, so for tasks like topic classification they add little value. Removing them reduces vocabulary size. But we should not always remove them. The classic example is negation. "The movie was not good at all" — after naive stopword removal, it can become "movie good," which is the opposite meaning. So for sentiment analysis, question answering or anything with transformers, I usually keep them. And whatever preprocessing I do in training, I apply exactly the same at inference, so there is no mismatch.