I’ve noticed something interesting with all the recent and insane talk about AI. Many software engineers now speak openly about entirely handing over coding tasks to AI agents, and they often get praised for making that move. Some even claim they barely look at the code generated from AI systems, and some don’t look at all. However, writers who code in human languages to help draft articles, books, or other prose texts get a vastly different response. They face harsh criticism. Why? The contrast is worth considering. Both groups work with similar technology, but the social judgment runs radically in opposite directions. Sure, the two crafts share some things in common, but they are certainly not exactly the same. So, is the reaction really a double standard? Well, partially.
How developers used to work before AI
Picture how developers used to build their software before AI. Generally speaking, they’d start with a problem, break it into pieces, and think through the architecture all before typing any code. They would choose data structures, write functions, plan testing strategies, secure code review assignments, and review edge cases with team members before running anything. When the code failed, they would read the errors, find the bugs, and fix them themselves. They would review their own work repeatedly and also ask colleagues to look at their code as well. Every choice in the finished code passed through the developer, other team members, and multiple systems. Human judgment stayed right at the center. The process was slower by today’s standards, but that slower pace forced a deeper understanding and led to higher quality products before anything shipped. That’s just a rough summary of the process but you get the idea.
How many developers work now with AI
Now compare that with how many developers work today using AI. They still start with a problem or a new opportunity and break the tasks into pieces, which is obviously similar to working before AI. The difference is that they now write detailed prompts instead of typing the first lines of a function. A prompt would name the files involved, state the tech stack, describe the exact behavior needed, and lists the constraints. An AI tool then produces a first draft, sometimes across several files. Developers review the output, run the tests, fixes errors, and tighten up the result. Developers also iterate with the AI by refining their prompts or making direct edits to the code, or configuring any number of agents to chain multiple tasks and run systems autonomously. For routine tasks such as boilerplate, tests, or simple refactors the AI clearly saves time.
But with complex logic or significant architectural decisions developers still do most of the thinking and keep full ownership of the final code that’s produced. The job has shifted toward directing AI systems and verifying outputs. Careful review remains essential for most serious software engineering work. Some engineers describe this as managing agents, and they treat the shift as a mark of sophistication. A smaller group of developers claims that they now rarely open the generated files at all because the AI systems are reliable and are meeting expectations. Even inside engineering that more extreme version sometimes draws criticism when a developer can’t explain or fully own the result. But the trend to what used to be considered extreme is ongoing.
How writers used to work before AI
Now look at writers. These people who code in prose went through something similar on their own timeline and with their own tools. The old way meant manual research, drafting outlines, crafting early drafts built sentence by sentence, and editing. Writers would sit with an idea for days or even longer before a concept or scene or in their heads came to life on a page. They would then revise repeatedly, cutting what didn’t work and sharpening what did. Aside from the formal editorial process that came after the writing where others would work on the text, the voice on the page belonged to the writer because every word was carefully crafted by hand.
How AI changes the writer’s process
AI changes the writers’s process now too. Writers can now just hand an AI system some early notes, ask for any amount of additional research, and get a full draft back in minutes. From there writers can certainly edit, sometimes lightly, sometimes so heavily, so that more of their voice survives within the AI generated text. The starting point now has moved from a blank page to a rough machine made draft, which is similar to a developer’s starting point moving from a blank file to a block of generated code.
Where the two reactions split
Here’s where the two paths split, though. It’s not in the work itself but in how the world responds to it. When developers say their agents wrote most or all of the code, people in the field call it efficient and innovative. Companies hold this up as the future of the profession because the commercial and social pressure is real. The argument is that faster delivery and lower headcount translate directly into competitive advantage. That’s the mantra and it’s pervasive in the industry at the moment. Engineers who still write everything by hand usually hear that they are now behind the times and will be replaced.
But if a writer drafting an article or book says the same thing as developers have been saying then the reaction flips dramatically. If they admit that AI drafted a chapter, even one they rewrote many times, then readers and trolls online immediately grow suspicious. Editors ask questions to writers they would never ask a developer. Some publications ban the practice of using AI outright. Many schools and teachers do as well. The finished piece gets picked apart for tells, real or imagined, in a way finished code rarely does.
Why the judgment differs
Part of this clear disparity comes from how each field values good work. Computer code has a clear test. It runs or it doesn’t. And users either get what they needed or they don’t. Prose has no such test. Readers respond to the human voice, the sense that a particular person shaped those particular words in a specific way. And that feeling is remarkably guarded and fragile. If readers and editors learn that a machine had a hand in the writing process then the spell breaks, even when the writing itself has not changed at all.
There’s another piece of this phenomenon worth naming. Code has always been written primarily for a machine to execute. A developer might read it later, but the first audience was always the compiler, and success meant the machine did what it was told. Prose never worked that way. It was always written by one person for another person, and it only started drifting toward a machine audience recently, first for search engines ranking pages and now for AI systems summarizing and reusing text. That difference in history might help explain part of the discomfort writers feel when they are judged for using AI. But engineers using AI agents are simply extending a relationship with machines that already existed. However, writers leaning on AI are now for the first time messing with a world that used to belong to another person entirely, and their readers can feel that shift even when they cannot name it.
The tools themselves that developers and writers use are also at different stages. AI coding assistants have become reliable enough for real production work on many routine tasks and even some advanced tasks. They can be constrained, tested, and iterated in ways that current AI writing tools still struggle with for high quality prose. It seems that cultural acceptance tracks that practical difference as much as pure preference.
The internal standard in software
Even inside the software industry, a version of this line already exists. It’s just aimed inward rather than at writers. Programmers who let an agent generate code without reading or fully understanding the code get called vibe coders, and plenty of other engineers push back on that label hard. Their standard sounds a lot like the one writers get held to. If you review what the AI produced, test it, and can explain how it works to someone else, that counts as real development no matter how much the AI contributed. If you can’t do any of that, it does’t count, whatever the code ends up doing. Writers face nearly the identical test. The difference is where the line sits. Inside engineering, plenty of AI use still clears that bar and earns real credit. But in writing even heavy revision after an AI draft often does not clear the line, at least not in the eyes of the people judging the finished piece.
That explanation only goes so far, though. It doesn’t account for why engineers who fail their own field’s test, the ones who openly say they barely glance at the code, still get praised for candor rather than penalized the way writers would be for the same admission. The work has moved in the same direction in both fields. But the judgment has not. Instead, it has settled in opposite places depending on who is doing the talking. It’s partially a perspective issue but also a demonstration that the two fields and processes aren’t exactly the same.
Where pride can move
None of this is new to developers. Long before AI, plenty of engineers took real pride in writing their own code specifically, not just in what it did. They argued over whose solution was cleaner. They refused to publish something messy. An ugly or inefficient implementation was a real embarrassment even when it worked. They took pride in their authorship, the same instinct that drives writers to protect a sentence. So the difference between the two fields was never that developers lacked that instinct. It’s that the instinct had somewhere else to go once AI arrived. And this turns out to be a critical point.
For developers, the code was always a means to an end. The real deliverable was a working system, and the code was generally the best available way to produce one. Craft pride and outcome pride pointed at the same target for a long time, so nobody had to choose between them. AI broke that link. Once a working system could exist without hand written code underneath it, the pride had somewhere to move. It shifted up a level, to the architecture, the judgment behind what got built, the taste in directing an agent toward the right result. The identity didn’t disappear. It just relocated to a layer AI has not fully reached yet. It remains to be seen how developers will react when AI can cover the entire process.
Why writers have less room to move
Writers do not seem to have an equivalent layer to retreat to, and the reason is structural. It’s not a matter of stubbornness. When developers hide code behind a working system, the user never touches the implementation directly. Two completely different codebases can produce an identical experience for the person using them. The code sits behind an intentional layer of insulation. Prose has no such layer. A reader does not experience some abstracted effect that the sentences produced somewhere upstream. A reader experiences the sentences directly themselves. Change the words and you have changed the actual thing being read, not just the machinery behind it. The sentence is often the product in a way code usually is not. So there is no equivalent shift available for most writers to make. But will that change in the future as readers get used to AI generated text? And what happens when AI agents can craft massive and unique novels in a specific writer’s voice without detection?
Nevertheless, markets and social pressure reinforce this process at present. Software users and companies primarily care whether the system works and how much it costs. But many readers of prose still treat the human relationship with an author and the sense of a particular mind behind the words as part of what they are buying and experiencing. Authenticity is not only a cultural preference. It’s part of the product for a large share of the writing market. For now, anyway.
Institutional rules differ too. Publishing contracts, academic policies, and editorial standards still treat AI contributions as something that must be disclosed or banned. But software employment and open source development norms treat AI assistance as ordinary tooling with far less formal restriction. Those rules reinforce the social disparity we are seeing escalate now with AI.
What the split inside software suggests
It’s not all perfect with software developers, though. Not every developer makes the shift to AI easily. The ones who built their identity on demonstrating individual skill, the tightest solution, or the best line of code feel a loss that looks a lot like what writers feel. For them the code was never just a means to an end. It was closer to the point itself. Both fields also worry about the next generation. In software the fear is that junior developers will never build the necessary skills to debug or design complex systems. In writing the fear is the loss of voice, critical judgment, research skills, and the long apprenticeship of craft. Watching some developers relocate their pride with ease while others struggle to let go of authorship suggests the split runs through personal temperament more than through the profession itself. Writers may be looking at a preview of their own future in that split with some finding a new place to put their pride and others not finding one at all. So, although the two fields are similar, the problems writers are facing may not be totally unique to them.
Maybe the honest answer about the double standard is that there really isn’t one. Or that it’s just not a clear distinction. Code was mostly judged by outsiders on results, while prose was always judged on process and on the sense of a specific person laboring over every sentence. AI did not create that asymmetry. It just made it impossible to ignore now. The commercial pressure, the maturity of the tools, and the different market rewards made the social reactions diverge even further. Some people think the disparity of reactions is getting worse, but maybe there will be a different outcome altogether that we can’t imagine right now. Who knows.
Since 2017 I have interviewed about 500 developers for articles, audio, video, and live streams at events on a variety of topics including Java, Linux, Oracle Database, MySQL, AI/ML, Developer Tools, Oracle Cloud, and Open Source.
Most of my interviews these days take place via Zoom from my kitchen, which I find frustrating because I greatly prefer the connection of live interactions at conferences. That’s a bug. I’m working on a fix. But for now, I’m making do. The checklist below captures some insights I’ve gained about the interpersonal dynamics of interviewing software developers. This isn’t about podcast equipment or technical setup. Instead, it focuses on creating a comfortable environment for guests, drawing out compelling stories, and fostering engaging conversations that resonate.
As I continue learning, I revisit these points regularly and update as needed. They’re shaped by my own painful journey in this field without formal mentorship, so I’m always open to feedback to help refine my approach. The whole experience has been pretty personal for me, to be honest, considering that I’ve radically changed careers a few times, I’ve had to start over from scratch repeatedly, and I couldn’t talk fluently until I was well into my 40s. So be it. That’s life.
Anyway, here’s what I’ve learned so far.
Before You Hit Record
Talk to them first.
Don’t just send your guests a calendar invite with a link and hope for the best. Some developers aren’t used to being interviewed, and they may be apprehensive initially. Do a quick call first. Send them an email explaining what you’re doing. Is this video or just audio? How long will it take? What kinds of things will we talk about? Then, when the interview day comes, I always start recording at least 15 minutes after getting on the call just so we can chat about their latest projects before recording, which helps guests get comfortable, sets a collaborative tone, and organizes things in my own head as well. I’m always nervous at the beginning so killing a few minutes up top is always best.
If you are live on site, you can do this simple preparation work right before you turn on the camera if you have a simple interview with an experienced guest. But for more complex things, you may need more time to prepare. For example, at JavaOne 2025, I ran a Duke’s Corner Podcast panel during the Day 3 Community Keynote, and for that I did a lot of preparation. First, I did my own prep to scope out the entire segment. Then I selected three interesting Java developers as panelists. Then I pinged them via email with all the details, and we had some online threads as we agreed to everything. Then we met as a group at the JavaOne speaker dinner on Monday a few days before the keynote to go over issues together and start the process of gelling as a group. Then we participated in rehearsals with the other Day 3 speakers on Wednesday. Then finally we ran live on Thursday. The result? Our session was perfect! But it did take some real preparation. When the stakes are high like this (a live keynote session) it’s best to layer the preparation with your guests so you don’t miss any of the details and everyone knows what to expect.
Do your homework.
If you show up unprepared, you’re wasting everyone’s time. And if your guest is experienced, you also run the risk of embarrassing yourself. But most developers aren’t experienced at interviews, and they aren’t media trained with prepared talking points like you’d get with a CEO or marketing executive. It’s your job to dig into their work a bit and find a few interesting threads. Check their GitHub accounts, read their blogs, look at their conference talks. If they’re involved in a user group, find out what they’ve been up to lately. Check their posts on X or LinkedIn or their project mailing lists to stay current with their latest community discussions and contributions.
This homework isn’t just about having some solid background data to generate interesting questions. It shows respect for their work and their time, it builds a genuine connection when you meet, and it makes the whole conversation flow better.
Start Strong, End Strong
Jump right in.
Don’t waste time with long, awkward small talk or forced jokes at the start of an interview. Pre-plan the start so you can begin efficiently. This is always the hardest part for me, especially when doing live streams because you only have one take. So, just do your introduction, get a quick response, and get going into the content. You’ll feel better once things get rolling! For example, if your guest organized a hackathon recently that helped streamline bug triaging, start there. That’s perfect. After your introduction and your guest’s response, jump in with something like this: “Hey, I saw your recent hackathon — tell me how that came together.” In other words, be pleasant and professional. But move! I’m not saying you have to make the intro so short to fit into the insane YouTube “shorts” of mere seconds up front. But don’t hang out with meaningless jabber either.
Plan your exit.
Every conversation has a natural lifespan. You’ll feel it when the energy starts winding down, you’ve run out of questions, or your start repeating yourself. Plan for wrapping up smoothly. I always tell guests upfront that I’ll give them a chance for final thoughts when we get near the end. When you feel that you’ve covered everything you can simply move along to this: “Ok, before we wrap up, is there anything else you want to add? Any plans coming up? Anything you want the community to know before we go?” Now, I wouldn’t ask all of those questions in a row like that. Those are just examples of one or two to use. After their response, it’s perfectly acceptable to say, something like this: “Oh, I love that. That’s great. Ok, we’re done. Let’s get out of here! Have a great trip to JavaZone in Oslo. See you next time.” Or something like that. They’ll respond with a quick bit. And you’re out. Or sometimes you’ll be able to cut right after your goodbye. Just go with the flow but always have the intention of ending things with some precision. If you want to summarize some key takeaways occasionally before saying goodbye, and if it feels natural, that’s fine too. There are many ways to end. Just don’t drag it out. Also, always thank your guests and tell them when the episode will be out. The goal here is to get out before the energy dies because it will be obvious to listeners if you don’t.
Listen!
Your superpower is your silence.
Listening. This is critical. It sounds obvious, but really very few people have mastered this skill. Actually listen to what your guest is saying in real time. You must listen to your guests while they are talking not only so they feel heard but also so you can facilitate the conversation naturally and things flow well. It’s obvious when one person in an interview is not listening to the other person. You can see it all over YouTube and especially on news programs. Also, just recall conversations you’ve had in real life. You know immediately when you aren’t being heard, right? Now put that experience on audio and video for all to see and hear. It’s ugly.
I know it’s tempting to think about your next question while your guest is talking. But resist that urge. If you are on site, I know it’s hard to listen when there are sound distractions in the room, and when you’re worrying if someone will crash into the camera (which happened to me many times). And, of course, it’s hard to listen when you can’t remember if you even turned on the camera or if you focused properly and set the white balance correctly. It’s best to have a short checklist on site because things can get confusing, especially when you are working alone, which has always been the case for me. And even have a short checklist for doing Zoom interviews from your kitchen. Checklists work. Remember, surgeons and airline pilots and people in many other professions use checklists daily so there’s no reason we can’t as well.
Use whatever tool you can to free your mind so you can listen in the moment. When someone tells you about fixing a critical bug or organizing their first meetup, really hear them as they are talking. Respond with some body language so they know you are following their story. Paraphrase what they said: “So your mentorship program actually helped people contribute to OpenJDK for the first time? That’s excellent!” This shows you’re paying attention and often encourages them to elaborate with even more details. Simply providing a brief summary is a great way to keep people talking while you navigate the conversation.
And don’t be afraid to respond with short quips like: “That’s cool!” or “Wow! How’d that work?” when something genuinely interests you. Sudden and authentic reactions help keep the conversation flowing naturally, which is what we all do in normal conversations without microphones and cameras. Just think of the last chat you had with a friend in your favorite coffee shop as a great example of normalcy. Try to keep your guests talking with subtle, familiar cues like this. Or sometimes, if they end before you think they should, be even more obvious. “No, keep going! That’s great. How did that situation end?” You’ll probably have to do this with a semi humorous voice to avoid appearing too aggressive. Most people get it, though.
Bridging and Flowing
Keep it moving.
Comment on what your guest just said before moving to the next topic. It would be great if you could also weave a new issue into your summary of their previous comment to help bridge them to the new issue. If they mention contributing to a project, acknowledge it: “That bug fix sounds like it was pretty complex. How did you approach that with so little information and no time?” You’ve summarized their comment and added a new bit in the hopes of moving them along if the next issue is a logical next step or somehow related. If things are dragging along too much on any given subject, though, you may need to shift topics more assertively because bridging isn’t possible. Just be direct: “That’s great. Really cool experience. Ok, let’s move on to the community. Talk about your work with your local user group. I’ve heard you are running the JUG now.”
If they keep going off on tangents about something unrelated, gently redirect: “That’s interesting. Hold that thought. I want to go back to your contribution process first…” Or even more direct, “Wait, go back. That was interesting.” Use their input to steer the conversation smoothly in the direction you want to go or to keep them moving along their path efficiently. If they casually mention mentoring and then move on to something else without saying much, make a mental note to ask about mentoring next. This keeps things organic and layers issues in some logical way. Now, there are cases when you don’t need to respond to topic shifts. Their answer just ends a good sequence really well, and maybe you can provide some silent space and some body language to move along. Watch skilled interviewers. They do this more than you realize.
And finally, try to keep the conversation going fluently by directing your guest to comment on specific issues rather than always asking question one, question two, question three. Weave in some open statements like, “You mentioned you’ve contributed to the Linux kernel as well as OpenJDK. I thought that was interesting. Tell me more about that.” In other words, you aren’t even asking a question here. You’re getting people talking by making statements or directly telling them to comment on something. Think about normal conversations with your friends. They’re based on a variety of free-flowing questions, statements, prompts, and body language. No one likes a formal Q&A session. Mix it up so the discussion is as natural as possible.
Asking Better Questions
Simple is best.
Keep it simple! Ask one question at a time. Or if you ask two make them directly related in a string where one builds on the other to add more clarity. Don’t ask disparate or compound questions! This only causes stress as the guest, the audience, and you try to keep track of your too-cute “three part” question. I see people ask these compound questions all the time: “How did you get started with OpenJDK, and what was your testing process, and also how did that work connect with your user group experience?” Nobody can answer that well, especially if you’re doing a live interview at a busy conference with a microphone right under your guest’s nose and a camera focused on their face. Where would they even start? Your guest won’t appreciate the unnecessary complexity too, trust me on that. I’ve made this mistake many times.
Instead: “How did you get started contributing to OpenJDK?” Stop. Let them answer. Then follow up: “Oh, sounds like a great opportunity. What was your testing process like before you submitted your code?” Stop. Let them answer. Then follow up: “I see, ok, so from that code integration process you met the JUG leader since he was the gatekeeper on the project.” That’s not even a question but those statements summarize the story and encourage the guest to say something like this: “Yes, we had so many conversations getting that fix tested and integrated on a tight deadline that we became friends and she invited me to do a session describing the technical details at the next JUG meeting on contributing to OpenJDK.”
So, if there are multiple parts to an issue, break things up into multiple questions and statements and just talk them out to their natural conclusion. No compound questions ever! Don’t put that tracking burden on your guests or yourself.
Also, try using some open-ended prompts: “Tell me about that bug fix” rather than “Did you find it challenging?” The statement “tell me about it” opens things up, whereas the “challenging” bit narrows things down. Both are valid but know when to use them. Ultimately, you want your guests to describe situations and stories and entire sequences of events, not simply answering yes/no answers. Always encourage people to tell you about something. In other words, prompt them and then step back and give them some space to explore. Then you can judge how much time they need, and you can adjust and guide them where needed. The goal here is to get them to describe experiences they’ve had via short stories. That’s what makes it easy for them to speak articulately for longer periods of time because as they are speaking they are re-living the the experience. And that’s when their natural personality comes out.
If the issue is complex, you may need to get more specific: “Break down your testing framework as if you’re explaining it to a new engineer on the team. Just give me a few of the more important steps to follow.” Don’t expect them to give you the full task list from the manual to do an integration. But you can expect a top-level overview of a process just as they’d do in a normal conversation. And avoid leading questions like “Isn’t X process better for that issue?” Instead ask “What drew you to that approach?” to get more detailed responses. There’s no need to put them on the spot with your judgements. Plus, you may not like it if they come back and embarrass you with their response! Remember, this is a conversation, not a competition.
Getting Good Stories
Everyone loves a story.
Before you start recording, ask your guests to think about a few stories they can tell. It’s good to have this conversation before the interview so they have some time to think about blending some stories into the overall themes of the conversation. You need details in responses, of course, but those bits should be expressed through a series of situations or short stories. This is why you don’t need to provide specific questions up front. Just offer your guests broad topics for discussion and let them wrap their content into their own personal stories. Once the story starts, you can listen if it’s flowing well or insert some quips to move things along in whatever direction that’s necessary.
Funny disasters work great as stories. “Tell me about that time you accidentally took down the bank on day one” or “What’s the worst bug fix you’ve ever integrated on a Friday afternoon?” A few dramatic stories in a conversation can go a long way to making things interesting and less stressful for both parties. These kinds of stories reduce stress and provide the audience with relatable, genuine, and memorable experiences. But be careful with the disasters. Make sure that everything worked out ok because you don’t want to surprise them on a live interview if something really terrible happened.
Also, when people tell real stories, their whole demeanor changes. Watch for this and encourage it with your own body language. They may get more animated, more detailed, more authentic. They light up! Watch how they come alive right in front of you! The technical stuff is important, but the human stories are what make people want to keep listening.
Push for vivid details.
If possible, ask questions that create scenes and narratives. Weaving in the five human senses (hearing, touch, sight, taste, smell) is a helpful technique. “What was it like in that room when you realized what happened? Who else was there? What did they say?” Probe for how things were felt. Also, directly ask your guests to take you there: “Wait, go back. Take me into that scene. What was it like when you first heard you were nominated and approved to be a Java Champion? You were on the keynote stage in front of everyone. Wow!” Get them to talk about the situation by reliving the memory. They’ll love it. What was on their screen when the system crashed? How did their team react? What did they do when they were organizing the event when the hurricane hit and blew trees into the conference center? Things like this. Thinking in terms of human and natural elements makes stories that have technical details more engaging.
Managing Different Comfort Levels
Being interviewed is a unique experience.
Recognize that being interviewed is a different skill than presenting a session. I’ve seen some famous developers who regularly present at big conferences in front of thousands of people who actually feel and look noticeably uncomfortable being interviewed. And this makes sense. They don’t have a laptop in front of them. They’ve not rehearsed the discussion. They’ve not been media trained. They don’t have control! Don’t assume they’re skilled at this specific task of recorded or live, free-flowing conversations, especially when you stick the microphone under their nose for the first time. One time I was at a conference streaming some interviews, and the guest wanted to use his laptop and show his slides. He just had no confidence that he could take his content and turn it into a verbal conversation. It happens. And it’s your job to manage this problem.
Make it a habit to put all your guests at ease right up front. Frame it as a fun chat to share their story with the community. Tell them this is a mutual discussion, not a journalism interview. We’re having some fun here! That’s it. Let them know that pauses are fine, stumbles are normal, and you can always edit things out later if something breaks. I often mention that I mess up my own introductions half the time, which helps them relax. And when I wreck their names in the first five seconds that leads to laughing. False starts are normal for Zoom interviews and are easily edited out. But if it happens when live streaming, have a handy tool to re-start on the fly: “Oh, wait, I messed that up, say your name again? Oh, wow, I was really off, eh?” And laugh. But don’t keep laughing. Move on fast. We’re all human. Making mistakes appear normal is the best way to adjust when doing things live. Just prepare accordingly.
Let Them Ask You Questions
Turnabout is fair play!
Encourage your guests to occasionally ask you questions too! This is a great way to ease nerves and sometimes leads to unexpected insights as it puts you as the host in the position of answering a question. During interviews when someone asks me about trends I’m seeing in the community or my experience with building Open Source communities, it often sparks great follow-up discussions. Don’t hog the microphone, though. Get in, move it along, get out.
And don’t be surprised if you feel uncomfortable when this happens! Remember, asking questions isn’t the same experience as answering them! There are many skilled interviewers who aren’t that good at being interviewed! So, characterize the interview as a conversation: “This is just us chatting about your work, so feel free to ask me anything as we move along.”
Know When to to be Quiet
Shut up!
Try not to speak too much throughout the interview. The guest should be talking about 70% of the time with you prompting them all along the way. You need to find a balance where you can insert yourself in the discussion to offer context to keep things going. Adding a comment here and there to give them a break is also fine. They will appreciate the time to relax. But if you talk too much, the interview will look and sound awkward because the guest will be sitting silent too long and they may look uncomfortable. This is even more awkward when you are doing a live standup hogging the mic and your guest just has to stand there. Very few guests can handle this so don’t put them in this situation. It’s your job to learn how to stand silent while they are doing the majority of the talking. This is where body language comes in really handy. You don’t actually have to stand still. You can move around a bit so your body language helps promote the conversation.
Also, don’t try to one-up your guest. Yes, interviewers do this. It’s amazing. If they tell you about a major outage they caused as their best outrageous story, don’t follow with your own outage story that tops them. Instead: “Wow, that sounds intense. How did you recover from that in such a short time?” Or if you did have a similar experience and want to contribute the story, you could say something like this: “Oh, I ran into something like that, too, so I can relate. But yours was worse!” And laugh. Remember, the guest is the focus of the discussion, not you. You can regularly check the ratio of your voice vs your guest’s voice in any audio editor by just looking at the two wave forms. Yours should have lots of silence throughout the interview, but when you talk it needs to matter.
Sound Quality Matters
Good sound and solid projection.
Although this post isn’t about gear, which requires its own dedicated post, here’s a quick reminder that the sound quality is more important than perfect video when doing podcasts. For remote interviews, insist on decent microphones or headsets. There are many perfectly affordable USB mics that require no setup. They need to be used. I’ve postponed and even canceled interviews when the audio quality was too poor. You can only fix so much in post. And since your goal is to make your guest look good and provide some entertaining content for the community, having bad sound in 2026 isn’t acceptable. It doesn’t have to be perfect. But it can’t be bad.
Also a sensitive issue related to sound is having to ask guests to assert themselves more. It’s fine to have a headset or a good microphone, but if your guests are too shy to project their voice that’s an issue too. So, just gently ask for more energy! You want them looking and sounding good. Hopefully, they’ll appreciate the thought. Most do. I’ve had to make this request a few times because some developers are naturally shy. But most times you can manage the low energy issue by asking better questions, and asking them to tell stories based on their own personal experiences. The story is the key. That’s what bring out their natural personality. Do that and most projection issues go away.
Handling the Tricky Stuff
Preventing conflicts.
To prevent people from potentially stumbling on sensitive topics like community conflicts, political issues, or competitive corporate products, just mark these issues out of bounds from the start of the interview. No exceptions. I always make this request, and I’ve never had a guest disagree. We are fortunate that our companies allow us to mix freely in open development communities using company resources, so we ought to keep our conversations focused on the things that are openly approved for public discussion.
After It’s Over
We’re done.
Send thank-you notes and let your guests know when the episodes will be live. Encourage them to share it with their networks since developers are obviously well-connected in their communities. Asking for feedback is always nice too. If you don’t want to send a mail afterwards because everyone already has too much mail, that’s fine. Just thank your guest after the conversation and give the publication details. In other words, don’t just end the live interview and disappear. Stop the recording and chat freely for a few minutes to properly say goodbye and wrap up any final details.
The best developer interviews feel like conversations between colleagues, not formal Q&A sessions. When you get it right, you’ll walk away having learned something new, and your audience will feel like they just spent an hour with someone they’d love to grab a coffee with and talk about some code.
Interviews on Java, MySQL, Cloud, Database, and FOSS. Taiwan 2019.
Here’s the article from above stripped down into a short checklist.
Before You Hit Record
Initial Contact
Send email explaining format (video/audio), duration, and general topics to set clear expectations and reduce guest anxiety.
Do a quick pre-call if the topic is complex or the guest seems nervous so you can uncover interesting stories and build rapport.
For Zoom interviews: start recording 15 minutes after joining to chat informally about their latest projects first. This helps guests relax and organizes your thoughts.
For live on-site: prep right before recording if the guest is experienced, but allow more time for those who are less comfortable on camera.
For complex events (panels, keynotes): layer preparation over multiple touchpoints including emails, group meetings, and rehearsals to ensure everything runs smoothly.
Tell guests general topics but don’t provide specific questions to preserve natural, spontaneous responses.
Set boundaries on off-limits topics (politics, competitive products, community conflicts) from the start to prevent uncomfortable moments.
Research
Check GitHub accounts for recent commits to understand their current technical work.
Read their blogs and articles to learn their communication style and key interests.
Review conference talks and presentations to identify topics they’re passionate about.
Research user group involvement and activities to understand their community contributions.
Check recent X, LinkedIn, or mailing list posts to stay current with their latest discussions.
Find interesting threads to explore during conversation so you can demonstrate respect and build a genuine connection.
During the Interview
Opening
Pre-plan your introduction to start efficiently, especially critical for live streams where you only get one take. But have a transition tool if you do mess up the live stream opening.
Jump straight into content after brief introductions. Don’t waste time with forced small talk.
Start with their recent work or achievements to engage them immediately with familiar territory.
Skip lengthy small talk and forced jokes that create awkward energy instead of authentic connection.
Listening
Actually listen in real time. Don’t plan your next question while they’re talking or you’ll create disjointed exchanges.
Use checklists to free your mind from technical worries (camera settings, recording status) so you can focus on the conversation.
Paraphrase what they said to show you’re following and encourage them to elaborate further.
Use body language and verbal cues (“That’s cool!” “Wow!”) to signal genuine interest and keep energy flowing.
React authentically to keep the conversation flowing. Forced reactions are obvious and create distance.
Bridging and Flow
Comment on what they just said before shifting topics to create seamless transitions.
Weave new issues into summaries of previous comments to bridge naturally: “That bug fix sounds complex. How did you approach it with so little time?”
Redirect gently if they go off on tangents: “That’s interesting. Hold that thought. I want to go back to your contribution process first…”
Use open statements, not just questions (“Tell me more about that”) to create conversational flow rather than interrogation.
Make mental notes to circle back to casual mentions they didn’t fully explore.
Mix questions, statements, prompts, and body language to make the conversations flow well. This isn’t a Q&A session.
Questioning
Ask one question at a time, or at most two directly related questions that build on each other.
Never ask compound or disparate multi-part questions that stress out guests, audiences, and yourself.
Break complex issues into multiple simple questions and guide guests through each part as they respond.
Use open-ended prompts (“Tell me about…”) instead of closed questions (“Was it challenging?”) to encourage storytelling.
Avoid leading questions (“Isn’t X better?”) and instead ask “What drew you to that approach?” for more detailed responses.
Guide them to explain complex concepts simply: “Break down your testing framework as if you’re explaining it to a new team member. Just a few of the top points.”
Let them answer fully before following up. Don’t interrupt their flow.
Story Collection
Ask guests beforehand to prepare a few stories so they have time to think about blending narratives into conversation themes.
Request funny disasters or dramatic moments (“Tell me about that time you took down the bank on day one”) to reduce stress and engage audiences.
Push for vivid sensory details (what they saw, heard, felt) to create scenes that draw listeners in.
Ask them to “take you into that scene” to get them reliving the memory rather than just reporting facts.
Encourage them to describe moments: “What was it like in that room when you realized what happened? Who was there?”
Focus on human elements, not just technical details. Watch how guests light up and become animated when telling real stories they’ve experienced.
Guest Comfort
Recognize that being interviewed differs from presenting. Even experienced conference speakers may feel awkward without slides or rehearsals.
Frame the interview as a fun chat, not a journalism interview. “This is a mutual discussion. We’re having fun here.”
Reassure that pauses/stumbles are normal and editable to create a safe space for authentic responses.
Share that you mess up too (introductions, names) to help them relax and feel less pressure.
Create safe space for authentic responses, especially for guests who aren’t media trained or don’t have control like they do in their presentations.
Adjust for guests who aren’t media trained. Don’t assume they’re skilled at free-flowing live or recorded conversations.
Role Flexibility
Encourage guests to ask you questions to ease nerves and spark unexpected insights.
Characterize the exchange as a two conversation, not a one way interrogation: “This is just us chatting about your work, so feel free to ask me anything as well.”
Expect to feel uncomfortable when you yourself are answering their questions! Asking questions is a different skill than answering them, even for experienced interviewers.
Managing Your Airtime
The guest should speak about 70% of the time with you prompting them along the way to keep things moving.
Insert yourself only to provide context or keep things going. Add comments here and there to give them breaks.
Don’t one-up their stories. If they share a major outage story, respond with “That sounds intense—how did you recover?” not your own outage tale.
Stay silent while they talk during live standups. Hogging the mic makes guests look uncomfortable standing there on camera. It’s your job to stand there and NOT look uncomfortable when you are not talking.
Check waveforms in post-production. Your waveform should show lots of silence.
Sound Quality
Insist on decent microphones or headsets for remote interviews. Affordable USB mics require no setup and must be used.
Postpone/cancel if audio quality is too poor. You can only fix so much in post-production, and bad sound is no longer acceptable.
Gently ask guests to project more energy if needed. Many developers are naturally shy but you want them sounding good.
Use headphones to monitor audio in real time so you can catch problems before they ruin the recording.
Closing
Plan your exit strategy because every conversation has a natural lifespan and you need to get out before energy dies.
Tell guests upfront you’ll ask for final thoughts so they can prepare something meaningful to end.
Use: “Before we wrap up, anything else to add? Any plans coming up?”
Keep your closing concise. Don’t drag it out with lengthy summaries unless it feels natural.
Thank them and provide episode release date to maintain clarity and goodwill.
Get out before energy dies because it will be obvious to listeners if you linger too long.
After the Interview
Follow-Up
Send a thank-you note to reinforce goodwill and maintain professional relationships.
Confirm episode release date so they know when to expect and share the content.
Encourage sharing within their networks since developers are well-connected in their communities.
Ask for feedback (“Any suggestions for how I could make these conversations better?”) to build long-term relationships and to learn yourself.
Or: Skip the final email. But don’t just disappear. Stop recording and chat freely for a few minutes to properly say goodbye
Maintain momentum for future collaboration and potential referrals to other interesting guests.
Obviously, this isn’t an exhaustive list of issues to consider. But it’s a good start. Cheers.
Here are all 77 podcasts I did for Duke’s Corner from 2022 to 2026. It was my great pleasure to interview all of these wonderful Java developers who spoke so passionately about the technology and the community over the years. All of your stories were amazing and inspiring! I loved every single conversation! Sadly, though, for me it’s all over now. Must make way for prompts and inference, I guess. But maybe we’ll meet again sometime soon. And thank you for all the nice comments on LinkedIn and X. Duke’s Corner Podcasts: https://grisanzio.com/duke/
Here’s the sixth and final interview I did at JavaOne 2026 back in March. Carlos is a Java Champion and also the founder of Bogota’s Java User Group, Bogotá JVM. Carlos has been running monthly meetups for over a decade, and he and his colleagues have built one of the most active developer communities in Latin America. In his session at JavaOne — Teaching Java as a First Language: Lessons from Three Years of a Real-World Bootcamp — he outlined a free, online, 13-week week program for learning Java. The bootcamp started in Colombia but then quickly expanded to include multiple JUGs in Latin American.
“Java is the best language for this” he said. The community, the tooling, the syntax, the readability of the language itself — everything pointed in the right direction. And the students in the bootcamp agree. “They love Java” he said. Carlos started out programming in C++ in school, but from the moment he finally picked up Java it was obviously different. “It was Love at first sight” he said.
Carlos also advises that developers embrace AI. “Think of it like your pair programming buddy,” he said. But he said to go deeply into programming fundamentals first because if you can’t evaluate what the AI produces then you may end up shipping bugs you don’t understand.
JavaOne was an amazing experience for Carlos. It was his first JavaOne, but he’ll be back for sure.
Here’s the fifth interview I did at JavaOne 2026. Cristian Schuszter is a PhD in systems engineering and a Tech Lead at CERN in Geneva. He’s been at CERN for 8 years, but he’s been coding since he was eight years old. He loves working with and contributing to the Java community and other Open Source projects. This was Cristian’s first JavaOne, and his session, “30 Years of Java Development: Keeping it All Together,” covered how CERN keeps Java running across teams since 1998. Like any large company, CERN uses a lot of legacy code supporting systems that, in Cristian’s words, “need to keep running.” Java is not only used for business critical applications at CERN but also for accelerator system operations. On working at CERN among Nobel laureates, Cristian said, “I felt like I thrived in this kind of environment.” Cristian also helped revive the Voxxed Days developer conference at CERN and started the CERN Java User Group.
