DEV Community: Vignan Nallani

I gave an AI a memory of my interview history — here's what I learned building on Cognee

Vignan Nallani — Tue, 30 Jun 2026 07:08:26 +0000

I gave an AI a memory of my interview history — here's what I learned building on Cognee

Every time I've used an AI to prep for interviews, it forgets me the second I close the tab. I paste my resume, it gives me the same advice it gives everyone, and the next session starts from zero. For something that's supposed to help me improve over time, that amnesia is the whole problem.

So for the Hangover Part AI: Where's My Context? hackathon, I built Interview Memory Coach — an AI coach that builds a permanent, structured memory of your resume, your target role, and every past interview where you struggled, then coaches you against your actual gaps instead of generic tips. It runs on Cognee, an open-source memory layer for AI agents.

This is the story of building it: what worked, the bugs that didn't, and what I learned about giving an AI a memory that actually persists.

The core idea: graph-grounded, not just retrieved

Most "AI with memory" projects are really just RAG — you embed some text, retrieve the nearest chunks, and hope the LLM stitches them into something coherent. That works until the answer depends on relationships between facts rather than the facts themselves.

Interview coaching is exactly that kind of problem. "How should I prepare for system design?" shouldn't return textbook advice — it should connect this candidate to their past failures to the role they're targeting. That's a graph traversal, not a similarity search.

Cognee's GRAPH_COMPLETION search does this in one call: it walks a knowledge graph built from your data and synthesizes an answer grounded in connected facts. When my test candidate Jane asks about system design, the coach doesn't recite fundamentals — it says:

"You've struggled with system design in past interviews — you were asked to design a URL shortener at 10M req/day, proposed SQLite, and admitted you couldn't handle distributed scale. The senior role you're targeting requires exactly this."

That specificity is the entire point. And it only works because Cognee turned her resume and interview notes into a graph where Jane → system design → distributed databases → url shortener are connected nodes, not loose text.

Using the full memory lifecycle

Cognee's memory isn't just store-and-retrieve. It has four operations — remember, recall, improve, forget — and I wanted to use all of them meaningfully, not just check boxes:

remember — ingest the resume, job description, and past Q&A; cognify extracts the graph.
recall — GRAPH_COMPLETION traverses the graph to answer a coaching question.
improve — an enrichment pass (memify) that deepens the stored graph.
forget — wipe stale interview history so it stops polluting coaching.

Getting each of these to behave for a fast, free-tier, single-user demo is where the real engineering happened. Here are the three problems that taught me the most.

Bug 1: the 8B model that couldn't follow a schema

To keep costs at zero, I started with a two-model setup: a small, fast model (llama-3.1-8b-instant via Groq) for graph extraction, and a larger one (llama-3.3-70b-versatile) for the actual coaching answers. Cheap extraction, quality answers — sensible split.

Except ingest kept crashing. The error trace showed the 8B model was producing KnowledgeGraph JSON that violated Cognee's schema — nodes missing their required description field. Cognee retried, the retries also came back malformed, and the whole pipeline died.

The fix taught me something about matching model size to task constraints: strict structured output is hard for small models, and no amount of retrying fixes a model that can't reliably hit a schema. Since ingest only runs once (the sample pre-loads at startup), I moved extraction to the 70B model too. The cost is trivial for a one-time call, the crashes vanished — and as a bonus, the richer model produced a denser graph (12 nodes became 20). Sometimes the "expensive" choice is the right one once you realize how rarely the call actually fires.

Bug 2: the coach that wouldn't answer twice

Early on, asking the same question twice produced a bizarre result: the second time, instead of coaching, the app replied "I'll wait for further clarification." It had decided it already answered.

This one took some digging. Cognee's search() has a session_id parameter that defaults to 'default_session' — so every question I asked landed in the same conversation session. Cognee, reasonably, treated my repeated question as a continuation of an ongoing chat and short-circuited rather than re-answering.

The fix was to pass a fresh uuid.uuid4() as the session_id on every coaching call, plus setting CACHING=false. Now each question is an independent, stateless query — exactly what a coaching tool wants. The lesson: a default that's perfect for a multi-turn agent (session continuity) is wrong for a stateless Q&A tool, and knowing why the default exists made the fix obvious instead of a guess.

Bug 3: the forget() that didn't forget

This was the sneakiest. I'd call cognee.forget(dataset="session"), it would return success — and then recall would still answer with the supposedly-forgotten data. A silent failure: the kind that looks fine in a demo right up until a judge clicks the button and watches it lie.

The root cause was a genuinely subtle interaction. For single-user local mode, you disable access control (ENABLE_BACKEND_ACCESS_CONTROL=false). But with access control off, GRAPH_COMPLETION becomes a global graph traversal — it doesn't filter by dataset. So deleting one dataset's nodes left residual nodes that the global search still happily found.

For a single-dataset demo, the reliable answer was a full prune_system wipe — which, since the app only ever holds one session, is functionally equivalent to forgetting that session. (True multi-dataset surgical forget would mean enabling access control and scoping searches per user — the production path, which I noted but didn't need.) What I appreciated here is that Cognee gave me enough visibility into its own internals to actually find this, rather than just shrugging at a black box.

What I think about Cognee after building on it

Honestly? It's a genuinely powerful piece of infrastructure, and the graph-vector hybrid is the real deal — being able to traverse a knowledge graph and fall back to semantic search, in one call, is exactly what "AI memory" should mean. The lifecycle API (remember/recall/improve/forget) is a clean mental model for something that's usually a tangle.

The rough edges I hit — the schema strictness, the session defaults, the dataset-scoping behavior — weren't bugs so much as behaviors I had to understand. And the fact that I could understand them (open source, readable internals, real error messages) is the difference between a tool you fight and a tool you learn. I'd reach for it again.

The takeaway

The build is fully self-hosted — SQLite, LanceDB, an embedded graph store, local CPU embeddings, and Groq's free tier for the LLM. No data leaves the machine, and it costs nothing to run.

But the part I'm keeping isn't the stack — it's the reframe. "AI memory" isn't a vector store with extra steps. It's a graph of what the system knows about you, that can grow, deepen, and be deliberately forgotten. Once interview prep remembers your actual history, it stops giving you everyone's advice and starts giving you yours.

Code's here: github.com/VignanNallani/interview-memory-coach

Built for the Hangover Part AI hackathon. This project was built with AI coding assistants for implementation; all architecture and debugging decisions were mine, and I can defend every one.

An infinite loop hiding in a string search: debugging objectIsQueried in KubeStellar

Vignan Nallani — Fri, 26 Jun 2026 07:27:15 +0000

Some bugs crash loudly. The more interesting ones just hang — no panic, no error, no stack trace, just a goroutine quietly spinning forever on input that looks completely ordinary. I ran into one of those recently while reading through KubeStellar, a CNCF Sandbox project for multi-cluster configuration management. Here's the hunt, the root cause, and the one-character-deep mistake that caused it.

What the function was supposed to do

Deep in KubeStellar's status-combination code (pkg/status/combinedstatus-resolution.go) there's a small helper called objectIsQueried. Its job is simple: given a query string and an object name, decide whether the object appears in the query as a whole word — not as a fragment buried inside a longer identifier. So "foo" should match "select foo from bar" but not "foobar".

To do that, it walks the string looking for each occurrence of the object, and for each one asks a second helper, isWholeWord, whether that position is bounded by non-alphanumeric characters. Reasonable design. Here's the original loop:

func objectIsQueried(query *string, obj string) bool {
    idx := 0

    for {
        idx = strings.Index((*query)[idx:], obj) // search from idx onward
        if idx == -1 {
            return false
        }

        if isWholeWord(query, idx, len(obj)) {
            return true
        }

        idx += len(obj)
    }
}

Read it quickly and it looks fine. That's exactly what made it dangerous.

The trap: relative vs. absolute indices

The bug lives entirely in one line:

idx = strings.Index((*query)[idx:], obj)

strings.Index returns the offset of obj relative to the slice it was given — and the slice here is (*query)[idx:], not the whole string. But the code then turns around and uses that relative offset as if it were an absolute position in the original query, both when calling isWholeWord(query, idx, ...) and when advancing idx += len(obj).

As long as the first match happens to sit at the start of the string, relative and absolute agree, and everything works. The moment the search slice starts somewhere in the middle, the two diverge — and the loop starts using a wrong index that points back into territory it already searched.

Watching it spin

The clearest way to see the failure is to trace the input query = "foobar foo", obj = "foo":

idx = 0. strings.Index("foobar foo", "foo") → 0. isWholeWord at position 0? The character after "foo" is b — alphanumeric — so it's embedded in "foobar", not a whole word. false. Advance: idx += 3 → idx = 3.
idx = 3. Now we search the slice "bar foo". strings.Index("bar foo", "foo") → 4 relative to that slice. The code stores 4 as if it were absolute. isWholeWord at absolute position 4 is wrong, returns false. Advance: idx += 3 → idx = 7.
idx = 7. Search the slice "foo". strings.Index("foo", "foo") → 0 relative. Stored as absolute 0. We're back to checking "foobar" again. false. Advance → idx = 3.

And we're looping: 3 → 7 → 3 → 7, forever. The function never returns. The exact trigger is "the first occurrence of the object is embedded in a longer word, and a later occurrence is standalone" — an input that's not exotic at all once real query strings are involved.

The fix

The fix is to keep the two notions of position separate: a base that tracks where the current search slice begins in absolute terms, and a rel that's the relative result from strings.Index. The absolute position is just base + rel.

func objectIsQueried(query *string, obj string) bool {
    base := 0

    for {
        // strings.Index returns a relative offset within (*query)[base:], so we
        // must add base to get the absolute position before passing it to
        // isWholeWord (which operates on the original string).
        rel := strings.Index((*query)[base:], obj)
        if rel == -1 {
            return false
        }

        abs := base + rel
        if isWholeWord(query, abs, len(obj)) {
            return true
        }

        base = abs + len(obj)
    }
}

Nine lines changed, five removed. The slice-based search is still efficient (slicing a string in Go shares the underlying storage — no copy), but now every index handed to isWholeWord is a true absolute position, and base only ever moves forward. No more oscillation.

Pinning it with a regression test

A fix you can't prove is a fix you'll lose. The change that actually matters long-term is the regression test, which encodes the exact input that used to hang so nobody can quietly reintroduce the bug later:

// Key regression case: first occurrence embedded, second standalone.
// The original code looped forever on this input.
{"foobar foo", "foo", true},

alongside the ordinary cases ("foo" in "select foo from bar" → true, "foobar" → false, punctuation boundaries like "(foo)" → true, empty query → false), plus a separate table-driven test for isWholeWord itself. The point isn't coverage for its own sake — it's that the one input that broke the function is now a named, permanent test case.

Three things I took away

When you slice before searching, every offset is relative. strings.Index(s[base:], x) does not return a position in s. This is the kind of mistake that's invisible on a quick read and obvious the moment you trace a concrete input — which is the whole argument for tracing concrete inputs.
A hang is a bug, even without a crash. No panic fired here. The only symptom would be a wedged goroutine. Code that loops on an external Index result should always have a strictly-monotonic advance you can point to — here, proving base always increases is the proof the loop terminates.
Reading unfamiliar code is a skill worth practicing in public. I found this by reading, not by hitting it in production. Open source is one of the few places you can do that on a real, used codebase and have your fix reviewed by people who maintain it.

The fix is up as a proposed change against KubeStellar — issue #3848 for the report, PR #3849 for the fix and tests. If you spend time in Go codebases, the relative-vs-absolute slice trap is worth keeping in your peripheral vision; it hides well.

Written by Vignan Nallani. Found a bug like this, or want to talk through how you'd have traced it differently? I'm always up for it.