Breaking into web development

“Joined with an EE/CS background and no web experience; proposed and delivered a 3-month trial that converted to a full-time offer.” It’s also the origin of the profile line about proving fast ramp-up on an unfamiliar stack.

I did not come to web development the usual way. I studied electrical engineering with a focus on biomedical engineering and signal processing. During my master’s, my work centered on machine-learning methods to classify ECG signals, modeling the electrical impulses of the heart, and ultrasound imaging — a lot of scripting and data analysis in Python and C++, and my first taste of building interfaces with Qt.

The topics were genuinely fascinating, and I’m grateful for my time in academia — it always sounded impressive when people asked what I’d worked on. But after graduating, I was itching for a different kind of work environment. I wanted to be part of the startup buzz — to build products that shipped and reached real people, fast.

The bet

So I applied to a startup — minubo — without knowing the basics of web technology. I still remember the CTO explaining the difference between frontend and backend development during the interview, and my eyes lighting up when he described building frontends.

Rather than pretend I already knew the stack, I made a proposal: a 3-month internship, learning everything by tackling real software problems. The premise was simple — if I turned out to be a quick learner, I’d be offered a full-time developer position.

It worked. The trial converted to a full-time offer, and it started the 10+ year engineering career the rest of this CV documents.

Ramping fast

Writing code itself was not new to me — years of scripting, data analysis, and signal-processing work meant I could already think in algorithms and structure. What was new was the domain. I picked up JavaScript, AngularJS, git, and the frontend tooling the company used quickly, learning the fundamentals of building features directly from the CTO.

Two things made those first months compound:

• I was in the product early. Rather than being handed tickets in isolation, I was involved in product and UX decisions from the start — so I learned not just how to build a feature, but why it should exist and how it should feel.
• Continuous delivery closed the loop. My changes shipped to actual B2B clients on a weekly cadence. That feedback loop — build it, ship it, see it used — was hugely motivating and taught me more than any tutorial could.

Beyond the basics

I didn’t stop at what the job required. I started seeking knowledge outside the company, self-teaching frontend principles and tooling, and bringing what I learned back into the codebase. Over time I:

• Modernized the frontend toolchain and introduced the then-new ES6 language features into our codebase;
• Built multiple high-impact features — aggregated data reports, dashboards, data visualization, and gamified notification mechanics.

The data-visualization thread is not a coincidence: the signal-processing and imaging work I’d done in academia turned out to transfer straight into making data legible on screen. The subject matter changed; the habit of turning messy signals into something a human can read did not.

Why it still matters

The muscle that trial forced — walking into an unfamiliar stack and becoming productive quickly — is one I’ve relied on ever since: a new framework, a new domain, a codebase I’ve never seen. It’s the same instinct behind migrating Loopy Demos to Astro + SolidJS by hand, and behind every “moved into an unfamiliar stack and proved fast ramp-up” moment in my career. It began with a bet that I could learn faster than the risk of hiring me — and then making good on it.