Claude Code 'Interview' Mode in 6 Minutes

--- type: transcript date: 2026-01-01 youtube_id: vgHBEju4kGE --- # Transcript: Claude Code 'Interview' Mode in 6 Minutes It's the first day of the year, and I thought, what better way to kick off the year than to show you a fresh way of how you can plan your projects within Claude Code. In this video, I'm going to be showing you how to get better outcomes by slowing down, spending more time being interviewed by Claude before actually kicking off the process, and beginning to code. Now, the origin of this came from Tariq, who works at Claude Code. He recently tweeted, "My favorite way to use Claude Code to build large features is specbase. Start with a minimal spec or prompt and ask Claude to interview you using the Ask User tool. then make a new session to execute these specs. This got a ton of attention and it really resonated with people because I think a lot of us have had the experience whether you're using cursor cloud code or any of these agentic systems where you'll put in a prompt and it will go through and build out a bunch of stuff that you might have otherwise not wanted it to do. There's a lot of nuances that go especially for larger prompts that arguably most of the time you probably want to have a little bit more of input on but you might not have originally thought that within your initial prompt. The idea with this is interview first, spec second, code last. Now, in terms of the approach for this, there's the method within cla code, the ask user question tool. You might have seen this if you've used cloud code before where it asks you two or three questions about implementation details. Further, he mentioned for big features or for new projects, Claude might ask me 40 questions and I end up with a much more detailed spec that I feel I had a lot of control over. The prompt that I've been using for this is read the spec.MD MD and interview me using the ask user question tool about literally anything. Technical implementation, UI and UX concerns, trade-offs, etc. But make sure the questions are not obvious. Be very in-depth and continue interviewing me continually until it's complete. Then write the spec to the file. So the idea with this is really to slow down to speed up. Now, a lot of people's first experience when they're leveraging tools like whether it's cloud code, cursor, lovable, bolt, generally what they do is they'll put in a prompt and there might be a couple questions and then it will spin off and start to build out your application. But the idea with this is really just to slow down to speed up. So most people they'll jump right into coding. And the thing with this is it will allow you to have a better understanding of what it's actually doing. The more time that you spend planning, the less time that you're going to spend reworking what Claude might have already done. The first time that I saw this sort of specd driven development workflow was from Kira, which is an IDE that was built by Amazon. And this is a similar sort of idea. Now, the idea with this is when you give Claude a prompt, Claude is going to make a ton of different assumptions. If we take the example of adding authentication to an application, if you just ask Claude to add authentication to your application, it could go off. It could implement a JWT. It could maybe not do ooth. It could do sessionbased. And the idea with this is at the end of it and you might realize at the end like oh I actually wanted to leverage a managed service something like work OS or clerk or whatever it might be. This is going to get to those details much sooner where you don't actually have to rework everything. Instead of prompting Claude, Claude is going to prompt us and instead of guessing Claude is going to ask clarify instead of you having to rework all of those different assumptions. Now if you're not familiar with the ask user question tool within Claude codes, this is what it looks like. It's going to ask you a number of questions mid session multiple choice options and then it will continue with your option. Now just to demonstrate this I'll do this with a relatively broad prompt. I'll say build me a Nex.js app. Interview me about what I want. What I've actually done is I've gone ahead and implemented what Tariq had within the prompt and I've added that within a skill. What we'll see here is it will trigger the interview skill which I'll show you in just a moment. And then from here we can see let me interview you and understand what you want to build within here. It's like, what am I actually building? A web app, a marketing site. I'll say I'm building a marketing site and it's for developers. And then as soon as I send in those answers, it's just going to go through the process and it's going to continue to ask me more clarifying questions. So, this is a developer tool or SDK. You can also add in your own information as well where you can type things to answer the questions as well. I can say we're going to have a book a demo page and we're just going to submit that. That's basically the core idea. Now, one quick aside that I do want to mention. Cloud code has had plan mode for quite a long time, which is excellent. It explores your codebase. It can design implementation files and it will actually write a plan. And the interview mode is not to substitute the plan mode. It can almost be used as a precursor for planning. You can interview and then you can go through the planning phase. And this ultimately will ideally lead to much better outcomes. Now in terms of actually adding an interview skill, it can be very straightforward. So you can use exactly what Tariq said. You can have read the plan, use this tool, ask me about the technical implementations, or you can build your own variation of this depending on what you want to do. You can specify potentially the number of questions or whatever it is within the skill file and it will trigger automatically. And the nice thing with skills is it's going to follow the process and it will be able to latch on and trigger those native tools within cloud code. It's pretty clear why this works. You're going to be making all of those different decisions up front. You're narrowing the space of all of the possible solutions that Claude could generate for you. Instead of discovering buried assumptions during code review, you can actually confront all of those decisions when they're cheap to change before it actually writes and uses all of those tokens to generate the feature that you're asking of it. Now, one of the more traditional prompt engineering methods was around crafting really perfect instructions or as close to it as you could get. Whereas with spec driven development, AI will help you discover what you actually want because it might not necessarily be as clear as you think right away. So instead of just getting everything right within one prompt, you're going to be going through a discovery process. And all of those different questions will ideally help reveal the requirements that you might have not have otherwise even thought that you had. Next time you have a large feature to build, I encourage you to try this out. Don't just try and get it all within one prompt. Actually try out the interview process. Ask it to interview you about this plan leveraging that ask user question tool and you'll be surprised, I think, at the results that you'll get. Otherwise, I'll put the links to some of this within the description of the video. But if you found this video useful, please like, comment, share, and subscribe.