InterviewGuide: a Spring Boot 4.1 and Spring AI 2.0 platform for resume analysis, mock interviews and RAG question banks

The problem InterviewGuide targets, and the audience it assumes

Interview preparation tooling usually splits into two unsatisfying halves. One half is a static question bank that cannot read a candidate's resume. The other half is a thin wrapper around a chat completion endpoint that scores an answer without any grounding documents. InterviewGuide attempts to close that gap in a single deployable application. The README describes it as an intelligent interview assistance platform integrating resume analysis, mock interviews in text and voice, interview scheduling, knowledge base management, knowledge-base question bank interviews, and multi-model configuration. The stated beneficiaries are job seekers, HR staff and training organisations. That list is worth reading carefully, because the three groups want different things. A job seeker wants practice and feedback. An HR user wants resume triage and scheduling. A training organisation wants a question bank it can curate. The repository attempts all three, which is why the surface area is large: resume parsing, calendar views, WebSocket voice, RAG chat and an evaluation engine all live in the same codebase. The design constraint behind that breadth is stated directly in the README's technology FAQ. The author chose PostgreSQL with pgvector partly because, in their words, they did not want to introduce too many components, and chose Redis Streams over Kafka for the same reason. That is a coherent position, but it means the project is opinionated about operational simplicity rather than about horizontal scale. If your organisation already runs Kafka and a dedicated vector database, InterviewGuide's choices will feel like a step backwards. If you are a single team deploying one stack, the consolidation is the point.

Architecture: one evaluation engine, two interview modes, Redis Streams in the middle

The mechanism that distinguishes InterviewGuide from a chat wrapper is the shared evaluation path. The README states that text interviews and voice interviews use the same evaluation engine, described as batched evaluation plus structured output plus a second aggregation pass plus a degradation fallback. That last clause matters more than the rest. A degradation fallback implies the maintainers expect structured LLM output to fail sometimes, and the design absorbs that failure rather than surfacing it as an error. The second architectural spine is asynchronous work over Redis Streams. Resume analysis, knowledge base vectorisation and mock interview report generation are all dispatched as stream tasks, and the README notes that this decoupling means analysis and vectorisation could be implemented in another programming language later. Resume analysis carries an explicit retry policy of up to three attempts and a duplicate check based on content hash, so re-uploading the same file does not queue a second identical job. Retrieval runs on pgvector with query rewriting, a similarity threshold and a TopK strategy, and answers stream to the browser over Server-Sent Events. Voice is the outlier. It uses WebSocket for bidirectional communication, with DashScope's Qwen3 ASR and TTS models behind a single API key, server-side voice activity detection for sentence segmentation, and sentence-level concurrent TTS so that generation, synthesis and playback overlap. The README claims a 200ms first-packet latency for that pipeline. Treat that figure as a design target reported by the project, not an independently measured number.

Getting it running: Gradle, Compose, and where configuration lands on disk

The build tool is Gradle 9.6.1, so the entry points are the Gradle wrapper rather than Maven goals. The README's technology table lists Spring Boot 4.1.0, Java 25, Spring AI 2.0.0, Spring AI Agent Utils 0.10.0, PostgreSQL 14 or later with pgvector (the Compose default is PostgreSQL 16), Redis 6 or later with Redisson 4.0.0, Apache Tika 2.9.2, iText 8.0.5, MapStruct 1.6.3 and SpringDoc OpenAPI 3.0.2. Object storage goes through the AWS S3 SDK 2.29.51 against an S3-compatible backend, which the README names as MinIO or RustFS. The frontend is React 18.3 with TypeScript 5.6, Vite 5.4, Tailwind CSS 4.1 and pnpm 10.26. A Docker quick-deploy item is checked off in the TODO list, so a Compose path is intended to exist, though the README excerpt provided here does not include the exact Compose command. Configuration is the part worth planning around. The README states that runtime configuration is written by default to the user directory under `~/.interview-guide/`, and that API key encryption is supported for that file. Multi-provider setup covers DashScope, LM Studio, Kimi, DeepSeek and GLM as OpenAI-compatible providers, with the default chat model and default embedding model switchable from the settings page instead of by editing source. That is a real operational improvement over projects that hardcode a provider, but it also means the settings file becomes a secret-bearing artifact that has to be backed up and access-controlled like any credential store.

Where the voice module falls short, according to the project's own README

The README contains a block explicitly labelled as known issues, and it is unusually candid. It lists high end-to-end latency caused by server-side audio relay, echo leakage when no headphones are used, a single TTS voice timbre, and choppy audio on weak networks. The planned directions are WebRTC, client-side VAD with noise reduction, and end-to-end speech models, all of which remain unchecked in the TODO list. The practical consequence is that the voice interview feature is best treated as a working prototype rather than a production channel. The server-side relay is the root cause of the latency complaint: audio travels to the server, gets processed, and travels back, so the floor on round-trip delay is set by the network path rather than by model inference alone. Echo leakage without headphones is a physical acoustics problem that software mitigation only partly solves. Anyone evaluating InterviewGuide for a call-centre style use case should stop here. The text interview path does not carry these caveats, and the shared evaluation engine means a text interview produces comparable scoring output without the audio constraints.

The knowledge base question bank and its capacity check

The knowledge base question bank is the most carefully specified module in the README, and the detail reveals a real design decision. Questions are generated from already-vectorised documents and carry a main question, a reference answer, key points, scoring criteria and follow-ups, organised by direction and difficulty. Generation is asynchronous over Redis Streams. The interesting part is what happens when generation underdelivers: the README states that when too few questions are produced, drafts are retained and the interface shows the actual follow-up count against the target follow-up count, so questions are not silently dropped. That is a small piece of interface honesty that many generation pipelines skip. The second notable mechanism is capacity validation. Before an interview starts, the system computes available capacity in real time from direction, difficulty, main question count and follow-up count per question. Follow-up count is described as a hard constraint: options with insufficient capacity are disabled in the interface, and the backend performs a fallback validation as well. This is the correct shape for this kind of feature, because a front-end-only check would let a crafted request start an interview with more follow-ups than the bank can supply. The cost is that question bank curation becomes load-bearing. If you archive or draft too many questions in a direction, the corresponding interview configuration simply becomes unavailable, and the README does not describe an automatic top-up path.

What a Spring AI based design gives up against a Python RAG stack

The obvious alternative for a team building this kind of system is a Python service using LangChain or LlamaIndex with FastAPI, paired with a dedicated vector store such as Qdrant or Milvus. The difference is not language preference, it is where the ecosystem sits. Python RAG tooling has a wider selection of retrievers, rerankers and evaluation harnesses available as libraries, and a dedicated vector database gives you index types and filtering that pgvector does not cover. InterviewGuide goes the other way deliberately: pgvector keeps relational data and embeddings in one database, so a query that filters candidates and ranks documents can be a single SQL statement, and Redis Streams avoid a second broker. Spring AI supplies the model abstraction layer, and Spring AI Agent Utils 0.10.0 handles Skill resource loading and Advisor extension. The Skill mechanism itself is a concrete differentiator: interview directions are defined by `SKILL.md` files, and the README says there are more than ten built-in directions including Java backend, company-specific tracks for Alibaba, ByteDance and Tencent, frontend, Python, algorithms, system design, test development and AI Agent, each declaring its scope, difficulty distribution and reference knowledge base. That is a file-based configuration format, which means adding a direction is a content change rather than a code change. A Python stack would more likely express the same thing as Python dictionaries or a database table. Neither is better in the abstract; the Java version is easier for a Java team to review and merge.

Licence, maintenance and upgrade exposure under AGPL-3.0

InterviewGuide is licensed under AGPL-3.0. The practical implication, stated plainly and without legal advice, is that AGPL-3.0 carries network copyleft: if you modify the software and let users interact with it over a network, the licence's source-availability obligation is generally understood to apply to those users. For an internal tool that a team runs for itself, that is usually not a practical concern. For a company that wants to host a modified InterviewGuide as a paid service, the obligation is the central question and needs a lawyer, not a README. The repository is not archived, and the most recent push recorded is 2026-08-14, so the project is active. No releases were retrieved, which means there is no tagged version to pin against; you would be tracking the default branch, `master`. That raises the maintenance cost in a way that is easy to underestimate. The stack is aggressive: Spring Boot 4.1.0, Java 25, Spring AI 2.0.0 and Gradle 9.6.1 are all recent major lines. Upgrading any one of them can force upgrades of the others, and Spring AI in particular has moved quickly between versions. The README also points to a paid companion tutorial, while stating that the project itself commits to full free open source with no Pro tier or paid unlock of core features. That separation is stated clearly, and the code is the thing you are evaluating. Budget for the upgrade treadmill rather than assuming the pinned versions will hold.

Editorial conclusion

Adopt InterviewGuide if you want a self-hosted Java codebase that already wires resume parsing, asynchronous LLM evaluation and pgvector retrieval into one application, and if you are willing to run PostgreSQL with pgvector, Redis and an S3-compatible store. Do not adopt it if you need low-latency voice interaction today, because the README itself flags end-to-end delay, echo leakage without headphones and single-tone TTS as unresolved. Before committing, verify three things against the repository: that Spring Boot 4.1.0 and Spring AI 2.0.0 resolve from your artifact repositories, that your PostgreSQL image ships pgvector, and that the AGPL-3.0 network-copyleft terms are acceptable for how you plan to expose the service.

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. Snailclimb/interview-guide on GitHub