Gleb Galkin | PropTech Expert & Developer Mentor

From Career Changer to Frontend Dev: The Accountability Method

2026-02-08T00:00:00Z

You have 47 browser tabs open. Three Udemy courses half-finished. A React tutorial bookmarked since last March. A GitHub repo called my-portfolio with one commit from four months ago.

You know what to do. You just don't do it.

I know this because I've seen it dozens of times. I've spent 18 years building software at Zalando, JUMO, and GROPYUS. I've led teams, shipped products, and mentored developers from zero to hired. The career changers are the ones I remember most. Not because they were the weakest. Because they were the most motivated people in the room — and still couldn't ship.

The pattern is always the same. And it has nothing to do with talent.

The Real Reason Career Changers Get Stuck

Let me tell you about a teacher from Berlin. Let's call her Maria. She had been learning to code for 11 months when she reached out. Eleven months. She knew HTML. She knew CSS. She could explain the difference between let and const. She had completed freeCodeCamp's responsive design certification.

She had never deployed a single project.

Not one.

When I asked her what happened every weekend when she sat down to code, the answer was always a variation of:

"I started building a to-do app, but then I saw a tutorial about React hooks and thought I should learn that first. Then I realized I didn't understand closures well enough. So I went back to JavaScript fundamentals. Then Monday came and I went back to work."

Sound familiar?

This is what I call the tutorial spiral. You keep learning because learning feels productive. It feels safe. Nobody can judge your to-do app if you never finish it. Nobody can reject your portfolio if it doesn't exist.

But here's the thing Google and YouTube won't tell you: knowing is not the bottleneck. Doing is the bottleneck.

And doing requires someone watching.

Why Courses Don't Work for Career Changers

I have a linguistics degree. Most engineers don't. This means I think about learning differently than pure engineers.

Here's what I've observed: courses are designed for knowledge transfer. They're lectures in a box. You watch, you nod, you maybe type along. But a course can't ask you why you skipped Saturday's coding session. A course can't look at your commit history and say, "You wrote CSS for six hours but didn't touch the JavaScript. Why are you avoiding it?"

A course can't text you on Tuesday asking why you didn't push that commit.

Career changers don't fail because the course was bad. They fail because:

No deadlines. Your job has deadlines. Your coding journey doesn't. Guess which one wins every time.
No feedback loop. You write code in isolation. You don't know if it's good, bad, or embarrassing. So you never show it to anyone.
No consequences. If you skip a week, nothing happens. Nobody notices. Nobody cares. So you skip another week. And another.
Analysis paralysis. Should I learn React or Vue? TypeScript or JavaScript first? Tailwind or plain CSS? You research for hours instead of building for minutes.

I've watched this cycle destroy more potential developers than any technical concept ever could.

The Accountability Method

After mentoring dozens of career changers, I built a framework. It's not complicated. It's not revolutionary. But it works.

I call it the Accountability Method. It has four parts.

1. One Project. No Switching.

Pick one project. Build it. Do not start another one until it's deployed.

Not a to-do app. Something you actually care about. A recipe tracker if you love cooking. A guitar chord library if you play music. A lesson planner if you're a teacher.

The project must be:

Personally meaningful — you'll need motivation when CSS Grid makes you want to throw your laptop
Small enough to finish in 4-6 weeks — not an e-commerce platform, not a social network
Deployable — it goes live on the internet where humans can see it

When Maria and I started working together, she picked a classroom management tool. She was a teacher. She knew the problem inside out. She didn't need to research the domain. She just needed to build.

2. Weekly Check-Ins With Pushback

Every Monday, you answer five questions:

What did I accomplish this week?
What blocked me?
What did I avoid and why?
What's my #1 goal for next week?
What's the first thing I'll do when I sit down to code?

Question three is the one that matters. "What did I avoid and why?" forces you to be honest with yourself. Most career changers avoid JavaScript when they can write CSS instead. They avoid deploying because the build process scares them. They avoid writing tests because they don't know where to start.

When I respond on Tuesday, I don't sugarcoat. If you spent six hours perfecting a hover animation instead of implementing the login flow, I'll say it. Gently, but directly.

If you're five years old and I can't explain it to you in a way you understand, I don't understand it well enough myself. That's my teaching philosophy. But being kind doesn't mean being soft. Accountability without honesty is just a diary.

3. Ship Something Every Two Weeks

Not "finish" something. Ship something.

The difference is critical. Finishing means the code works on your machine. Shipping means it's live on the internet. These are two completely different skills, and the gap between them is where most career changers die.

Here's a two-week sprint structure I use:

Week 1:

Days 1-3: Build the feature (HTML, CSS, JavaScript)
Days 4-5: Make it work on mobile
Days 6-7: Write one test. Just one.

Week 2:

Days 1-2: Fix the bugs you found while testing
Days 3-4: Deploy to Vercel, Netlify, or GitHub Pages
Day 5: Share the link with one person and ask for feedback
Days 6-7: Implement one piece of feedback

By the end of two weeks, you have a feature that's live, tested, and reviewed by a real human. That's more than most bootcamp graduates achieve in a month.

4. Build in Public

Tell someone what you're building. Post your progress on X, LinkedIn, or even just a WhatsApp group. The point is not to get followers. The point is to create social accountability.

When Maria started posting her weekly progress on LinkedIn, something shifted. She couldn't skip a week anymore because people were watching. Three of her colleagues started asking her about coding. A recruiter noticed her posts and reached out.

She didn't have a portfolio website yet. She had something better: a public trail of consistent work.

The 14-Week Timeline

Maria landed her first frontend role in 14 weeks. Here's roughly what those weeks looked like:

Weeks 1-2: Set up the project. HTML structure. Basic CSS. Deploy an ugly version to Netlify. It was ugly. That's fine.

Weeks 3-4: Add JavaScript interactivity. Event listeners. DOM manipulation. No framework yet. Vanilla JS only.

Weeks 5-6: Refactor the CSS with Tailwind. Make it responsive. Deploy the updated version.

Weeks 7-8: Learn React basics. Rebuild one component in React. Not the whole app. One component.

Weeks 9-10: Add state management. Connect to a simple API. Deploy the React version.

Weeks 11-12: Write tests. Set up CI/CD. Add TypeScript to one file. Deploy with automated pipeline.

Weeks 13-14: Polish the portfolio. Prepare for interviews. Do two mock interviews with me.

She didn't learn everything. She learned enough to ship, enough to talk about her work intelligently, and enough to demonstrate she could learn the rest on the job.

That's what employers want. Not perfection. Proof that you can ship.

What I See From the Other Side of the Table

I've conducted hundreds of technical interviews. I wrote about one memorable experience where a candidate tried to secretly Google the answers. It didn't end well.

But here's what I've never told anyone: the career changers who use the accountability method interview differently than bootcamp graduates. They don't recite textbook answers. They tell stories.

"I built a classroom management tool because I was a teacher and I hated the existing ones. Here's the deployed version. Here's my Git history — you can see I shipped every two weeks. Here's the test I'm most proud of. Here's a bug I couldn't fix for three days and how I eventually solved it."

That answer beats "I completed a React bootcamp and built a to-do app" every single time.

I know because I'm the one sitting on the other side of the table. I'm the one who decides.

The Hard Truth

The accountability method is not easy. It's not comfortable. You will have weeks where you want to quit. You will have Mondays where you dread writing that check-in because you didn't do what you promised.

That's the point.

If you could do it alone, you would have done it already. You've had access to every tutorial, every course, every documentation site on the internet. The information was never the problem.

The problem is that nobody is watching.

Google can teach you React. YouTube can teach you TypeScript. But neither of them will text you on Tuesday asking why you didn't push that commit.

What to Do Next

If you're a career changer reading this, here's what I want you to do right now. Not tomorrow. Not next Monday. Right now.

Pick one project. Something you care about. Something small enough to deploy in two weeks.
Tell someone about it. A friend, a partner, a colleague. Post it online. Make it real by making it public.
Set a deadline. Two weeks from today, version one goes live. Ugly is fine. Broken is fine. Live is non-negotiable.
Find someone to report to. A mentor, a study group, a friend who codes. Someone who will ask you uncomfortable questions on Tuesday.

And if you can't find that someone — that's literally what I do.

I love to help people become developers regardless of their background, previous job, and skills. I enjoy patiently explaining complex topics in plain language like you're five. Whether you're catching up on a pet project or nailing a bug, reach out and we can do it together.

You don't need another course. You need someone watching.

Now close those 47 tabs and open your code editor.

WebXR - The Future of Virtual and Augmented Reality on the Web

2023-01-17T00:00:00Z

What Is WebXR?

WebXR is the future of web-based virtual and augmented reality. It is a set of APIs (Application Programming Interfaces) that allows developers to create and run VR and AR experiences on the web. This means that users will be able to access VR and AR content without the need to download any additional software or apps.

WebXR is built on top of WebVR, which was the first set of APIs for creating VR experiences on the web. However, WebXR extends the capabilities of WebVR by also supporting AR experiences. This is made possible by using the device's camera and other sensors to overlay digital content on the real world.

Key Advantages of WebXR

Wider Reach and Accessibility

One of the key advantages of WebXR is that it allows for a wider reach of VR and AR content. With traditional VR and AR, users are required to have specific hardware, such as VR headsets or AR glasses. With WebXR, users can access VR and AR content on any device that has a web browser, including smartphones, tablets, and laptops. This greatly expands the potential audience for VR and AR content.

Cross-Platform Compatibility

Another advantage of WebXR is that it allows for cross-platform compatibility. With traditional VR and AR, developers have to create separate versions of their content for each platform, such as Oculus, HTC Vive, and PlayStation VR. With WebXR, developers can create one version of their content that will work on any platform that supports the WebXR APIs.

WebXR Applications in E-Commerce

WebXR also opens up new opportunities for e-commerce and online shopping. With WebXR, shoppers can try on virtual clothes, shoes, and accessories, and see how they look on them before making a purchase.

In addition, WebXR can also be used for virtual tours of properties, allowing potential buyers to explore properties remotely.

The Future of Immersive Web Experiences

In conclusion, WebXR is a game-changer for the VR and AR industry. It allows for wider reach, cross-platform compatibility, and opens up new opportunities for e-commerce, online shopping, and real estate. As the technology continues to evolve, we can expect to see more and more VR and AR experiences available on the web, making them accessible to everyone.

Materials Used

Cover photo by Mediamodifier, available under Unsplash License.

Why Googling During Interviews Doesn't Help (A Lead Engineer's Perspective)

2023-01-12T00:00:00Z

Once upon a time

It was a regular screening interview with someone from another part of the world sitting in the same-furniture office.

Rainy weather in winter does not help to focus at all, and I go to get some coffee. Being sleepy is something I want to avoid at all costs. Pouring over Columbian coffee gives a brain energy spike. It is important to have fifteen minutes before the interview starts. You need to switch focus away from the routine.

A notebook with a pen are prepared to record the candidate's answers, emotions, body language, and my quick feedback.

3, 2, 1, click...

Mega standard questions

"Hello, my name is Gleb. Welcome to the technical screening interview. It is one hour long in total. At the end of the interview, you will have ten minutes to ask any question. During the interview, I take some notes. If you see me typing I am not chatting with my mates. I am complete with you. These notes are for me and I will never distribute or pass them to anyone. I need these for decision talk. Do you have any questions about the interview process?"

I don't remember anyone who had any additional questions. The interview framework is dead simple. So we start.

My first question is standard: why did you decide to change your job and apply for this position at our company?

You might argue this question is mega standard, and I should omit it during technical interviews. Believe me or not but I ask this question because of two reasons:

It is a good starting point for the conversation.
I am curious. Everyone is different. I still remember one answer: "I decided to quit my job and apply overseas because I WANT TO ESCAPE FROM MY COUNTRY." That was a real pain.

This time the answer was: "I want to move further in my career." A good one.

I asked the second question: "What kind of techniques and tools do you use to write a good quality code?" It is usually the open one. I would like to know about the candidate's experience.

"I use ESLint for linting my code and Prettier for code formatting. It looks the same for everyone in the team," the candidate answered.

One interesting observation: junior developers often starts with tools, for example, linting, formatting, tests. Senior developers mention software design patterns, data structures, algorithms first, and all the tools second.

"Do you use Test Driven Development?" I asked.

"Yes, I do."

"Great! It is time to get hands dirty and code something," I said. "I am gonna share with you the JSFiddle link. You will find a simple assignment there. You need to implement one function that reverses a string passed to it as the parameter. You have five minutes to think about it. You can think loud and if you have any question or problem we can discuss."

"Sure, ok," the candidate said.

This is how JSFiddle looked like:

  /**
   * Reverse a string pased as a parameter.
   * For example, reverse('Hello') returns 'olleH'.
   * 
   * @param {string} str - A string to reverse
   * @returns {string} Reversed string
   */
  function reverse(str) {
      
  }

Glowing Face

I made a coffee sip. The third interview already. My voice needs to have a short break.

The candidate was sitting in silence. The cursor on the JSFiddle page was not moving. It is worth saying the candidate's surrounding was dark. JSFiddle background is black as well, so the candidate's face was kinda in a shade.

Suddenly the face gloves. Boom!

Quick experiment: what website with a bright white background do you open when you have a question? Bingo, Google. Or maybe Bing, DuckDuckGo, it doesn't matter. What matters is I was sitting in front of the person cheating. Even if you have a silent keyboard you can still notice shoulder and eyes micro-movements.

Being caught cheating during the interview is embarrassing for both of us.

I decided to save the candidate's face and proposed:

"If you have any trouble remembering a function name or something, please, ask me. I also recommend thinking loud, so I can help you."

Candidate nodded. Needless to say, the candidate went on to surreptitiously google all the next questions I asked.

I was frustrated and hopeless to save the interview. If you need to google such a basic question what kind of questions should I ask for the middle Frontend engineer position?

We finished the interview in time.

I could not interrupt it earlier whereas I wanted with my all heart. I felt it was painful for both of us.

The coding interview result was awful. The candidate tried to google answers instead of focusing on the problem. No test was written (remember TDD was mentioned). So I had to review code samples but nothing was done until the end.

This candidate would never know what I know about cheating.

Tips for Candidates

I would love to share some tips for candidates from my 12+ years of experience.

Don't be late for the interview. Every minute counts to give you the possibility to make a better impression and answer more questions. Arrive on time if it is an offline interview.

Check your internet connection. If it is an online interview make sure you have a good internet connection and try to connect some minutes before the interview starts.

Check your surroundings. Avoid someone is walking behind you during the interview without pants.

Be sure to dress for the occasion. Even for the online interview. It also has a positive psychological effect on you. You will be more focused and in the mood.

Communicate effectively. This means being able to explain your ideas clearly and concisely. Think loud. It helps me to understand your approach to solving a problem. But also be able to listen attentively to others. Sometimes candidates are stuck during the interview. I usually try to help them. As an interviewer, I give some hints that can help. So if you listen with 100% attention you will nail the question.

Make sure you know what kind of interview you are preparing for.
There are many different types of interviews for a software engineer position.

One type of interview may be a Q&A session. The interviewer will ask you questions about your experience, skills, and abilities. Be yourself and tell about your personality and your superpower.
Another type of interview may be a coding challenge, where you need to show your hard skills. I recommend showing your everyday coding process. For example, if you use Test Driven Development start your coding challenge with a test.
The third type of interview may be about your thinking on system architecture. You must prepare for answering open questions.

Be ready to answer questions about your experience, your skills, and your goals. You should also be prepared to talk about the projects you've worked on in the past, and how you contributed to them. Explain in detail your input. It is always interesting how people solve the same problem differently. If you contribute to any open source project share it! If you hack something in your free time, show it! Github is a new Tinder.

Prepare your code samples. The interviewer might want to know how you approached the problem, what solutions you came up with, and why you made the choices you did.

Show your competencies. Having a deep understanding of algorithms, data structures, and software design principles helps a lot. It is important to be well-versed in the latest technologies and trends. It shows that you're a part of the engineering community.

Be sure to read up on the company's products and services. You should also be familiar with the company's technology stack, and be able to talk about the projects you've worked on that used that technology. If this information is not available it is a great question to the interviewer.

Prepare a list of questions. Outline everything you want to know or you need from the company as a bullet points list.

Ask questions about the company's culture. I as the interviewer want to know if you are a good fit for the company and if the company is a good fit for you.

Be yourself.

P.S.

You might want to know what the candidate could do differently. If you don't know the answer, if you are confused, JUST SAY IT explicitly. Don't try to cheat or stall. Help me to move the interview forward, so I can learn more about you, your skills, and your superpower.

Materials Used

Cover photo: Grayscale Photography of Man by Tookapic, available under Creative Commons Zero (CC0) license.

Active Listening Skills for Software Engineers and Leaders

2022-12-13T00:00:00Z

What Is Active Listening?

Active listening is the process of intentionally paying full attention to the speaker, understanding their message, and responding in a way that shows you have heard and comprehended what they said.

It involves more than just hearing the words that are being said - it involves paying attention to the speaker's body language, tone of voice, and any other nonverbal cues they may be giving off.

Being an active listener can improve communication in a variety of settings, from personal relationships to professional environments.

Why Active Listening Matters for Engineers

In software development, communication breakdowns cost time and money. Active listening helps you understand requirements clearly, give better code reviews, and collaborate effectively with cross-functional teams.

Key Practices for Active Listening

Active listening is a learnable skill that transforms how you collaborate with your team.

Here are the essential techniques:

Make eye contact and avoid interrupting - Give the speaker your full attention, especially during remote meetings
Ask clarifying questions - Ensure you understand requirements before you start coding
Avoid formulating a response - Listen first, think second, respond last
Reflect and paraphrase - Summarize what you heard to confirm understanding

The Impact on Your Career

Active listening can be challenging, but it is a valuable skill to develop. By actively listening, you can:

Improve your relationships with teammates and stakeholders
Reduce misunderstandings that cause bugs and rework
Foster a deeper understanding of user needs and business requirements
Build trust as a reliable team member and leader

Whether you're preparing for technical interviews or transitioning into a frontend developer role, active listening is a foundational skill that sets you apart.

Materials Used

Cover photo by Volodymyr Hryshchenko, available under Unsplash License.