DEV Community: Oleh Volostnykh

I Just Defended My Bachelor's Thesis. Was University Worth It?

Oleh Volostnykh — Fri, 19 Jun 2026 17:04:53 +0000

I defended my bachelor's thesis today.

A few hours ago I was standing in front of a committee, answering questions about research I'd spent months on. Now it's over. The degree is done.

And somewhere between the handshakes and the walk home, the obvious question surfaced: was it worth it?

I've been in tech long enough to know this is a loaded question. There are people who will tell you a CS degree is the only real foundation. There are people who will tell you it's an overpriced piece of paper and you should have been building on GitHub instead. Both camps are more confident than the reality warrants.

Here's my honest answer, written today of all days, while it's still fresh.

What university actually gave me

Let me start with the real value — not the stuff universities put in brochures, but what I actually walked away with.

A forcing function for breadth. Left to my own devices, I would have learned what interested me and ignored the rest. University forced me into subjects I wouldn't have chosen — statistics, business strategy, systems theory, organizational behavior. Some of it felt irrelevant at the time. Some of it turned out to be exactly the kind of thinking I use when making product decisions now. You don't know which is which until later.

The ability to learn structured, unfamiliar material under pressure. This sounds abstract until you're in your first job and someone hands you a 60-page technical specification and expects you to understand it by Friday. Surviving exams on topics you didn't choose teaches you something about how to process dense, foreign material quickly. That skill transfers.

Credentials that open certain doors. I'll be honest about this one. There are companies — particularly larger ones, particularly in certain European markets — where a degree is a filter. Not because it proves you can code, but because HR processes require it. Knowing those doors exist and deciding whether you care about them is a legitimate part of the calculation.

Time. Three years is a long time, and university gave me a structured environment to spend it in. I built IdeaPick during my degree. I started writing during my degree. I had space to experiment with what I actually wanted to do — not because the curriculum encouraged it, but because the degree didn't consume every hour of every day.

What university didn't give me

This list is also real, and worth naming plainly.

Production-level technical skills. I did not learn to build a Next.js app with streaming LLM responses, Row Level Security, and proper rate limiting in any lecture. The technical skills that make me employable as a frontend developer came from building things outside of class — personal projects, side products, reading documentation, making mistakes and fixing them.

How to ship. Universities teach you how to submit. There's a deadline, you hand something in, you get a grade. Shipping a product to real users — handling feedback, fixing things that break in production, making something that someone actually pays for — is a different activity entirely, and it's not in the curriculum.

How the industry actually works. The gap between academic software engineering and professional software engineering is wide. Version control practices, code review culture, incident response, how teams actually make decisions — none of this was covered in a way that reflected what I've experienced in real contexts.

Clarity on what I wanted. I went in hoping the degree would help me figure out what I was doing with my career. It didn't, really. That clarity came from building things, talking to people, and paying attention to what I couldn't stop thinking about.

The question nobody asks honestly enough

Here's what I think the "is university worth it" debate usually gets wrong: it treats the degree as the variable, when the real variable is what you do alongside it.

Two people can complete the same degree program. One spends the time attending lectures, passing exams, and doing the minimum required. The other does the same lectures and exams while also building projects, writing about what they're learning, and using the structure of university as a container for a much larger program of self-directed work.

Those two people come out with the same certificate and radically different outcomes.

The degree is not what creates the difference. The habits, the projects, and the initiative do.

So the honest version of the question isn't "is university worth it." It's "what are you planning to do with the time, and does university help or hinder that?" For some people, a structured environment with deadlines and access to academic resources is genuinely useful scaffolding. For others, that same structure is a cage that slows them down.

Where I land

I don't regret my degree. I learned things I wouldn't have sought out on my own. I had time I used well — not because university told me to, but because I decided to. And the credential will matter in some contexts, even if it doesn't define me.

But if you asked me whether the degree was the most valuable thing I did in the last three years, the honest answer is no. Building IdeaPick taught me more about product, architecture, and user thinking than three years of lectures. Writing consistently taught me more about communication than any academic paper.

The degree was the frame. The work I did inside and around it was the picture.

If you're deciding whether to go — or whether to finish — I won't tell you what to do. The answer depends on what you want to build, who you want to work for, and how you learn best. Those are questions only you can answer.

What I'll say is this: wherever you are, the credentials matter less than the work. The work is what follows you.

Did you go to university? Do you think it was worth it for your tech career — or would you make a different call if you were starting again today?

How I Validate My App Ideas

Oleh Volostnykh — Sat, 13 Jun 2026 19:01:51 +0000

The most expensive mistake an early-stage developer can make isn't writing bad code. It's writing good code for something nobody wanted.

I learned this the slow way — by building things, shipping them, and watching them land with silence. Eventually I stopped treating validation as a step you do after you're excited about an idea, and started treating it as the thing that decides whether the idea deserves your time at all.

Here's the process I actually use now, before any code gets written.

Step 1: Talk to actual humans before you talk to yourself

This is the step almost everyone skips, and it's the most important one.

Before building anything, I try to have real conversations with people who might have the problem I think I'm solving. Not surveys. Not polls. Conversations.

The goal isn't to pitch them on my idea. It's the opposite — I want to understand their current situation without mentioning my idea at all. How do they currently deal with this problem? What do they use? What annoys them about it? How often does this come up? What have they tried that didn't work?

If someone describes a real, recurring frustration without me prompting them toward it, that's a signal. If I have to lead them to the problem — "don't you wish there was a tool that..." — that's a different signal, and usually not a good one.

A few things I watch for in these conversations:

Do they bring it up unprompted? A problem someone is actively annoyed by comes up naturally. A problem that only exists when you suggest it probably isn't urgent enough.
What are they currently doing instead? "Nothing, I just deal with it" is a weaker signal than "I use three different spreadsheets and it's a mess." The second person has already invested effort into solving this badly — which means they'd likely invest in solving it well.
How do they talk about it? Frustration, specific complaints, war stories — these are good signs. A shrug is not. I try to talk to at least five to ten people before I take an idea seriously. Not because that's statistically significant — it's not — but because patterns start to emerge. If three out of seven people independently describe the same frustration in similar terms, that's worth paying attention to.

Step 2: Research competitors — and read between the lines

Once I have a sense that a problem is real, I look at who else is solving it.

The instinct here is often "if there's competition, the market is taken." I think that's backwards. Competition is evidence that people pay for solutions to this problem. The absence of any competitors is often a worse sign than the presence of several — it can mean the market is too small, the problem isn't actually painful enough, or someone already tried and it didn't work.

What I actually look for:

Reviews — especially the negative ones. This is where the real signal lives. I read through reviews of existing tools looking for recurring complaints. If multiple people are saying the same thing — "great idea but the onboarding is confusing," "wish it had X feature," "too expensive for what it does" — that's not just feedback for the existing product. That's a map of where the gap is.

Pricing and positioning. What are people actually paying for this? Is there a tier that's clearly underserved — too expensive for individuals, too basic for teams? Sometimes the opportunity isn't a new product, it's a different price point or a narrower audience for an existing idea.

How long competitors have existed and how they're evolving. A product that's been around for years and is still actively updated suggests a durable market. A graveyard of abandoned competitors might mean the problem is hard to monetize — or it might mean nobody executed well. Worth digging into which.

What they're NOT doing. This is the most useful one. Existing tools are often built for a specific audience or use case, and they tend to stay there — not because nothing else makes sense, but because pivoting is hard once you have existing users. That creates room for someone building specifically for the audience being left out.

Step 3: Find the gap — and be honest about whether it's real

This is where talking to users and researching competitors come together.

The gap I'm looking for is the overlap between "a problem people actually described to me" and "something existing solutions don't address well." When both of those point in the same direction, that's a real signal. When only one does, I'm more cautious.

A few honest questions I ask myself at this stage:

Is this gap big enough to matter? Some gaps are real but tiny — they affect a narrow slice of users in a minor way. That might be a feature for an existing product, not a reason to build a new one.

Why hasn't anyone filled this gap already? Sometimes the answer is "nobody's thought of it" — which is rare. More often it's "it's hard to build," "it's hard to monetize," or "the audience is too small to be worth it for existing players." Understanding why the gap exists tells you whether it's an opportunity or a trap.

Am I solving this because users need it, or because I find it interesting? This is the hardest one to be honest about. As a developer, it's easy to get excited about a technically interesting problem and convince yourself there's a market need to match. Sometimes there is. Often the excitement and the need are pointing in different directions, and only one of them pays the bills.

Step 4: Define what "validated enough" looks like — before you start

One thing I've learned: validation can become a way to avoid building, just as much as skipping it can lead you to build the wrong thing.

So before I start the process, I try to define what would make me confident enough to start building. For me, that's usually some combination of: a handful of people independently describing the same problem in their own words, a competitive landscape that shows people pay for adjacent solutions, and a specific gap I can articulate in one sentence without hedging.

It doesn't need to be certainty. It needs to be enough signal that building feels like a reasonable bet rather than a hope.

Why I ended up building a tool for this

After going through this process manually a few times — talking to people, digging through reviews, trying to keep track of competitor research across different ideas — I noticed the process itself was repetitive enough that I started automating parts of it.

That eventually became IdeaPick — a tool that takes an idea, pulls real competitor and market data, and generates a structured validation report: market gaps, competition signals, risks, and a starting point for the kind of research I described above.

It doesn't replace talking to real users — nothing does. But it does a lot of the competitor research and gap-finding legwork automatically, which means more time can go toward the conversations that actually matter.

The honest summary: ideas are cheap, and almost every idea sounds good when you're the one having it. The framework above isn't about proving an idea is good — it's about giving a bad idea enough chances to reveal itself before you've spent months building it.

How do you validate ideas before building? Curious what other developers and indie hackers actually do — or don't do — before writing code.

AI is Ruining Junior Devs

Oleh Volostnykh — Tue, 09 Jun 2026 14:16:04 +0000

Here's a scenario that's becoming more common than anyone wants to admit.

A junior developer gets stuck on a problem. Instead of sitting with it — reading the error, forming a hypothesis, checking the docs — they paste it straight into ChatGPT. They get an answer. It works. They move on.

This happens five times a day. Every day. For months.

On paper, they're productive. PRs are getting merged. Features are shipping. But something is quietly not happening: they're not learning to debug. They're not building the mental model of how the system actually works. They're not developing the instinct that tells you why something broke, not just what to paste to fix it.

And when the AI gives them a wrong answer — which it does, regularly — they can't tell.

The crutch you don't notice you're using

The problem with AI as a crutch is that it doesn't feel like a crutch. It feels like efficiency.

There's no obvious signal that something is wrong. The code compiles. The tests pass. The feature ships. The feedback loop that would normally tell you "you don't understand this yet" gets bypassed entirely, because the output looks correct even when the understanding isn't there.

Senior engineers can use AI tools heavily and stay sharp — because they have enough depth to evaluate the output, catch the mistakes, and direct the tool deliberately. They know what good looks like. They know when to trust the suggestion and when to push back.

Juniors don't have that depth yet. That's not a criticism — it's just where they are in the learning curve. The issue is that AI tools don't know the difference. They give the same answer to someone who understands the problem and someone who doesn't. And the junior who accepts the answer without understanding it isn't closing the gap. They're just hiding it.

What fundamentals actually means

"Learn the fundamentals" sounds like something a grumpy senior engineer says when they don't want to explain something. Let me be more specific about what's actually at risk.

Debugging instinct. The ability to read an error message, form a hypothesis about what caused it, and systematically test that hypothesis. This is not a skill you're born with. It's built through repetition — through being stuck, trying things, being wrong, trying again. Every time you skip that process, you miss a rep.

Mental models. Understanding not just that something works but why it works. Why a hash map gives you O(1) lookup. Why a useEffect with the wrong dependency array causes infinite renders. Why your database query is slow. These models are what let you reason about new problems you've never seen before — which is most of what senior engineering actually is.

Reading code. Real codebases are messy. They have naming that made sense to someone three years ago, patterns that evolved organically, and decisions that are only understandable in context. Learning to navigate that — to read code you didn't write and didn't choose — is a skill AI cannot develop for you.

Knowing when you don't know. This might be the most important one. Experienced engineers have a calibrated sense of uncertainty. When they're unsure about something, they know they're unsure. Juniors who've been leaning on AI often have the opposite — they're confident about things they don't actually understand, because the tool provided an answer and the answer worked.

The interview will find the gap

This is where it becomes concrete.

A junior developer who has shipped features for six months entirely on AI assistance walks into a technical interview. The interviewer asks them to debug a piece of code on a whiteboard — no tools, no autocomplete, no paste-into-ChatGPT. Or they ask them to explain why they chose one approach over another in a project they claim to own.

The gap surfaces immediately. Not because the candidate is unintelligent — but because the reps weren't there. The reasoning wasn't practiced. The mental models weren't built.

And the frustrating part is that the candidate often doesn't see it coming. The daily workflow felt productive. The code was shipping. Nothing in the feedback loop signaled that something was missing.

Until the interview did.

AI tools aren't the enemy — the habit is

None of this means don't use AI tools. That would be both impractical and unnecessary.

The tools are genuinely useful. They eliminate boilerplate, unblock syntax questions, suggest approaches you might not have considered. Used well, they make you faster at the parts of development that don't require deep thinking — which frees up more time for the parts that do.

The habit that's worth breaking is the one where AI is the first response to difficulty rather than a resource you reach for after you've attempted to think it through yourself.

Try to solve it first. Give yourself ten or fifteen minutes with the problem before opening a new tab. Form a hypothesis. Check the docs. Read the error message carefully, the whole thing, not just the last line. Then, if you're still stuck, use the tool — but use it to check your thinking, not to replace it.

That distinction sounds small. Over months, it's the difference between a developer who can reason independently and one who can't function without the assistant.

The developers who will be fine

The junior developers who are going to come out of this period well are not the ones who avoided AI tools. They're the ones who used them without outsourcing their thinking to them.

They shipped faster because of AI. They also spent time on hard problems without it. They read documentation. They debugged without pasting. They built things from scratch occasionally, on purpose, even when a generator could have done it in thirty seconds.

They stayed curious about the why, not just the what.

The market is hard right now. Getting a junior role is genuinely difficult. But the developers who build real depth during this period — even without a job, even while building side projects alone — are the ones who will be very hard to pass over when the market opens back up.

The gap between "used AI to ship things" and "used AI to ship things and still understands what I built" is enormous. And it's entirely within your control.

Do you have a rule for when you let yourself reach for AI and when you don't? I'm curious how other junior and mid-level developers are thinking about this.

Building a Startup Is Not Just About Having an Idea - Here's What Nobody Tells You

Oleh Volostnykh — Mon, 08 Jun 2026 18:07:30 +0000

There's a narrative going around right now that goes something like this:

Come up with an idea. Describe it to an AI. Ship a startup. Profit.

I get why it's appealing. Tools like Lovable, Bolt, and v0 are genuinely impressive. You can go from a blank page to a working UI in under an hour. That's real, and it's remarkable.

But I've been building my own product — IdeaPick, an AI-powered idea validation platform for indie hackers — for a while now. And I can tell you with some confidence: the idea is the easy part. What comes after is a different story.

This isn't a discouragement piece. Building something of your own is one of the best things you can do as a developer right now. But if you walk in expecting AI to carry you, you're going to hit a wall fast. Better to know what's actually ahead.

The myth: AI is the co-founder you never had

The pitch is seductive. You have an idea, you have AI, what else do you need?

In practice: quite a lot.

AI is an extraordinary tool for moving faster. It's not a replacement for understanding what you're building, why it matters, or how to make it work reliably. The developers who get the most out of AI tools are the ones who know enough to direct them, catch their mistakes, and step in when the generated output isn't good enough.

Which means the skills still matter. They've just changed shape.

Here's what building IdeaPick actually required — none of which "just have an idea" prepares you for.

Design — more than making things look pretty

You don't need to be a designer. But you do need to understand design well enough to make decisions.

What is the hierarchy on this page? Where does the user's eye go first? Is this button obvious enough that someone who has never seen your product before will know to click it? Does this empty state tell the user what to do next, or does it just look empty?

AI can generate a UI. It cannot tell you whether that UI actually guides a user through your product effectively. That judgment is yours. And if you don't develop it, your product will feel confusing in ways you won't be able to diagnose — because every screen looks fine in isolation and broken as a flow.

Design is also your first trust signal. Users decide within seconds whether your product feels credible. A generic, unpolished interface says "someone made this quickly and didn't care enough to finish it." That impression is hard to recover from.

Cybersecurity — the thing everyone skips until it's too late

This one is unglamorous and easy to defer. Don't.

If you're building any product that handles user accounts, you're responsible for those users' data. That means understanding authentication properly, not just copying an auth flow from a tutorial. It means Row Level Security on your database so users can only access their own data. It means rate limiting your API endpoints so someone can't hammer your LLM calls and run up your bill. It means input validation on everything that touches your backend.

I use Supabase with RLS on every table, Upstash Redis for rate limiting, and Zod to validate every single piece of data that comes back from an AI model — because AI outputs can be malformed, unexpected, or just wrong. None of that is optional. None of it is exciting. All of it is the difference between a product and a liability.

AI will generate code that looks correct and has security holes in it. Knowing enough to spot them is on you.

Business — because a product nobody pays for is a hobby

Building is the part developers are comfortable with. Figuring out who your user is, why they would pay, and how to reach them is the part most developers avoid — and it's the part that determines whether any of the building was worth it.

Some questions you need real answers to:

Who specifically is this for? Not "developers" — which developers, with which problem, in which context?
What would make them pay rather than use a free alternative?
How do you reach them? Where do they spend time, what do they read, who do they trust?
What does success look like in 90 days — and how will you know if you're on track? I built IdeaPick for indie hackers and solo founders because I am one. That specificity matters. "Everyone" is not a target audience. Trying to serve everyone is how you build a product that resonates with nobody.

You don't need an MBA. But you do need to spend serious time on these questions before you write the first line of code, and revisit them regularly as you build.

Programming — yes, still

This might be the most controversial point given the current hype cycle, so let me be precise.

You don't need to be a senior engineer to build a startup solo. But you do need enough programming knowledge to understand what your AI tools are generating, debug it when it breaks, and make architectural decisions that won't collapse under you six months later.

AI-generated code has a shelf life. It works for the happy path. The moment something unexpected happens — an edge case, a performance issue, a dependency conflict, an API change — you need to be able to read the code and understand what's actually going on.

In IdeaPick, I have 13+ LLM API calls, a streaming NDJSON architecture, a hybrid scoring system that combines deterministic algorithms with AI narrative generation, and state management that handles conversation history, partial streaming tokens, and multiple request states simultaneously. No AI tool designed that system end to end. I designed it, made the decisions, and used AI to move faster within those decisions.

If I didn't understand what I was building, I wouldn't have been able to make those decisions at all.

AI skills — yes, this is its own category now

Knowing how to use AI tools well is genuinely a skill, and most people using them are leaving a lot on the table.

Understanding how to write a prompt that gets a reliable, structured response. Knowing when to use streaming versus a single response. Understanding tool calling, structured outputs, and how to validate AI responses so your app doesn't break when the model returns something unexpected. Knowing which model to use for which task — and why using gpt-4o-mini for everything in IdeaPick made sense cost and quality-wise.

These aren't advanced concepts, but they're not obvious either. Treating AI as a magic box you talk to is how you end up with a fragile product that works in demos and breaks in production.

So why bother?

Because all of this is learnable. And learning it by building something real is the fastest and most durable way to actually learn it.

Every skill gap I listed above is one I've been closing while building IdeaPick. I didn't have all of it figured out when I started. I had enough to begin, and the product taught me the rest.

That's the honest case for building your own thing — not that it's easy, but that it's one of the few contexts where you learn all of these skills together, under real conditions, with real stakes. No tutorial gives you that. No junior job gives you the full picture that fast.

The idea gets you to the starting line. Everything else gets you across it.

Start with what you know. Build toward what you don't. Ship something — even rough, even incomplete. The skills accumulate faster than you think.

What's been the hardest skill gap to close in your own building journey — design, business, security, something else? Drop it in the comments.

The Job Market Is Rough. Here's Why I Started Building Instead.

Oleh Volostnykh — Thu, 04 Jun 2026 19:14:47 +0000

Let me be upfront about something.

When I say "build a startup," I don't mean raise a seed round, quit your job, and move to San Francisco. I mean something much simpler and much more achievable: build something real, put it online, and tell people what you're learning along the way.

That's it. That's the whole idea.

I know how that sounds. But hear me out — because the market for junior and graduate developers right now makes this less of an ambitious bet and more of a practical one.

The market is genuinely hard

If you're a recent graduate or someone switching into tech, you already know this. The entry-level tier has compressed significantly. Companies that used to hire juniors are now posting "junior" roles that expect two years of experience. The interview process has gotten longer and more exhausting. Ghosting after five rounds is normal. And AI tools have raised the baseline for what "basic" looks like, which makes it harder to stand out with a portfolio of tutorial projects.

Waiting it out — sending 50 applications a month and hoping — is a strategy. But it's a passive one. And it hands all the control to a market that isn't currently working in your favor.

What I did instead

I built IdeaPick — an AI-powered product idea generation and validation platform for indie hackers, solo developers, and early-stage founders.

The core loop: you describe your skills and interests, the app searches real competitor data, and generates grounded product ideas with validation scores, roadmaps, and a workspace to execute from.

Was it a moonshot startup idea? No. Was it a project that pushed me well beyond anything a junior job would have asked me to do? Absolutely.

Here's a partial list of what building IdeaPick actually forced me to learn:

Streaming UI — rendering LLM responses progressively via NDJSON, handling partial state, avoiding layout thrash
LLM integration at scale — 13+ separate model calls, each with Zod validation, structured outputs, and proper error handling
Hybrid scoring systems — combining deterministic algorithms on real App Store data with LLM narrative generation, so the model narrates instead of hallucinating metrics
Auth, rate limiting, RLS — Supabase with Row Level Security, Upstash Redis for per-IP and per-user limits, guest flows that convert on sign-in
Product thinking — onboarding flows, empty states, the difference between what users say they want and what they actually need None of that came from a tutorial. All of it came from hitting a wall and having to get through it.

The learning gap between a junior job and building something

A junior job teaches you how to work inside someone else's system. You pick up their conventions, their codebase, their deployment pipeline. That's valuable — genuinely. Working on a real team with real engineers is something building alone can't fully replace.

But here's what a junior job often doesn't give you: the full picture.

When you're a junior, tickets arrive scoped. Designs are handed to you. The architecture is already decided. You implement. You learn the layer you're touching and not much else.

When you build your own thing, there are no tickets. You make every decision — from database schema to color palette to whether the loading state should be a spinner or a skeleton. You face the consequences of every decision, which means you actually understand why certain decisions matter.

The learning is less comfortable. It's also deeper.

But here's the part most people skip: document it

Building alone is good. Building and documenting publicly is a different thing entirely.

Write about what you're building. Post updates when something works. Post updates when something breaks — especially when something breaks. Explain the decision you made and why. Share the architecture diagram. Talk about the library you tried and abandoned.

This does a few things that quietly matter:

It proves you can think, not just copy. Anyone can follow a tutorial. Explaining a real tradeoff you navigated in production shows a different level of understanding. Hiring managers and engineers who see that know the difference immediately.

It builds an audience that compounds. Each post is a small signal. Over months, those signals accumulate into a body of work that represents you more accurately than any CV. People start to recognize your name before you've applied anywhere.

It attracts people you want to work with. The engineers, founders, and companies who respond to someone building and writing in public are usually the ones worth working for. The ones who don't notice aren't the ones you want.

It keeps you accountable. Saying publicly "I'm building X" creates just enough pressure to actually finish it. More projects die from abandonment than from bad ideas.

What "document the journey" actually looks like

It doesn't have to be polished. It doesn't have to be long.

A DEV.to post about a bug that took you three days to fix and what you learned
A short LinkedIn update when you ship a new feature with a screenshot
A tweet thread walking through an architecture decision
A postmortem when something you built didn't work the way you expected The bar is: be specific and be honest. Generic posts ("I'm learning React!") disappear. Specific ones ("Here's why I replaced Redux with Zustand for conversation state in my AI app, and what broke when I did") get read, saved, and shared.

The realistic expectation

Building something won't guarantee you a job. Documenting it won't go viral overnight. This isn't a shortcut — it's a different kind of work, with a different kind of return.

What it does is give you something real to point to. When the market opens back up — and it will — you won't be walking into interviews with a portfolio of todo apps and a blank answer when they ask what you've shipped. You'll have a product, an architecture you can explain, decisions you can defend, and a trail of writing that shows how you think.

That's a different conversation entirely.

Start smaller than you think you should

The biggest mistake is waiting for the right idea. The right idea doesn't exist before you start building. It emerges from building.

Pick a problem you've personally run into. Build the simplest version that solves it. Ship it, even if it's rough. Write one post about what you built and why.

That's week one. Everything else follows from there.

The market might not be hiring right now. But it's still watching.

Are you building something on the side while job hunting? What's been the hardest part — the building or the consistency of documenting it? Drop it in the comments.

A Company Offered Me a Senior Role at Junior Pay - And Expected Me to Fraud My Way Through It

Oleh Volostnykh — Wed, 03 Jun 2026 15:28:36 +0000

A real story about a hiring scam targeting junior developers, and why your skills are worth more than desperation.

applied for a junior frontend position.

A friendly woman reached out, invited me to an AI interview. I did it. She liked what she saw and moved me to the next stage.

I joined a call. There was a guy on the other end. I walked him through my experience, he nodded along, then started telling me about the company, what they offer, the culture.

Then he said something that stopped me cold.

They wanted to put me forward — not for the junior role I applied for — but for a Senior Frontend Engineer position. Great, right?

Except I'd be earning a junior salary. And they'd be keeping the difference.

I asked the obvious question

"How would I actually do the work? I don't have senior-level experience."

He smiled. There would be mentors, he said. They'd handle my tasks.

I sat with that for a second.

"And the interview? How do I pass a senior frontend interview?"

He was calm about it. I wouldn't be doing the interview. Someone else would take it for me. After about a month on the job, nobody would remember the voice from the call anyway.

I declined. I ended the call. And I've been thinking about it ever since.

Let's be clear about what this is

This isn't a grey area. This is a scam — layered and deliberate.

The company bills a client for a senior engineer. They pay you junior wages. The gap goes into their pocket. You get placed using fraudulent credentials that aren't yours. When you can't do the work — because you were never qualified for it — you take the blame. The "mentors" disappear. The client is angry. You're the one who looks like a fraud, even though you were the one being defrauded.

And if the interview fraud ever surfaces, you're the face on the call. Not them.

They found you because you're a junior. Because the market is hard and juniors are scared. Because "senior salary" sounds like a lifeline when you've been job hunting for months. They are counting on that fear.

The junior market is genuinely brutal right now

I want to say that plainly, without sugarcoating it.

Getting your first or second role in frontend right now is hard. The entry-level tier has compressed. Companies that used to hire juniors now expect mid-level output at junior pay. AI tools have raised the bar for what "basic" looks like. And the interview process has gotten longer and more exhausting for everyone, especially people without much experience to lean on.

That context matters — because it explains why offers like this one are tempting. Not because juniors are naive. Because they're tired, and this looks like a door opening.

But it's not a door. It's a trap with a friendly face on it.

What to watch for

The specific pitch I received had a few markers worth naming:

Unsolicited level upgrade. You applied for junior. They're offering senior. Without seeing more of your work, without a technical assessment, without any obvious reason. That's not opportunity — that's a setup.
Vague "mentor" structure. Real mentorship means you do the work and someone guides you. When "mentors" are described as doing the work for you, that's not mentorship. That's a ghost operation.
Interview substitution. Any arrangement where someone else represents you in a hiring process is fraud. Full stop. The client company is being deceived. You become complicit the moment you agree.

- Salary math that doesn't add up. If they're billing senior and paying junior, ask yourself who keeps the rest. That question answers itself.

Your skills are not the problem

Here's the thing I want junior developers to actually hear.

The reason you're in the junior market is that you're still building. That's not a flaw — that's exactly where you're supposed to be. The skills you're developing right now, the projects you're shipping, the debugging sessions that take four hours and teach you more than any tutorial — that's the work. That's the actual foundation.

A shortcut that skips the foundation doesn't accelerate your career. It hollows it out.

Three months of real junior work — writing code you understand, getting feedback from people who actually want you to grow, shipping things you can explain — is worth more than a year of having someone else do your job while you watch.

Because eventually, the scaffolding comes down. And whatever is underneath is what you built.

Decline clearly and move on

You don't owe these people a long explanation. You don't need to argue the ethics with them on the call. A clear "this isn't something I'm interested in" is enough.

What you do owe yourself is the refusal. Not because this particular offer is uniquely evil — but because accepting it tells you something about how much you value what you're building. And that belief matters. It will carry you through the rejections and the silence and the long stretches where nothing seems to be moving.

The job market is hard. It will probably stay hard for a while. But the developers who come out of this period with real skills — skills they earned, not borrowed — are the ones who will actually have careers worth having.

Keep building. Decline the traps. The legitimate door will open.

Has anyone else run into something like this? I'd be curious how common this actually is — drop it in the comments.

Users Can Tell When Your UI Was AI-Generated - And They Don't Like It

Oleh Volostnykh — Tue, 02 Jun 2026 22:56:27 +0000

Open Lovable, v0, or Bolt. Describe an app. Hit generate.

In thirty seconds you have a working UI — cards with rounded corners, a sidebar with icons, a dashboard with soft shadows, a color palette that feels vaguely familiar. It works. It's clean. It's perfectly... fine.

And that's exactly the problem.

The "fine" problem

There's a specific aesthetic that AI-generated UIs tend to converge on. Tailwind defaults. shadcn/ui components. A blue or purple primary color. A hero section with a headline, a subheadline, and a CTA button. A features grid with icons and three-word labels.

It's not ugly. It's just identical.

Designers have a word for this: generic. And users — even ones who couldn't articulate why — feel it. The interface feels like a template someone forgot to customize. There's no friction, no texture, no point of view. It communicates something unintentional: nobody made a decision here.

What users are actually responding to

Users don't consciously think "this UI was AI-generated." What they feel is something more subtle:

Low trust — a generic interface signals a generic product. If the UI feels disposable, the product feels disposable.
Lack of identity — nothing in the experience says who built this or why. It could be anyone's app.
Uncanny familiarity — they've seen this layout before, on a different product, in a different industry. That recognition creates distance instead of comfort.

This isn't new. The same thing happened with WordPress themes in 2012, Bootstrap sites in 2015, and Webflow templates in 2020. Each wave produced a flood of visually competent but indistinguishable products. Users learned to equate the aesthetic with low effort — even when real work went into the product underneath.

AI-generated UI is the latest wave. And it's moving faster than any of the previous ones.

To be fair: AI-generated UI does real things well

This isn't a one-sided argument. AI UI generation has genuine strengths worth naming.

Speed of prototyping. Getting from zero to something testable in minutes is genuinely valuable. For validating ideas, gathering early feedback, or unblocking a design conversation — it's excellent. The artifact doesn't need to be final; it needs to be enough.

Solid component foundations. The components AI tools generate are usually accessible, responsive, and reasonably well-structured. The baseline is higher than what many developers would ship under time pressure. That's not nothing.

Useful for internal tools. Admin dashboards, internal tooling, CMS interfaces — places where no one is trying to build brand equity. Generic is fine. Generic is actually appropriate. The problem isn't generic UI. The problem is generic UI in places where it isn't appropriate.

Where it breaks down

The failure mode is specific: AI-generated UI shipped directly to users as a finished product experience, in contexts where trust, identity, and differentiation matter.

That's most consumer products. Most SaaS products. Anything where the UI is part of the product value.

Here's what gets lost:

Intentionality. Good UI design is full of decisions that seem small but add up — the exact amount of padding between elements, the choice to use a serif font in one place, the color that isn't in the standard palette. These decisions signal craft. AI tools optimize for competence, not craft.

Brand coherence. AI-generated UI has no memory of your brand. It doesn't know that your product is for developers who hate clutter, or for parents who are overwhelmed, or for executives who want to feel in control. It generates for a general user. Your users are specific.

Edge cases and real content. AI-generated layouts look great with placeholder content. The moment you put real data in — long usernames, error messages, empty states, truncated text — the seams show. Real UI is designed for real content, and that requires judgment AI tools don't have yet.

The practical middle ground

The answer isn't "don't use AI tools." It's "don't stop at what they give you."

Think of AI-generated UI the way you'd think of a rough sketch from a junior designer. It's a starting point that eliminates the blank canvas problem, gives you something to react to, and speeds up the first 40% of the work. But it's not done. It was never supposed to be done.

A few things worth doing after the AI hands off:

Kill the defaults first. Change the primary color. Change the border radius. Change the font. These three changes alone will make an AI-generated UI look less generic than 80% of what gets shipped.

Design for your actual content. Take your real data — real names, real copy, real edge cases — and put it into the layout immediately. The places it breaks are the places that need design decisions, not more AI generation.

Add one thing that couldn't have been generated. An unusual interaction, a micro-animation with a specific personality, a layout choice that trades convention for character. One thing is enough to signal that a human made decisions here.

Slow down on the parts that touch trust. Onboarding flows, empty states, error messages, loading states — these are the moments when users decide whether they trust your product. AI tools handle them generically. You shouldn't.

The honest conclusion

AI UI generation tools are genuinely useful. They lower the cost of starting, and for a lot of use cases — prototypes, internal tools, MVPs under real time pressure — they're the right choice.

But there's a growing gap between what these tools can produce and what users experience as a considered, trustworthy product. That gap is visible. Users feel it even when they can't name it.

The question for every frontend engineer and product builder isn't whether to use these tools. It's how much of what they generate you're willing to ship without touching.

That decision says something about your product — whether you intend it to or not.

Have you noticed users responding differently to AI-generated UI? Or do you think the "users can tell" claim is overstated? Genuinely curious what people are seeing in the wild.

What Is an AI Frontend Engineer?

Oleh Volostnykh — Mon, 01 Jun 2026 15:40:35 +0000

I changed my LinkedIn title to "AI Frontend Engineer".

Then people started asking what it meant. Then companies started posting job listings with that exact title. Apparently the whim was onto something.

So let me explain what I mean by it - because it's a real and distinct set of skills, not just a buzzword someone stuck on a traditional frontend role.

The honest answer to "what is it?"

An AI Frontend Engineer is a frontend engineer who specializes in building AI-powered products and experiences.
Think about the apps you use daily - ChatGPT, Claude, Cursor, Lovable, n8n, Codex. The interfaces that feel fast, responsive, and trustworthy despite talking to a model that is slow, probabilistic, and occasionally wrong. Someone built those experiences. That's the job.

It's a similar idea to how video calling apps, real-time collaboration tools, or audio editors demand frontend expertise well beyond the standard web development stack. The domain changes what you need to know. AI is the same.

What a standard frontend engineer does

Before layering on the AI-specific stuff, the fundamentals still matter - fully.

A frontend engineer turns product requirements and backend APIs into a polished UI. That means UI architecture, design systems, state management, routing, performance optimization, accessibility. None of that goes away in AI products. If anything, it matters more, because AI interfaces are already fighting an uphill battle for user trust.
Shaky fundamentals + unpredictable model behavior = a product that feels broken even when it isn't.

What an AI frontend engineer adds on top

This is where the role diverges. Here's the actual skill surface.

LLM APIs

You need to know how to work with language model APIs beyond a basic fetch call:

Streaming responses - rendering tokens as they arrive, handling partial state, avoiding layout thrash
Tool calling - displaying function calls in progress, surfacing results inline
Structured outputs - parsing and rendering typed model responses reliably
Retries and cancellation - handling the model being slow, wrong, or timing out without breaking the UI

Agentic frontend experiences

Single-turn Q&A is the easy case. The harder case - and where most real products live - is multi-turn, multi-step interactions:

Conversation history that persists, branches, or resets correctly
Approval flows where the user gates what the model does next
Intermediate states where the model is mid-task and the UI needs to reflect that honestly

UX patterns specific to AI

This is underrated and underdiscussed. AI products have their own UX vocabulary:

Streaming indicators that feel informative, not just generic loading spinners
Graceful degradation when the model produces something unexpected
Trust signals - letting users see what the model is doing and why
Communicating confidence and uncertainty through UI, not just text

Multimodal inputs

Text is just one input type. Modern AI products handle files, images, audio, and rich context attachments. Building the upload flows, previews, and context management for all of that is non-trivial frontend work.

Complex app architecture

AI products tend to develop layers fast:

Orchestration layers sitting between the UI and the model
Reusable components for chat messages, tool results, and artifact rendering
Message pipelines that handle streaming, queuing, and error states
Artifact rendering - code blocks, structured data, generated images, inline previews

State management

State in AI apps is a different beast. You're tracking:

Conversation history - append-only, ordered, sometimes branching
Streaming tokens - partial, mutable, then finalized
Request states - idle → loading → streaming → done → error
Retry logic, cancellation, and optimistic updates

Redux was designed for a world where state was predictable. AI state is not always predictable. How you model it matters a lot.

The one-sentence version

A typical frontend engineer turns product requirements and backend APIs into a polished UI.

An AI frontend engineer turns model capabilities into a polished, trustworthy, controllable product experience.
The word that matters most in that second sentence is controllable. Users of AI products need to feel like they're in charge of something that could, in theory, run away from them. That feeling is built in the frontend.

Is this a real role or a marketing title?

Both, honestly.

"AI Frontend Engineer" is not yet standardized. Different companies will mean slightly different things by it. Some will use it for any frontend engineer working on an AI product. Others will mean the specific skill set described above.

But the skills are real regardless of what the title says. Streaming UIs, agentic flows, multimodal inputs, LLM state management - these are concrete, learnable, in-demand skills. Engineers who have them are building the products that millions of people use to interact with AI every day.
Whether your LinkedIn says it or not, those skills are worth developing.

Are you working on AI products on the frontend? What's been the hardest part of the stack to get right - streaming, state, UX patterns? Drop it in the comments.

AI Won't Save You From Forgetting How to Think

Oleh Volostnykh — Sun, 31 May 2026 13:05:55 +0000

I want to make a claim that might age badly, and I'm making it anyway.
The more we offload thinking to AI tools, the more we need deliberate practice to stay sharp. And LeetCode — for all its baggage — is one of the few structured ways most developers have to do that.
Not for interviews. For your brain.

Something is quietly happening to developers right now
Nobody announces it. There's no error message.
But ask yourself honestly: when was the last time you worked through a non-trivial logic problem without reaching for Copilot, ChatGPT, or a Stack Overflow snippet in the first five minutes? When did you last choose a data structure because you reasoned through the trade-offs — not because autocomplete suggested it?
AI coding tools are genuinely useful. I use them daily. But there's a cost that compounds slowly and invisibly: you stop exercising the reasoning muscle, and eventually, it weakens.
You don't notice until someone asks you why your solution works — and you have to think harder than you expected.

What forgetting actually looks like
It doesn't look like incompetence. It looks like learned helplessness disguised as efficiency.

You paste a problem into ChatGPT before sitting with it for even two minutes
You can read code well but struggle to write logic from scratch under any pressure
You know a nested loop is "probably bad" but can't articulate why, or what the better approach is
You feel vaguely anxious when the AI gives you a wrong answer — because you're not sure how to verify it

That last one is the one that should worry you. If you can't sanity-check the output, you're not using a tool. You're depending on one.

Why DSA and algorithms are actually the right antidote
Not because Google-style interviews are a good measure of engineering talent — they're often not.
But because DSA problems are the most concentrated form of a skill you use constantly in real work: breaking down a problem you've never seen before, reasoning about it carefully, and arriving at a solution you can defend.
Working through a sliding window problem trains you to notice patterns in data. Implementing a graph traversal from scratch forces you to hold state in your head. Getting a time complexity wrong and figuring out why teaches you to question your own assumptions.
None of that is interview prep. All of it is thinking.
And thinking is exactly what AI is tempting us to skip.

The bar is low — and that's the point
I'm not suggesting grinding 300 hard problems on a leaderboard.
Twenty minutes, a few times a week. One problem. No solution tab open. The goal isn't to solve it — the goal is to try before you give up. To sit with the discomfort of not immediately knowing the answer, and work through it rather than outsourcing it.
That habit — trying first, thinking before reaching — is what erodes fastest in an AI-assisted workflow. It's also what makes you the kind of engineer who can actually steer AI tools well, rather than just accept whatever they produce.

This isn't nostalgia for a pre-AI world
AI tools are here, they're useful, and they're not going anywhere. The developers who will use them best aren't the ones who delegate the most — they're the ones who've kept their own reasoning sharp enough to know when the output is wrong, when the approach is suboptimal, and when the problem itself is being misunderstood.
DSA practice won't make you immune to bad AI output. But it keeps the critical faculty alive - the part of you that reads a solution and thinks "wait, that doesn't feel right" and knows how to follow that instinct.
That instinct is worth protecting.

Are you still doing any deliberate problem-solving practice, or has AI tooling changed how you think about that? Genuinely curious where other devs land on this.