Recently, I went through a structured interview process with JobLeads GmbH for a Frontend role. I decided to document the experience objectively, outlining how the process was organized, what was expected technically, and what I learned from it.

Step 1: CV Submission and HR Screening

After submitting my CV, I was invited to an initial HR call.

The conversation lasted around 15–20 minutes and covered:

  • My professional background

  • The technologies I work with (Vue, Nuxt, TypeScript, etc.)

  • The type of projects I have been involved in

  • What I am currently looking for

They also presented the company and its internal culture.

One thing that stood out was the emphasis on how the company treats employees. They highlighted:

  • A strong remote-first culture

  • Clear communication processes

  • Work-life balance

  • Annual team-building events, often organized in Mediterranean locations

  • Good conditions for remote employees

It was clear that long-term collaboration and culture fit matter to them, not only technical skills.

A few days later, I received a professional follow-up inviting me to a technical interview. The expectations were clearly outlined in advance.

Step 2: Technical Interview Preparation

Before the interview, they informed me:

  • Which technologies would be covered

  • That the session would include live coding

  • That AI tools were not allowed

  • That Google search was permitted

  • That tasks would be provided in a Markdown file

  • That I should prepare my local development environment

The transparency helped reduce uncertainty.

Since the session would involve live coding without AI assistance, I spent about a week preparing. I focused on:

  • Writing Nuxt code without AI

  • Refreshing syntax so it felt natural

  • Practicing clean and structured solutions

  • Practicing explaining my thought process while coding

The key shift was mental. In everyday development, AI tools are often part of the workflow. In this context, everything had to come directly from memory and reasoning.

Step 3: Technical Interview (Live Coding)

The technical interview lasted around one hour.

On the morning of the interview, I received access to a GitLab repository. I had to clone it locally and work from there. This also allowed them to observe how I use basic Git commands while working.

The tasks were provided in a Markdown file inside the repository.

During the session:

  • I coded live

  • I explained every decision

  • I described trade-offs

  • I structured the solution clearly

The format tested not only correctness, but also:

  • Communication clarity

  • Code organization

  • Git workflow basics

  • Structured thinking under time pressure

It was less about “getting it to work” and more about demonstrating how I think.

Step 4: Trial Day Tasks

After passing the technical interview, I was invited to a trial day.

The trial day consisted of multiple practical tasks designed to simulate real frontend challenges.

Some of the tasks included:

1. Vanilla JavaScript Range Slider (Single & Double)

I implemented a range slider without external libraries.

Key aspects included:

  • Class-based architecture

  • Accessibility (role="slider", aria-valuemin, aria-valuemax, aria-valuenow)

  • Keyboard navigation (Arrow keys, Home/End, step adjustments)

  • Performance optimization using requestAnimationFrame

  • Touch support

  • Clean separation of logic and styling

This task tested DOM manipulation skills, accessibility knowledge, performance awareness, and architectural clarity.

2. Cart Store with Promo Code Logic (Vue / Pinia)

Another task involved implementing cart state management with promotional code logic.

Important aspects included:

  • Reactive state handling

  • Removing items from the cart

  • Applying discount conditions (for example, minimum purchase thresholds)

  • Ensuring promo codes become invalid if conditions are no longer met

Under time pressure, implementing business logic cleanly and handling edge cases was more challenging than expected. Knowing the concept and writing it confidently in a high-pressure environment are two different things.

3. SEO, SSR, and Performance Discussions

There were also discussions around:

  • SEO meta handling

  • Structured data (JSON-LD)

  • Server-side rendering

  • Core Web Vitals (including CLS)

We discussed how animations can impact layout shifts if not handled correctly. There were also conversations about font optimization (hosting locally instead of relying on external sources), image optimization, and accessibility considerations.

This part focused more on architectural awareness than pure coding.

Reflection on the Trial Day and Presentation

One important aspect of the trial day was clarity around expectations.

I was not entirely sure whether all tasks were expected to be fully completed within the allocated time. Because of that uncertainty, I focused heavily on finishing as much functionality as possible.

In doing so, I relied more on AI tools during preparation than I probably should have. While this helped me move faster during practice, it also meant that I did not internalize certain syntax details deeply enough. Under pressure, that gap becomes visible.

Another challenging part was the final presentation.

The demonstration of my solution was done in front of approximately ten developers. Explaining architectural decisions, implementation details, and edge cases in that environment created a high-pressure situation for me.

It was not only about whether the code worked. It was about:

  • How confidently I could explain it

  • How clearly I could defend decisions

  • How quickly I could respond to follow-up technical questions

Presenting in front of a large technical audience is a skill in itself. Writing code alone and defending it under scrutiny are two different challenges.

In hindsight, I could have prepared more specifically for that format — especially by practicing explaining decisions out loud under simulated pressure.

What I Learned

  1. Live coding without AI is a different muscle.
    It requires deeper internalization of syntax and patterns.

  2. Clarifying expectations early matters.
    If completion criteria are unclear, it is better to ask directly.

  3. Speed is not everything.
    Demonstrating structured thinking and architectural clarity may matter more than finishing every detail.

  4. Business logic under pressure reveals real understanding.
    Edge cases matter.

  5. Technical presentation skills require deliberate practice.
    Explaining decisions confidently in front of multiple senior developers is a separate skill from writing code alone.

Final Thoughts

Although I was not ultimately selected for the role, the process was structured, transparent, and technically demanding.

It highlighted areas for growth:

  • Faster syntax recall

  • Stronger confidence with state edge cases

  • Sharper articulation of architectural trade-offs

At the same time, it reinforced strengths in:

  • Accessibility awareness

  • Performance thinking

  • Structured frontend architecture

Overall, it was a challenging but valuable experience — one that clarified both my current level and the direction for further improvement.