DEV Community: Kanishaka Pranjal

The Other Side of the Table: What 10 Developer Interviews Taught Me About the AI Gap

Kanishaka Pranjal — Thu, 17 Sep 2026 11:51:15 +0000

A year ago I was the candidate. I hijacked my own intro call at WeAssist.io, shared my screen, and demoed FableWeaver until they hired me in 30 minutes.

I was recently promoted to Dev Team Lead at WeAssist.io, on top of my founding engineer role on WorkStackOS. The first thing the new title handed me was the other side of the table. We needed developer interns for WorkStackOS, and I was now the person asking the technical questions.

Between August 27 and September 1, I ran 10 technical interviews alongside our operations manager. Forty minutes each: 30 for the interview, 10 for the debrief. Some started at 4:30 AM my time.

After the very first one, once the candidate had left the call, I asked our operations manager: "I was not rude, right?" It was my first time interviewing anyone. I had been firing questions fast and could not tell if that was leadership or nerves.

By the tenth interview, I had a script, a scoring habit, and one uncomfortable conclusion. Most candidates are not ready for what AI-first companies are actually hiring for. Their AI knowledge is thin, and their personal projects fall apart the moment I open a private browser tab.

Here is what I saw. No names, because none of this is about a person. It is about a pattern.

The Script I Ended Up With

By day three the interview had a shape:

Share your screen and open GitHub. Contribution graph, switch the years. Open your best repo. Click on the commits. Scroll slowly.
Live demo. Not a recorded video. If it is not deployed, run it locally.
I try to break it. Open a private tab, log in with the same account, check if the cart is still there. Submit a one-character password. Click the terms and conditions link. "So I can use anyone's email to create an account, right?"
Rate yourself 0 to 10 in agentic AI. Then I test the number. What is a tool? What is an agent? Do you know RAG? What are evals?
The novel problem. 100,000 documents. 50,000 are chapters of one interconnected book series. 50,000 are random. Build an assistant that knows chapter 2 matters in chapter 100. How?
The reading test. I paste a link to a GraphRAG doc and say: read it, then answer again. Close your eyes if you need to think.
The twist. Now the app has a dashboard with live data from a database. Users should talk to an assistant instead of clicking through the UI. What changes?
Core values.

Step 7 has a one-sentence answer. Give the model a tool that calls the API. Almost nobody said it without a hint.

Pattern 1: The Self-Rating Collapse

"How confident are you in agentic AI, 0 to 10?" was the most useful question I asked all week, because the follow-up is where the number goes to die.

One candidate with 11 months of professional experience and "AI" on every line of the resume rated himself 8.9. His first reaction to the phrase "agentic AI" had been: "The vibe coding you are telling?" Then: "Using AI means using the integrated IDE?" When I asked whether he knew tools, MCP, agents, and agent frameworks, the answer was no. By the end of the section he re-rated himself: "I will rate myself now 6 because the basic flows I don't know."

Another rated himself 7 to 8 because "I can give very good prompt." When I clarified that I meant tool calling and MCP, he said: "Sir, I am new. I am new. So I will rate myself around 2."

One candidate told me MCP stands for "model context processor."

One candidate, asked about RAG, said he had not gone through deep learning and machine learning yet. RAG is not deep learning. It is a retrieval pipeline you can build in an afternoon.

One candidate had three AI projects on the resume and a document-chat app built on Qdrant. Asked about evals: "Eval means evaluation of RAG or something, means I don't get it." Two minutes earlier he had told me "we have to evaluate the RAG."

And the resume with AI everywhere? When I asked how the AI actually helped the automation, the honest answer was: it checks whether login succeeded by reading the DOM, and it extracts a CSS selector when the hard-coded ones fail. That is a fallback, not an AI system.

Pattern 2: Everything Is RAG

The live-data twist exposed the same reflex in almost everyone. The app has a dashboard, the data changes every minute, and the user wants to ask the assistant about their pending orders.

The answers I got, across the twist and the novel problem before it:

"Build a Graph RAG of the pages and the data on the pages and provide that to our chatbot."
"Can we keep updating the Graph RAG?"
"As soon as a change occurs in data, we can log that change in our vector Graph RAG."
"Load the page and save it in chunks, and then we can train the model on it." That one confuses retrieval with training.
"Due to RAG, it doesn't hallucinate."

RAG has become the hammer, and every problem looks like a document. Nobody thinks about the model reaching out to the system it lives in. The closest anyone got unprompted was "he can access that database through API calls or MCP, whatever." That is the right instinct. Everyone else needed me to say it: "What if we just ask the AI to do the API call?"

Sometimes a complex thing needs a simple thing. A tool call. The model asks your API, your API answers, the model reads the answer. That is what agentic means. If you cannot explain that, do not rate yourself above a 4.

Pattern 3: Projects That Could Not Survive a Private Tab

This is the part I care about most, and I will admit my bias up front. My own job offer came from a side project with zero users. So I believe a personal project is the single most honest signal a candidate can give. It is the only thing on the resume nobody else assigned you.

Here is what the personal projects looked like.

Commit history. One project had five commits, all pushed in one dump after two to three weeks of building: "I did the whole project at a time. After that, I commit the whole project." Another had six: "I work on the complete project and then upload all of it to the GitHub." A third had 12 commits over three months. The ones with 40-plus commits had messages nobody could read six months later.

Demos. One candidate offered a recorded video instead of a live run, because the project was two months old and "I don't feel that much confident that it will run or not." When he ran it, he forgot to activate the virtual environment. Then the upload broke. "Something has broke."

One joined from a company laptop and could not build his own personal project in Docker. "I cannot say confirm because I had not run this project."

Two candidates had backends on Render's free tier that were asleep when the demo started. One had set up a cron to keep it warm and turned it off because he was about to hit the monthly hour limit.

Breaking the demo. On one e-commerce site, OTP was dead, the terms and conditions link went nowhere, there was no email verification, and the cart lived in browser localStorage, so it vanished when I opened a private tab. He also forgot the password to his own test account.

On a chess platform, I asked the candidate to create a room and join it from a private tab with the same account. "So you are battling yourself with the same ID. What do you think about it?"

Data. A railway assistant that ran on a 2017 CSV because there was no free real-time API. A flight booking system where Mumbai to Delhi returned nothing, because no flights had been added on that route.

Users. Across all ten candidates, the number of personal projects with a real user who was not a friend was zero. The only real users belonged to client work and internships: a complaint system deployed across 100-plus service centers, a job-application tool with 20-plus users on a subscription, a management app for one local gym. Real, but not personal.

Ownership. One candidate listed three client projects under "Projects." My first question was: "Do you know the difference between a project and work experience?" He said a project is a subset of work experience. For me that was a no from the start, and I said so in the debrief. I had read the resume thinking, wow, he built that for himself. He had not.

Our operations manager put it best in one of the debriefs: when candidates for AI roles are asked for a personal project and cannot show anything outside of work, the doubts start right there.

Pattern 4: Fundamentals You Studied Last Semester

I did not ask LeetCode. I asked about things candidates told me they were good at.

One candidate claimed strong DBMS experience. I asked for ACID properties. He said atomicity means two transactions should not interfere with each other, which is isolation. Then he said "A for availability." I gave him the letters. He gave the same definition for atomicity and isolation again and could not attempt durability.

I told him why I cared. WorkStackOS has a ledger. If we do not have atomicity, the ledger fails. A $100 transfer either goes through or it does not. It cannot vanish in the middle.

The same candidate declined the whiteboard twice when I asked for the Alice and Bob flow. "Can I explain verbally, sir? It will be better." It was not.

In the debrief I said what I actually felt. I gave him so many chances to talk about what he knows, and he could not tell the basic thing. Not the AI thing. The basic thing.

Pattern 5: Nobody Googled Us

Asked what he knew about the company, one candidate said it is "an outsourcing company for the employees and the employee can work remotely." That is the description our operations manager had given him the day before, plus the LinkedIn header.

One candidate had researched our time zone. One.

And one candidate did something nobody else did. He messaged me on LinkedIn before the interview and asked how to prepare. I told him: personal project. He showed up with two deployed projects, found a sleeping Render service in the logs when I asked him to locate the issue himself, and sat through more than twenty technical questions. Another candidate that week got about five, and the technical round was over in minutes. Not because I was harsher. Because he had something to show, so I had something to ask.

For contrast, our AI resume screener had ranked one candidate at a 90 percent match with a 99 percent assessment score. The resume mentioned TypeScript, React, and Supabase, and Supabase was in the job description. Asked how much she knew about LLMs and agentic AI: "Currently I have no idea in this topic." The keyword match got her the interview. It could not get her through it.

What the Five Who Advanced Did Differently

Five of ten went to the founders' round. Not one of them was flawless. Here is what they had in common.

They could explain their own pipeline end to end. One candidate walked me through hybrid retrieval: dense embeddings plus BM25, rerank to 15 chunks, cross-encoder down to the top 5, Gemini with a Groq fallback. He had zero web development experience for a Next.js role. He still advanced, because when I asked about GraphRAG he said "No idea," read the doc, and explained it back correctly.
They learned in the room. A third-year student read an unfamiliar GraphRAG article under time pressure and explained why relationships matter for "who was X and what did he do and why," which is exactly what the plain-RAG answers missed. When I told him to close his eyes and think, he did. He did not panic.
They debugged live. Sleeping service, stale key, failed test case. He opened the logs and found it. I told him I understood. I have failed the same way many times.
They had shipped something real, somewhere. A complaint management system replacing an Excel process across five states. OTP email verification actually implemented, not planned.
They were honest. "I don't want to lie and say I'm very confident. But I'm actually willing to learn." That candidate had tried BERT for a recommendation engine, measured the results, and switched to cosine similarity because it worked better. That is engineering.

Honesty, plus something runnable, plus the ability to learn on the spot. That beat every keyword-stuffed resume of the week.

What I Learned About Interviewing

I was new at this too.

Depth is gated by the candidate. I can only dig as deep as the project allows. No project, no depth, short interview.
The reading test stays. Pasting a doc mid-interview and asking for a revised answer showed me more in five minutes than any question about experience. Our operations manager called it trial by fire. It is now a permanent part of how I interview.
Close your eyes. The moment a candidate starts typing, they are searching. Asking them to close their eyes and think produced better answers and told me who could handle pressure.
Time is the real cost. Several candidates said they could reach an intermediate level in agentic AI in three to four weeks. I believed them. The question in the debrief was different: could we afford three to four weeks? For an intern who is supposed to multiply the team, that was usually the whole decision.
Set the table. We now tell every candidate before the call: have your GitHub and a live demo ready. If it is not ready, the interview ends early.

If You Are Interviewing in 2026

Warm up your demo the morning of. Ping your free-tier backend with a cron. Read your own README. Run it once before the call.
Commit as you build. Five commits for three weeks of work tells me you either did not iterate or you are hiding the iteration.
Be explicit about ownership. If it was client or contract work, label it that way. A resume that blurs the line reads as padding, and the next question will be: remove what the company did, what did you build from scratch?
Rate yourself one point lower than you want to. The follow-up question is coming.
Learn the vocabulary. Tool. Agent. MCP is Model Context Protocol. RAG is retrieval, not training. Evals. Observability. This is a weekend of reading.
Not everything is RAG. If the data is live, the answer is a tool call.
Assume I will open a private tab. Verify emails. Persist state server-side. Make the terms link go somewhere.
Get one real user. One person who is not your friend. It changes every answer you give.
Ask how to prepare. The one candidate who asked had the best interview of the week.
There is no cost excuse. The Gemini API key is free for development. You will not max it out. There is no reason left for a 2026 project to have no AI feature.

A year ago, a side project with zero users got me hired in 30 minutes. This month I watched ten people sit where I sat. The ones who got through were not the ones with the best resumes. They were the ones who could run their thing, explain it, break it in front of me, and say "I don't know" without flinching.

Build something. Keep it running. Know why it works. That is the whole interview.

Zero Users, One Job Offer: The Honest Post-Mortem of My AI Side Project

Kanishaka Pranjal — Mon, 30 Mar 2026 13:49:16 +0000

This is the story of how I spent seven months building an AI storytelling app, completely failed to market it, gave up on it in frustration, and still consider it the most successful failure of my career.

The Weekend Grind (January to July 2025)

At the start of 2025, I was in my 8th semester of B.Tech, juggling a flexible remote internship during the week. On paper, I was building my resume. In reality, the atmosphere was bleak. I was taking on freelance gigs just to stay afloat, and the looming dread of graduation without a full-time role lined up was a heavy physical weight.

I knew that if I didn't land a job soon, the frustration was going to spiral. So, FableWeaver.ai became my weekend obsession. Every Saturday and Sunday for seven months, I locked myself in to build.

The Mental Anchor & The Inspiration

Coding a massive full-stack Next.js/TypeScript application on top of a weekday internship and 4 to 5 hours of daily interview prep is a fast track to burnout. To survive, I built strict boundaries.

First, I built a physical anchor. Every morning, I hit the gym. Over 14 months, that daily discipline helped me drop from 83kg to a lean 64kg. It became my mental fortress, keeping the anxiety at bay and building the raw discipline I needed to code through the weekends.

Second, I refused to give up my hobbies. No matter how deep I was in the codebase, I carved out at least an hour every day to unplug and read web novels like Omniscient Reader's Viewpoint and Mother of Learning. But those stories weren't just an escape; they were the blueprint.

I was building FableWeaver for the community that raised me. I genuinely love these stories, and I have massive respect for the communities of readers and writers surrounding them. I wanted to give them a platform where AI characters could actually remember massive amounts of lore and interact autonomously.

The Technical Trenches

Building FableWeaver forced me to solve problems that no basic tutorial covers. The hardest hurdle was what I call the "Goldfish Effect."

The deeper a story went, the more the AI lost the plot arc. Imagine reading a 50-chapter fantasy book. In chapter 2, the author reveals a dark secret about the villain. But by chapter 15, the AI generating the story has completely forgotten the villain's motives and suddenly makes him a friendly barista serving the hero coffee. The context window just buckles under the weight of the lore.

Fixing that (building complex context management systems to keep the AI anchored to the truth) took months of trial and error. It was brutal, but it forced me to actually engineer, not just write API wrappers.

The Marketing Wall & The Post-Mortem

By July, the product was "done." It featured multiple AI agents interacting via Supabase Realtime and layered context injection. It was technically sophisticated, but invisible.

My marketing was a disaster. The bitter irony of FableWeaver is that the exact community I built it for—the readers and writers I loved—completely rejected it. I spent weeks lurking in Discord servers, desperately dropping links and pitching the app. Instead of welcoming the tool, I got swiftly hit with the ban hammer by mods for self-promotion.

If I had to do it over, I would not have spent seven months building in absolute silence. I would have built in public from day one, shared the technical struggles of managing AI context on Twitter, and asked writers for feedback before I ever wrote a line of code. Dropping a finished link into a chatroom is not community building; it is trespassing.

I lacked the resources and the audience to push it further. Exhausted, feeling the sting of rejection from my own community, and sitting at zero users, I looked at the finished product and did something rare in the "hustle" world: I gave up.

The 30-Minute Plot Twist

My primary reason for building FableWeaver wasn't to become a startup founder; it was to get a real job.

In mid-August, shortly after graduating, I hit a breaking point with standard job applications. Out of sheer frustration, I built a custom AI Agent web app in a single day to completely automate my cold email outreach (a wild story for another time). That agent landed me an interview for an AI Engineer role at WeAssist.io.

I wasn't interviewing with another engineer; I was sitting down with the Founder and the Product Manager. They needed someone who could bring deep AI knowledge to the table to actually build out their vision.

I didn't wait for them to ask me abstract LeetCode questions. I intentionally hijacked the conversation. I wanted to show them what I could build and exactly how I utilized AI to do it.

I pulled up the FableWeaver dashboard and took over the demo. I didn't even look for an "aha" moment from them; I was entirely laser-focused on showing the live product. I walked them through the autonomous AI group chats and explained how I solved the chapter context-loss problem under the hood. They saw the thousands of hours of weekend effort I had poured into the platform.

They were so impressed, they hired me in under 30 minutes.

The Real ROI

Today, as an AI Engineer, I can confidently say that FableWeaver.ai served its true purpose.

It might have zero users, but the skills transferred exactly. Handling complex agents, knowing exactly when to use a tool call, managing context tokens, and optimizing API costs for web apps are second nature to me now. Why? Because I already bled over those exact issues on my own time.

FableWeaver will likely never have a paying user. But a project with zero users is not a failure if it gets you exactly where you need to go. I didn't build a startup. I built a 2,000-hour technical interview that nobody could ignore.

I didn't get the users, but I got the job. And honestly, that was the point all along.

Stop Building To-Do Lists: How My Passion Project for Web Novels Taught Me AI Engineering

Kanishaka Pranjal — Mon, 16 Mar 2026 16:13:43 +0000

In 2026, everyone is building "Chat with your PDF" apps and AI Resume Screeners. These are the new to-do lists. Tutorial projects that prove you can call an API but not much else.

I was stuck in that loop too. Then I started building for an obsession I've had since I was a kid: stories.

How I Got Here

I was 13 when I wrote my first lines of QBasic. But my obsession wasn't code. It was worlds. Cartoons first, then anime and manhwa (Solo Leveling had me tracking power systems across 200+ chapters like a database), and eventually web novels. By the time I hit college at IIIT Sri City, I was reading Omniscient Reader's Viewpoint and Mother of Learning. Stories with thousands of chapters, hundreds of characters, and lore systems deep enough to crash a context window.

I didn't just want to read these stories. Since childhood, I'd wonder what it would be like to actually talk to these characters. And by 2020, I had entire worlds spinning in my head that I wanted to write down, but my writing couldn't keep up with my imagination.

So I built the tool I wished existed.

FableWeaver.ai

FableWeaver.ai is an AI-powered platform for writing interactive web novels. Not a wrapper around a chat API, but an actual system where characters remember their lore across hundreds of chapters and can talk to each other autonomously.

Building it forced me into two engineering problems that no tutorial covers.

Problem 1: LLMs Forget Everything

I call this the Goldfish Effect. Most student AI projects work fine for short documents. But feed an LLM a 200-chapter novel and it forgets the protagonist's hidden motive from Chapter 2 by the time you hit Chapter 50. The context window just isn't big enough to hold an entire world.

My first instinct was basic RAG: retrieve relevant chunks and stuff them into the prompt. That works for documentation search. It does not work for narrative, where foreshadowing from 30 chapters ago matters as much as what happened last paragraph.

So I built a layered summary system instead. Three tiers of context, each serving a different purpose:

World lore: the rules of the universe, character backstories, magic systems. Static. Never changes unless the author edits it.
Arc summaries: a compressed version of the current ~10-chapter plot arc. Updated every few chapters.
Chapter recap: a detailed summary of the immediately preceding chapter. Regenerated every time.

When the AI writes a new chapter, it gets all three layers injected into the prompt. It knows the world, it knows the current plot arc, and it knows what just happened.

// Fetch the three context layers for prompt injection
const { data: layers } = await supabase
  .from('context_layers')
  .select('type, content')
  .in('type', ['world_lore', 'arc_summary', 'chapter_recap'])
  .order('type');

const worldLore = layers?.find(l => l.type === 'world_lore')?.content ?? '';
const arcSummary = layers?.find(l => l.type === 'arc_summary')?.content ?? '';
const lastChapter = layers?.find(l => l.type === 'chapter_recap')?.content ?? '';

const prompt = `World: ${worldLore}
Current Arc: ${arcSummary}
Previous Chapter: ${lastChapter}

Continue the story. Write Chapter ${currentChapter}.`;

Problem 2: Characters That Talk to Each Other

While most people build 1-on-1 chatbots, I wanted a full cast that could argue with each other. And with the reader.

Each character is its own AI agent with a system prompt that locks down their voice, their secrets, and their constraints. A brooding anti-hero gets "Never agree easily. Question motives. Use short sentences." A court scholar gets "Speak formally. Reference historical precedents. Never use contractions."

The tricky part was orchestration. I wired it up with Supabase Realtime so the agents run in a shared channel:

A user drops a message into the group chat.
The hero agent responds.
The rival agent "hears" the response, runs it through a personality-weighted prompt, and decides whether to interject or stay quiet.
A turn-taking manager prevents infinite agent loops. This was a real problem in early builds. Two agents would just argue forever.

The result is a conversation that feels alive. You're not chatting with a bot; you're in a room with characters who have their own agendas.

What Broke

Two things nearly killed the project.

Summary decay. I initially had the AI summarize the previous summary every few chapters. Classic shortcut. By chapter 20, it was like a game of telephone. The plot had hallucinated into something unrecognizable. A character's betrayal got softened into a "disagreement," key plot points vanished entirely. I fixed this by anchoring every 5th summary back to the original world lore, so the summaries could never drift too far from ground truth.

Character bleed. After about 10 messages in the group chat, every character started sounding the same. Polite, helpful, agreeable. Turns out LLMs have a strong gravitational pull toward a "default helpful assistant" voice. I had to fight this with negative prompting: explicitly telling each agent what they would never say or do. That made the difference between a cast of identical chatbots and characters with actual friction.

The Takeaway

My first shipped project was GoodWill, a messy MERN stack app connecting NGOs with donors. Three organizations actually used it. The tech was barely held together, but it taught me something no tutorial ever did: a shipped, imperfect product is worth more than a perfect one that never leaves localhost.

FableWeaver was the same lesson at a harder difficulty. It taught me context window management, multi-agent orchestration, and real-time state management. Not because I was following a curriculum, but because I needed to solve these problems to make my thing work.

In 2026, the bar has moved. Recruiters don't care that you can call an API. They want to see that you can manage state, handle latency, and keep an AI system coherent over time. You learn that by building something you actually care about, something where cutting corners means your own experience gets worse.

Find the gap in your hobbies. Build the bridge.

This post was originally published on kanishakapranjal.com.

The True Mother of Learning

Kanishaka Pranjal — Wed, 04 Mar 2026 08:04:32 +0000

If you had to answer the question, "What is the mother of learning?" what would you say?

It is a slightly philosophical question, and the answer varies. Some might say patience. Others might say curiosity. For me, the absolute mother of learning is applying.

💡 Tip:
Quick aside for the fantasy fans: Mother of Learning is a legendary web novel where the protagonist masters magic by reliving a one-month time loop hundreds of times. The principle is simple: progressive repetition, applied relentlessly, until mastery.

Universally, the core of human skill acquisition is progressive repetition. We try something, we fail, we adjust our approach, and we try again. We loop through the problem until it clicks.

The most fascinating part about this concept? That is exactly how Artificial Intelligence learns, too.

The Human and Machine Parallel

When we look at Machine Learning, models go through "epochs": massive cycles of progressive repetition. They ingest data, make a prediction, calculate the error, adjust their parameters, and repeat.

Whether human or machine, mastering a new skill requires looping through the data until the patterns make sense.

My AI Journey: From Curiosity to Production

My own journey into the world of AI mirrored this exact process. Back in 2022, I didn't start with complex architectures. I started simply as a curious user messing around in the OpenAI Playground.

I was hooked. I spent my weekends reading articles, consuming documentation, and testing prompts. Soon, I was in the Playground at least five times a week, pushing the limits of what the models could generate.

But I realized early on—whether I was 13 writing my first lines of QBasic or later building full-stack applications—a shipped, imperfect product teaches you more than a polished tutorial ever could.

I used progressive repetition to go from testing basic prompts to engineering actual products:

Voice-based AI: Integrating OpenAI's Realtime API and WebRTC to build interview simulators.
Generative Storytelling: Leveraging the Gemini API for platforms like FableWeaver.ai.

Architecting the Future

Fast forward to today, and that initial curiosity has evolved into my daily reality as an AI Engineer.

I went from testing prompts to building entire platforms from scratch. Today, my work revolves around architecting AI-powered full-stack systems with Next.js, TypeScript, and AWS. I build platforms where AI handles the operational grunt work so humans can focus on the work that requires actual judgment.

The Takeaway

If you want to understand Artificial Intelligence, you cannot just read about it. You have to get your hands dirty.

Find a tool, hit the API rate limit, figure out why your WebSocket dropped, and build it better.

This post was originally published on kanishakapranjal.com.

The mother of learning is applying.

Let's discuss: What is one project you "applied" yourself to that taught you more than any book ever did? Drop it in the comments!