If anyone can vibe code, how will companies decide who to hire?
Today, traditional engineering interviews often revolve around DSA (Data Structures and Algorithms).
And while DSA tests analytical rigor, it also wires thinking into strict, logical frames.
Creativity lives outside those frames.
Problem-solving and creating experiences are two entirely different games.
And sometimes, forcing a purely analytical mindset can quietly erode creative instincts — the very instincts vibe coders thrive on.
Which raises a bigger question:
Is the future of technology moving into the hands of more imaginative, creative builders — rather than traditional analytical problem-solvers?
The landscape is shifting.
Tomorrow's tech leaders might not be the ones who solve problems the fastest — but the ones who dream, imagine, and build experiences that feel alive.
Let’s Explore Together:
If you were designing a hiring process for vibe coders, what would it look like? (Ship a product? Solve a challenge? Collaborate with AI?)
Is vibe coding a new skill category — or just a shortcut?
Would traditional engineers embrace vibe coders as peers, or view them as outsiders?
Is technology becoming less about technical mastery and more about creative fluency?
What new “thinking muscles” will the next generation of builders need to develop?
The future is unfolding fast — and it’s about to get wildly more creative.
Replies
I disagree with your premise that forcing an analytical mindset erodes creative instincts. Software engineering always starts with imagination. We dream and imagine the product, how it should work, and then the analytical process begins to code it. To make it exist.
Vibe coders are creative. I was hesitant to accept it at first, I'm in that traditional engineer group, but I honestly don't think it changes anything about our profession. We can implement things faster through vibe coding, but the job is the same. Imagine the product, design the technical architecture, and code it. And if you're prompting an AI to contribute to all of these phases, I need to trust your knowledge to trust that you can properly evaluate the code that's produced by AI.
It will be this way at least until AI can do it all on its own. When that happens vibe coders and traditional engineers alike will be gone :)
Kalyxa
@appsforhumans I really like your take on this — especially the point about imagination being at the core before analysis even begins.
You're right: whether it’s traditional engineering or vibe coding, the foundation is still vision first. Appreciate you sharing your perspective!
I think vibe-coding v1 is about going from brief to complete solution in one cut. And then you get what you get and its close to impossible to improve upon what you got. But I think vibe-coding, or even vibe designing, v2 is much more interesting. It will be about iterative vibing. going from zero to 0.1 then 0.2. etc. And that requires a lot of human-in-the-loop work. Which is a skill. Im doing vibe coding and vibe designing v2 today. But its fringy and buggy, and not ready for mass adoption. In any case. I wrote a bit about vibe designing yesterday here: https://eoncodes.substack.com/p/vibe-designing-with-cline-mcp-figma
Kalyxa
@sentry_co Love this perspective — especially the idea of iterative vibing over one-shot creation.
Can someone explain to me briefly, what is vibe coding? Because i cant really understand..
@haris_designer
You vibe with the AI and code comes out.
Check out loveable.dev or cursor for examples. Basically you tell an AI what you want, AI codes it, you tell it to fix what's broken, and repeat until you have a product. It is... not for me.
There are methods for making it perform better so it writes code with less issues. I've heard if you converse with the AI to design the software architecture, then it will do a decent job of implementing that architecture. Things like that. But basically it's vibe coding is just talking with AI and letting it code for you.
@haris_designer It's a form of coding where you (the human) provide the LLM with requirements and feedback - and it builds a software application to your specs.
The human does minimal "computer programming," perhaps none. The implication is that a non-coder human can produce a working application, even a fairly sophisticated one, that calls multiple SaaS API.
I do know how to code, but in a hackathon, I vibe-coded with Windsurf (Claude 3.7 under the hood) to produce a working MVP within a few hours.
I think interviews will slowly be more similar to the real job positions than they are right now. Instead of asking to scaffold a project or do some minor things in a very tiny project, I think it will be more related to understanding a big project and debugging and fixing small and scoped bugs in it. And I don't think vibe-coding or AI would be a valid / fast solution here.
At least, that's how I was approaching hiring when I needed a software engineer!
@david_camacho_cateura1 I've hired a few good software engineers solely on a conversation and discussion about projects and technologies. I've been in the field for 10 years, but it was my first time being on the interviewer side. My opinion is that I can tell the difference between someone who knows what they were talking about or not.
A little pop quiz about specific technologies that we're using. If they're not familiar with it that's completely fine, then I look for common ground we can talk about, or I have them explain their domain to me. We'll talk about the software ecosystem in these domains. My feeling is that only someone with appropriate experience will be able to talk about them knowledgeably, share their frustrations, discuss trustworthy resources to use when working on a problem, all those things that come with software engineering. Usually the discussion will show how much real experience they have. Not years of experience, but actual hands on experience. It is my firm opinion that one can work in the industry for years and still not have suitable experience for a particular role.
The gist is if I feel like I'm talking to a peer in the industry, I'll recommend them to be hired. I don't really need to watch them code, that's like the most rote/mechanical part of the job. I do think coding standards are important, but we can work on that on the job.
Lancepilot
I think companies will start caring more about what you can actually build rather than how well you pass a coding test. If you can ship real things that people want to use, that’s going to matter way more than just solving algorithms. The future feels like it's about creativity + execution, not just technical perfection.
Interesting discussion. I used stackoverflow all the time to help with my coding. Was I vibe-coding with stackoverflow? I havent been to stackoverflow since I began using AI to help with my coding. I don't think of it as good or bad, but as a way to accomplish my goal, which was building the project as quickly and as best possible.
As another user said, "I think companies will start caring more about what you can actually build rather than how well you pass a coding test. " I think they will look at your portfolio and make a decision that way. And whatever keeps the costs the lowest!
Kalyxa
@russellsyellow Totally relate to this. I used to live on StackOverflow too, but once I started using AI tools, it became more about staying in flow than searching for exact answers. It’s not about “cheating” or skipping the hard parts — it’s just a new way to solve problems faster.
And yep, I agree — portfolio > test scores. If you can ship real, working stuff, that says more than passing a timed algorithm round ever could.
I just discovered there's a term for what I've been doing apparently. As one of these "vibe coders" I would personally not hire one unless they have actual knowledge about code and development.
As a 20+ year graphic designer, I know just enough about code to get AI to build some slick apps for personal workflows or more robust needs. But when it breaks, I'm often spending gratuitous amounts of time getting a fix because I don't know foundational information to know where to even start with most issues. I also don't know what I don't know, so I would never assume my code is robust enough to handle users across multiple devices, be able to trouble shoot their bug issues efficiently, or even know how to prep the code for launch at industry standards.
Right now, for all of the above, I rely entirely on googling or other AIs, often giving my Claude code to Mistral, CoPilot, GPT, Grok, and/or Gemini and seeing who can solve the problem first. I'm at their mercy, so if they're wrong or missing something (which they regularly do), I wouldn't say it's a great plan as an employer to go this route with people such as myself. They also tend to break things when fixing things, so it prolongs the resolution. (Although, it's kind of like asking a coding question on Reddit, you'll get all sorts of answers to try more than a unified solution.)
In the hands of a trained coder, or perhaps on a team with "traditional" oversite, though, I think vibe coding could have great upside, but only if vibe coders can somehow prove what they build is "better" by some measurable metric.
Totally agree that it's easier than ever to prototype something now. But getting that same project production-ready (secure, scalable, reliable) still takes a serious deep dive. I built my first client-only iOS app in 2 days like 6 months ago. My second one was a full-stack app and has taken two months of hard work using more advanced models. When I ask cursor about database security, I am in the top 1-2% of full-stack mobile apps. So problems that are associated with vibe coding can be solved with a good amount of effort. Also, finding the right tech stack still takes a lot of trial and error.