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

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:

1. Share your screen and open GitHub. Contribution graph, switch the years. Open your best repo. Click on the commits. Scroll slowly.
2. Live demo. Not a recorded video. If it is not deployed, run it locally.
3. 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?"
4. 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?
5. 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?
6. 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.
7. 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?
8. 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

1. 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.
2. Commit as you build. Five commits for three weeks of work tells me you either did not iterate or you are hiding the iteration.
3. 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?
4. Rate yourself one point lower than you want to. The follow-up question is coming.
5. Learn the vocabulary. Tool. Agent. MCP is Model Context Protocol. RAG is retrieval, not training. Evals. Observability. This is a weekend of reading.
6. Not everything is RAG. If the data is live, the answer is a tool call.
7. Assume I will open a private tab. Verify emails. Persist state server-side. Make the terms link go somewhere.
8. Get one real user. One person who is not your friend. It changes every answer you give.
9. Ask how to prepare. The one candidate who asked had the best interview of the week.
10. 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.