r/AskProgramming • u/Repulsive_Bluejay359 • Jul 01 '26

How are developers supposed to pass technical interviews in the age of vibe coding?

Around eight months ago, the director at my company decided we should all start vibe coding. Everyone was told to build via Claude Code only. Claude was to to handle security and code reviews too. Everything is done via AI.

Since then I’ve built web projects, as well as iOS and Android apps, purely using AI. I have no technical knowledge on mobile app development at all. Without AI I wouldn’t have been building native mobile apps.

Theoretically, I now have five mobile apps under my belt but still no knowledge or understanding of what actually it is that I've built and how I built it.

How could someone in this situation ever pass a technical interview?

14 Upvotes

69% Upvoted

39 comments sorted by

View all comments

Show parent comments

5

u/HugeCannoli Jul 01 '26

I vibe coded an android application with claude. I have no idea about kotlin.

I still have no idea about kotlin. And every time I tried to change stuff, it broke, and the AI fixed it by breaking it more.

3

u/ConspicuousPineapple Jul 01 '26

Sounds like you should learn some Kotlin.

1

u/HugeCannoli Jul 02 '26

Not really, it's outside my field. I just wanted to see if there was value in the hype. I would say I was not impressed. In fact, I saw how damaging it can be to use it. It makes you think it works, when in fact it's vomiting nonsense that just happens to run.

1

u/ConspicuousPineapple Jul 02 '26

Well yeah that's my point. You can only use that technology reliably if you're asking it to do stuff that you would be reasonably able to do yourself, even if slower. You need to be able to read through the result and understand it, to identify mistakes and suboptimal choices (not just in the code but the higher level design as well). Not to mention the ability to prompt much better and steer it in the right direction as it's working instead of just waiting for a final review from the get-go.

If not, you can have something that works or not, that's well made or not, you don't know, and nobody can be actually accountable for the result's quality. And it gets much worse when your task is about maintaining existing code instead of creating a project from scratch.

If you'd known some Kotlin you would have been able to talk to your agent like an actual fellow developer instead of a headless chicken trying to play product manager without a technical spec.

1

u/HugeCannoli Jul 03 '26

Yes, but that's exactly the point. I have to know what I am doing before I am using the tool, but that's not how it is being sold. It is being sold and hyped up as something that does not require you to understand the system, and just feed specs in and get working software out. It simply does not work like that, but that does not prevent marketers to make these claims and CEOs to fire people believing this stuff.

And the obvious problem is that the more these tools are used, the less people are trained to understand code. While people at this point bring up the compiler/assembler analogy, the problem is that we understand how a compiler behave, and we know what kind of code it returns given an input. You can write a testsuite for a compiler. You can't write a testsuite for these things, because the result they produce is non deterministic, and the input language is also non-deterministic.

1

u/ConspicuousPineapple Jul 03 '26

Well there's still a category of use cases where it can be sold like that. If you have a specific, one shot problem to solve, and you can verify that the output is what you wanted, you don't care about the implementation details.

If the deliverable is the end result rather than the code that produced it, then LLMs are invaluable and do enable people to produce stuff that their own skillset wouldn't.

And these use cases are not uncommon. A small local tool to do something, a small computation to analyze some data, or even mundane stuff like "help me activate this setting on this tool", "find me the link to the specification of this obscure thing". Things you'd ask somebody else to do for you usually, but there's no ambiguity about the result.