> Voice-to-voice (thought-to-thought, maybe?) interaction with your coding agent — conversational Claude Code, not just voice-to-text input — is a natural next step.
Maybe it's just me, but I don't see the appeal in verbal dictation, especially where complexity is involved. I want to think through issues deliberately, carefully, and slowly to ensure I'm not glossing over subtle nuances. I don't find speaking to be conducive to that.
For me, the process of writing (and rewriting) gives me the time, space, and structure to more precisely articulate what I want with a more heightened degree of specificity. Being able to type at 80+ wpm probably helps as well.
The power of voice dictation for me is that I can get out every scrap of nuance and insight I can think of as unfiltered verbal diarrhea. Doing this gives me solidly an extra 9 in chance of getting good outputs.
Stream of consciousness typing for me is still slower and causes me to buffer and filter more and deliberately crafting a perfect prompt is far slower still.
LLMs are great at extracting the essence of unstructured inputs and voice lets me take best advantage of that.
Voice output, on the other hand, is completely useless unless perhaps it can play at 4x speed. But I need to be able to skim LLM output quickly and revisit important points repeatedly. Can't see why I'd ever want to serialize and slow that down.
Soon there's only going to be one way to prove you're human online: Write with an eloquent combination of hate speech, racial slurs, and offensive language.
You're assuming the question has to even be that difficult. I've proctored sessions for senior-level webdev roles where the questions were akin to "baby's first React component" -- write a component that updates a counter when you click a button. So many candidates (who purported to be working with React for years) would fail, abysmally. Not like they were just making small mistakes; I didn't even care about best practices -- they just needed to make it work. So many failed. Lot of frauds out there.
I think some of this is probably attributed to being maintenance devs who don't build a lot of greenfield stuff. I got this way in one of my past jobs. I think us as devs really need to practice creating things from scratch from time to time. Working out those kinks is a good skill (less with AI) but also good practice for those baby components you'd need to make in an interview.
When I did tech interviews, I used to think I could just jump right in with an intermediate level question and go from there. But the reality is that most of the candidates I interviewed couldn't even answer a trivial question that just required a basic for-loop with an if-statement inside it. These are not pressure-cooker interviews where they need to balance a binary tree while having Baby Shark blasted at them on full volume. These are chill interviews where I ask them to iterate through a string and tell me where the first "x" character is.
There are so many software engineering candidates who literally cannot write the simplest code. I even had someone actually say "I don't really write code at my current job, I'm more of a thought leader." Bzzzzzt.
I've always prepared what I called level 1, level 2, and level 3 questions ready for candidates. But, I almost never even got to level 2, and never in 20 years of interviewing got to my level 3 questions.
I always wonder when people tell these stories exactly what the metric is.
I've been around the block for over 3 decades. I've had a number of high level positions across both IC and management tracks. These days I'm very hands on keyboard across a number of clients. If you asked me to write a basic for loop or if statement, there's a small chance I'd flub the exact syntax if writing on a whiteboard. Both because I bounce between languages all day and wires get crossed on the fly, but also the standard interview pressure type arguments. Whereas if the test is "does this person understand what a for loop is and how it works?", then yes, I can easily demonstrate I do.
In real life I'm not going to take an interview where there's not already that degree of trust so if that questions comes up something is already wrong. But I'm sure there are interviewers in the world who'd fail someone for that.
TBH I'm like that, but how hard could writing a React component be? I'm not even a React programmer but I can probably write working code on a whiteboard.
The best candidates would have that question wrapped up in 5 minutes. Like they're not even having to think about it, which is honestly all I cared about testing for -- do something really easy really fast so I know you're not BSing me, and then we can move on to just having a conversation about your past experience.
One of the worst guys took 20 minutes, with me having to coach him through it the entire time. It was a true exercise in patience, but I don't mind helping people learn new things. When he got his rejection email, he actually complained to the recruiter because he thought he did really well. Dude...
My version of fizzbuzz (I'm in backend/ML/NLP) is counting how many times each word appears in a string. Literally `return Counter(text.lower().split())` but it's totally fine if you want to do it in a for loop or whatever, as long as you can fluently write an incredibly simple function.
Yep, that was actually a placeholder (eventually with real people, and now soon with 500 downloads!) I didn’t comment out properly hence what someone else pointed out with the html commenting. Mistakes happen and I agree I should do a better job to proof read :)
This is objectively wrong.
reply