README.md

metadata

title: InterviewForge
emoji: 💻
colorFrom: yellow
colorTo: blue
sdk: gradio
sdk_version: 6.17.3
python_version: '3.13'
app_file: app.py
pinned: false

Exploratory Data Analysis (EDA) & Dataset Details

Please note that the comprehensive Exploratory Data Analysis (EDA)—including data quality checks, distribution analysis, and the full dataset card—is hosted in a separate dataset repository to keep this application space clean and focused.

You can explore the complete EDA and access the raw dataset in the README at: 🔗 Davichick/InterviewForge_GenDS

1. Embedding Model Selection

To power the retrieval engine, I evaluated three open-source, 384-dimensional sentence-embedding models from Hugging Face: all-MiniLM-L6-v2, BAAI/bge-small-en-v1.5, and intfloat/e5-small-v2. The evaluation ran on a random sample of 2,500 questions and measured three things:

1. Encoding speed — how long it takes to embed the sample.
2. Semantic separability — Silhouette Score (cosine) of the embedding space against the 16 true question categories.
3. Retrieval quality — Precision@1, Precision@5, and Mean Reciprocal Rank (MRR), where a retrieved question counts as relevant if it belongs to the same category as the query.

One implementation detail worth noting: e5-small-v2 is an asymmetric retrieval model and requires a query: prefix on queries and a passage: prefix on documents — without them its performance collapses. These prefixes were applied throughout the evaluation and the application.

Observations:

• Speed: all-MiniLM-L6-v2 was by far the fastest (28s for 2,500 questions), while e5-small-v2 was the slowest (84s, roughly 3× longer).
• Semantic separability: all three silhouette scores were slightly negative — expected, since interview categories share a great deal of vocabulary and overlap heavily in meaning — but e5-small-v2 scored best (−0.033), ahead of bge-small-en-v1.5 (−0.040) and all-MiniLM-L6-v2 (−0.046).
• Retrieval: e5-small-v2 won on all three metrics: Precision@1 = 0.18, Precision@5 = 0.16, MRR = 0.30. Interestingly, all-MiniLM-L6-v2 came second (P@1 = 0.16, MRR = 0.28) and bge-small-en-v1.5 last (P@1 = 0.15, MRR = 0.26), so raw model size was not the deciding factor. For context, these are strict proxy metrics — a match counts only if the retrieved question shares the exact category — and with 16 categories a random ranker would score P@1 ≈ 0.06, so the winner performs roughly 3× better than chance.

Conclusion: intfloat/e5-small-v2 won both quality evaluations (separability and retrieval), so despite being the slowest of the three, it was selected as the core embedding model. All 20,444 questions were then encoded with the passage: prefix, L2-normalized, and saved as an .npy vector store that the application loads at startup.

---

2. Embeddings Analysis & Clustering

To validate that the chosen model organizes the interview domain in a meaningful way, the embedding space was analyzed with three complementary techniques: K-Means clustering with the Elbow Method, t-SNE projection, and hierarchical clustering.

K-Means & the Elbow Method

For each of the three candidate models, K-Means was fitted for K = 2 to 15 and the inertia (sum of squared distances) was plotted. The curves decline smoothly without a sharp elbow — another sign that interview questions form a continuum rather than isolated islands — but the bend suggested a different natural granularity per model: K = 10 for MiniLM, K = 8 for BGE, and K = 6 for E5. Each model was then re-clustered at its own optimal K and projected to 2D (TruncatedSVD) for visual comparison:

The E5 map shows the cleanest macro-structure: even at the smallest K, its clusters occupy distinct, coherent regions of the projection instead of interleaving.

t-SNE Projection (True Categories)

To check how well each embedding space respects the true labels, the five most frequent question categories were projected with t-SNE (a non-linear method better suited to deep embeddings than PCA) and colored by their real category. As expected from the silhouette analysis, the categories are not linearly separable in any of the three spaces — interview questions genuinely blend topics (a "Coding & Problem Solving" question in FinTech shares vocabulary with "Tools & Frameworks"). However, clear local neighborhood structure is visible, and it is strongest in the E5 panel (right): "Prioritization Under Pressure" concentrates into a dense central region and "Tools & Frameworks" forms distinct pockets. This local coherence is exactly what a nearest-neighbor retrieval engine relies on, and it is consistent with E5 winning the Precision/MRR comparison.

Hierarchical Semantic Taxonomy

Finally, a mean (centroid) embedding was computed for each of the 16 question categories, L2-normalized, and clustered hierarchically using Ward's linkage. The category labels only define the 16 groups — the relationships between them are discovered purely from the geometry of the embedding space. The resulting dendrogram organizes the interview domain into three interpretable branches:

1. Behavioral & HR: "Culture Fit & Values", "Salary & Expectations", "Communication & Soft Skills", and "Business Impact & Metrics" merge together at low distance.
2. Core Engineering: "Coding & Problem Solving", "System Design & Architecture", "Scalability & Growth Planning", and "Innovation & Emerging Tech" form a distinct technical branch. Notably, "Motivation & Career Goals" attaches to this branch via "Tools & Frameworks" — the model apparently associates career-growth questions with technology-stack questions, a genuinely surprising discovery.
3. Operational & Situational: "Incident Response & Ownership", "Prioritization Under Pressure", "Collaboration & Cross-Team Work", and "Conflict Resolution" cluster together with "Debugging & Troubleshooting" and "Technical Roadmap & Strategy" — the "how do you act under real conditions" side of interviewing.

The fact that this taxonomy matches how humans intuitively divide interviews — HR vs. hard skills vs. situational behavior — without ever being told those relationships confirms that the retrieval system operates in a semantically structured vector space.

---

3. Recommendation System (How it Works)

The application utilizes a Vector-Based Retrieval strategy to recommend the most relevant interview question to the user based on their specific configuration.

The Pipeline:

1. User Configuration: The user selects their desired parameters via the UI: Role, Sector, Interviewer Persona, Category, and Difficulty Level.
2. Dynamic Query Generation: The application concatenates these parameters into a structured text query string.
3. Query Embedding: The input query is passed through the selected e5-small-v2 model, converting it into a 384-dimensional query vector.
4. Vector Similarity Search: The system computes the Cosine Similarity between the user's query vector and the pre-computed question embeddings database.
5. Retrieval: The system identifies the vector with the highest similarity score (argmax) and retrieves the exact matching interview scenario.

4. Dual-Model Architecture: Retrieval vs. Evaluation

• Model 1: The Retrieval Engine (intfloat/e5-small-v2) When the interview begins, this embedding model handles the search. It translates the user's specific configuration into a 384-dimensional vector and searches the 20,444-question database to fetch the exact, context-aware question. It does not generate new text; it retrieves the best existing scenario.

• Model 2: The Evaluation Engine (Qwen/Qwen2.5-1.5B-Instruct) Once the user submits their answer to the question, a completely different Generative AI (LLM) takes over. This model acts as the "Interviewer." It analyzes the candidate's specific response against the original question and generates a personalized, structured evaluation. The output includes a numeric Grade, highlighted Pros and Cons, and a concrete Example of how to answer it better.

Why this matters: This separation of concerns ensures the application is highly efficient. It uses aמ embedding model for the heavy lifting of searching through thousands of records, while reserving the deeper, more computationally expensive Generative LLM exclusively for providing human-like, nuanced feedback.