Workplace Image CYAN Security Group GmbH

Mislav Findrik, Research Engineering Lead bei cyan Digital Security

Description

Mislav Findrik von cyan Digital Security spricht im Interview über seinen Werdegang – angefangen von der Schule bis hin zu seiner aktuellen Arbeit – und gibt Tipps für Beginner.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In “Mislav Findrik, Research Engineering Lead bei cyan Digital Security,” Mislav Findrik recounts his journey from hands‑on electronics and circuit programming to bachelor’s and master’s degrees in computer science, applied research in Vienna, and pursuing a PhD. He now leads Research Engineering at cyan, collaborating with Austrian research centers and guiding teams of data engineers, data scientists, and software engineers to build machine‑learning‑based cybersecurity products that better protect customers. For aspiring ML engineers and data scientists, he advises entering data‑science competitions, attending regular meetups, and maintaining a public GitHub profile.

From Soldering Iron to ML Leadership: Mislav Findrik, Research Engineering Lead at cyan Digital Security on building impact through research and industry

Context: A conversation that connects the dots

In “Mislav Findrik, Research Engineering Lead at cyan Digital Security” (Speaker: Mislav Findrik, Company: CYAN Security Group GmbH), the speaker offers a clear, grounded journey: from technical high school and circuit boards to applied research, a PhD, and leading a research engineering team in cybersecurity with a focus on machine learning. There’s no fanfare—just a straightforward account of how hands-on beginnings, academic rigor, and product orientation align.

Listening closely, we traced how early hours with a soldering iron formed the foundation for a role that now hinges on collaboration, data competency, and making products better. And we distilled what most benefits engineers: staying close to the craft, investing in depth, and working across organizational and disciplinary lines.

Beginnings with boards, chips, and a soldering iron

The story starts with classic builder energy. Technical high school wasn’t just theory—it was wiring, soldering, and programming circuit boards:

“I went to the technical high school, I had affinity for engineering and well I've started with programming the circuit boards, so with a solder iron, I was playing with the electronics, trying to make chips...”

This is the kind of tactile experience that shapes how you approach systems later. Early exposure to electronics forces a systems mindset: inputs and outputs, dependencies, side effects. In data-driven work and machine learning, that discipline translates into crisp interfaces, clear assumptions, and testable hypotheses.

What we take from this phase

  • Early practice builds muscle memory: Working on real systems—boards or datasets—creates intuition that lasts.
  • Hardware habits sharpen rigor: When a component is misaligned, nothing works. That unforgiving feedback loop is invaluable later in software and ML.

Starting in electrical engineering, arriving in computer science

University began with a plan to study electrical engineering. But the first year reshaped that plan:

“When I started the university, I wanted to study electrical engineering, but during the first year, I get into the programming, so I've started getting more into the computer science...”

The outcome: a bachelor’s and a master’s in computer science. This is less a pivot than a widening of scope—from the physical to the algorithmic, from soldering to coding. Programming opened new rooms: abstracting problems, reusing solutions, and eventually stepping into data and machine learning.

Lessons for developers early in their careers

  • Follow the pull: If programming lights you up in your first year, honor that signal.
  • Disciplines compound: An electrical perspective enriches CS with system intuition and respect for constraints.

Applied research in Vienna: projects bridging industry and academia

After the master’s degree came applied research in Vienna: Austrian and European projects with academic partners.

“...working for the applied research centers in Vienna, where I got the opportunity to work on various European projects and Austrian projects, which involved academia and research...”

This environment rewards clean problem framing and results that transfer beyond prototypes. Along the way, Mislav had the opportunity to pursue doctoral studies in parallel:

“During my work at the research centers, I got the opportunity to do the doctoral studies, so I've been doing a PhD during my time at research...”

A PhD alongside applied projects fuses two strengths that modern ML and data teams need: methodological depth and product-minded realism. It’s a combination that helps turn promising ideas into dependable systems.

Why this blend matters

  • Research as a tool: Project-driven research makes outcomes operational.
  • Depth plus delivery: Academic rigor paired with a product lens creates durable value—and often sets the stage for leadership in data-heavy domains.

Moving into industry: Product impact at CYAN Security Group GmbH

After research came the move into industry. Today, Mislav serves as Research Engineering Lead at cyan Digital Security. The mission is crisp:

“At Cyan, I'm working as a lead for research engineering, we are collaborating with research centers in Austria, which are helping us to build better solutions, better cybersecurity solutions so that Cyan can better protect the customers.”

The strategy emerges clearly: partner with research institutions to keep improving cybersecurity products, with a direct aim—protecting customers. This is research for the sake of product capability.

How the work is organized

Mislav outlines three pillars:

  • Collaboration with research partners in Austria
  • Leading an interdisciplinary team of data engineers, data scientists, and software engineers
  • Focusing on machine learning as the lever for product improvement

“So my work involves working with the research partners, leading a research team of data engineers, data scientists and software engineers. So we work on various research topics, which lead to improved product, our cybersecurity products and we focus on machine learning...”

Research engineering here is bridgework. It speaks the language of academia and the language of product. It also requires leadership that translates priorities: Which research questions serve product security? Which ML approaches are ready for production-grade impact?

Machine learning in cybersecurity: Focus without buzzwords

Mislav’s description of ML stays deliberately plain. No hype—just a focus on making cybersecurity products better. That clarity translates into three practical tenets:

  1. Purpose over novelty: ML is for “better cybersecurity solutions,” not for showcasing technical possibility.
  2. Collaboration as a quality amplifier: Research partners contribute depth, rigor, and fresh ideas—vital as threats and data patterns evolve.
  3. Team complementarity: Data engineering, data science, and software engineering together ensure ML ships as product, not just notebooks.

Practical implications

  • Data quality is product quality: What data engineers enable shapes how robust ML becomes in use.
  • Scientific rigor guards against mirages: Solid evaluation, explicit assumptions, and reproducibility are non-negotiable in security contexts.
  • Integration is the real test: Ultimately, impact is measured in a product environment.

Leadership that translates: From idea to outcome

The role description implies the daily work of research engineering leadership: translate, prioritize, connect. Leading data engineers, data scientists, and software engineers means setting goals everyone can align with. Research partners widen the idea space; leadership channels that into product-relevant initiatives.

There’s no self-promotion in Mislav’s words—just a job to be done: “better cybersecurity solutions … better protect the customers.” In the end, what counts is effect.

Advice for aspiring ML engineers and data scientists

Mislav closes with concrete recommendations that are both simple and action-ready:

“...attend as much as possible data science contests where they can benchmark their solutions against others who are competing.”

“I would also recommend attending regular meetups where the industry talks are given by various companies...”

“And of course, to build themselves a profile on GitHub, which is publicly available...”

Three levers—simple and effective

  1. Data science contests: Benchmarking against others gives honest feedback. It sharpens ideas, deepens metric literacy, and shows progress.
  2. Regular meetups: Industry talks expose you to real problems, practiced approaches, and critical conversations.
  3. A public GitHub profile: Public work is a portfolio. It reveals how you think, document, and test—and lets others assess your potential.

Why these three?

  • They scale from small experiments to systematic growth.
  • They pair learning with visibility—knowledge needs to be findable and reviewable.
  • They tie feedback to progress—contests and community formats provide comparatives and resonance.

Our editorial takeaways

We experienced this session as a blueprint for building a career through steady, pragmatic steps. No shortcuts, no theatrics. Three constants stood out:

  • Craft first: Whether soldering or coding, skill is built at the workbench.
  • Depth through research: Academic rigor is an asset—especially when fused with applied projects.
  • Product impact as the goal: Research plus team execution plus collaboration yields improvements that protect customers.

All three align naturally with cybersecurity—a domain shaped by change. The path Mislav outlines shows how to stay oriented amid that change: clarity of purpose (“better cybersecurity solutions”), strong partners, and teams that treat data, models, and software as a coherent system.

Guardrails for your own path

Staying strictly within what was shared, we see a set of practical guardrails for developers navigating study, research, and industry:

  • Follow curiosity: The move from electrical engineering to CS began with genuine pull toward programming, then continued through bachelor’s and master’s.
  • Seek the overlap of theory and practice: Applied research with academic depth builds method competence without losing real-world relevance.
  • Learn in competition, share in community, document in public: Contests, meetups, GitHub—three ways to make capability visible and better.
  • Think in systems and products: ML is a means to protect customers. That demands data pipelines, models, infrastructure, and team alignment.

A straight line: Consequence over spectacle

The power of this story is its simplicity. A technical start, a deliberate shift, years of applied research with a PhD, and a leadership role that connects research to product. Less narrative flair, more substance—and a useful model. In tech careers, consistency is underrated: taking time to learn things thoroughly; submitting ideas to benchmarks; engaging communities; and building results that hold up in production.

Conclusion: What matters—and how to get there

From “Mislav Findrik, Research Engineering Lead at cyan Digital Security,” we carry three core ideas:

  • Practical foundations: Electronics and early programming build a robust base.
  • Research as catalyst: Industry–academia projects, paired with doctoral study, shape a mindset that makes product improvement systematic.
  • Leadership through connection: Partnering with research, leading interdisciplinary teams, and focusing on ML lead to better cybersecurity solutions—with direct benefits for customers.

For aspiring ML engineers and data scientists, the speaker’s advice is pragmatic and precise: compete to benchmark, attend to learn, and publish to be seen. For the broader tech community, it’s a reminder that progress is built from many small, consistent steps—and that the best research is the kind that ships and protects.

More Tech Lead Stories

More Dev Stories