Nuki Home Solutions
Albert Kemetinger, Lead Firmware Developer bei Nuki
Description
Albert Kemetinger von Nuki spricht im Interview über seinen Weg mit dem Programmieren – angefangen von Basic und programmierbaren Taschenrechner, bis hin zu seiner aktuellen Arbeit als Lead Firmware Developer – und gibt Hinweise für Newcomer
By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.
Video Summary
In "Albert Kemetinger, Lead Firmware Developer bei Nuki," Albert Kemetinger traces his path from early school and calculator BASIC, through C/C++ at a Higher Technical College and electronics with a biomedical focus in Graz, to roles in satellite navigation research and a major semiconductor firm before leading firmware at Nuki. He explains the appeal and demands of firmware—being close to hardware, constant new problems, and high product impact under tight RAM/Flash/power constraints—and his responsibility for architecture and code quality alongside the soft skills required to lead a team. His advice: learn by doing after grasping fundamentals, build hardware experience, and start with small projects on platforms like Arduino or Raspberry Pi while tinkering at home and researching online.
From Calculator Games to Firmware Leadership: Albert Kemetinger, Lead Firmware Developer at Nuki, on learning by doing, tight constraints, and team skills
Highlights from the session “Albert Kemetinger, Lead Firmware Developer bei Nuki”
In the session “Albert Kemetinger, Lead Firmware Developer bei Nuki,” Speaker Albert Kemetinger of Nuki Home Solutions shared a grounded, hands-on view of a firmware career that starts in school and moves through higher technical education, research, semiconductor industry work, and ultimately a leadership role. Along the way, a clear thread emerges: curiosity close to the hardware, a love for optimization, and acceptance that good firmware requires both technical discipline and soft skills.
One statement anchors the whole story:
“We firmware developers bring the life into this hardware.”
From DevJobs.at’s editorial vantage point, this talk reads like a concise field guide: keep solving new problems, take ownership of architecture and code quality, and treat RAM, Flash, and power budgets as non‑negotiable context, not afterthoughts.
Early sparks: school informatics and BASIC on a calculator
Kemetinger’s first contact with programming happened “in the 2nd school,” in a setting where informatics was available and the first basics became tangible. The most vivid image is his programmable calculator — a small laboratory for logic and numbers:
“Also my calculator could program basics. There I made a few smaller games with numbers.”
This kind of start is telling. Small, playful projects can become the seed of a professional path. Learning, here, means making — and making starts wherever you are, even on a calculator.
HTL, C/C++, and the fascination of Assembly
Formal depth followed at the Higher Technical College (HTL), where C and C++ took center stage. Kemetinger underscores that these were the languages he liked early on. He also points to Assembly as a source of genuine fascination — not for nostalgia, but for control and performance:
“I liked the first programming language C and C++, which I learned in the HTL … But I am also very fascinated by how performant code can be written when you use Assembly.”
For firmware work, that trio is emblematic. C is the workhorse, C++ extends design possibilities, and Assembly is the precision tool when every instruction counts. If you’re drawn to firmware, you’ll likely meet these languages early and often.
Education and early career: Salzburg, Graz, research, semiconductors — and then Nuki
Kemetinger sketches his path succinctly. He began at the Higher Technical College in Salzburg, then moved to Graz to study electronics “in biomedical.” His professional journey started at a research company in satellite navigation. Next came a large semiconductor manufacturer, where he worked in the firmware department. Today, he serves as the firmware development lead at Nuki:
“My first professional career was in a research company in the field of satellite navigation. After that I [joined] a big semiconductor manufacturer. There I worked in the firmware department. And now I work at Nuki as firmware development lead.”
The stations line up around the same axis: the interface of electronics and software. Research sharpened the fundamentals, industry demanded robust delivery, and product work converges all of that into shipping devices that just work.
Why firmware never gets boring
Asked what he enjoys most about firmware, Kemetinger reaches for a sentiment most embedded engineers will recognize:
“It will never be boring. And I have a big influence on the products we develop.”
New problems keep the work fresh. Firmware is not a routine; it’s an ongoing negotiation with chips, peripherals, and limits. There’s also the immediacy of impact: firmware decisions shape how a product behaves. The anchor is his simple observation:
“Nowadays electronics are everywhere. We firmware developers bring life into this hardware.”
That’s not a slogan; it’s an accurate job description. Without firmware, electronics are inert. In this field, you contribute to the moment a device becomes truly functional — and you take responsibility for reliability and efficiency.
Living with constraints: RAM, Flash, and power
A central part of the job is treating constraints as reality: RAM, Flash, and power. Kemetinger puts it plainly:
“We are very close to the hardware. Therefore we are mostly restricted … to low resources like RAM, Flash, or power. Therefore we have to optimize a lot.”
This is not an optional preference. In firmware, efficiency isn’t a nice-to-have — it’s the default. It drives architectural decisions, data structures, and the use of tools and toolchains. For developers coming from resource-rich environments, this is a mindset shift. The hardware won’t bend; code and design must.
Technology and tools: it depends on the chip — currently C and Eclipse IDE
Kemetinger emphasizes that favorite technologies depend on the chip. At the moment, he programs in C and uses the Eclipse IDE:
“At the moment I program with C and with Eclipse IDE.”
That’s a pragmatic choice in embedded contexts. Tools follow the chip and the project, not the other way around. Flexibility is part of the craft.
Architecture and code quality: responsibility you can feel
Alongside daily development, Kemetinger owns architecture and code quality:
“I am responsible for the entire architecture. I am responsible for the quality of the code.”
Architecture sets the shape of what’s possible; code quality determines whether it stays reliable over time. In firmware, this coupling is stark. Clean architecture captures hardware specifics without leaking them everywhere. Quality practices keep the code legible, testable, and efficient — crucial when a few kilobytes and milliwatts make the difference.
Leading means leading people: soft skills and “interhuman” topics
Kemetinger is frank about the challenges of being a firmware lead. Beyond sizable technical responsibility, there’s the human side:
“You have to deal with soft skills because you are leading a team. And you have to deal with interhuman problems.”
Leadership in firmware isn’t purely technical. It’s also about communication, expectations, compromise, and conflict resolution. Technical excellence doesn’t magically produce great teamwork; it must be paired with soft skills.
The best tip for beginners: learn by doing
Asked about advice for beginners, Kemetinger’s answer is unequivocal:
“I think the best tip for beginners is that you learn what you do. If you program a lot, you get great experience.”
An introductory course helps to grasp fundamentals. But then, do:
“Of course it helps if you have an introduction to understand the basic concepts of programming.”
For aspiring firmware developers, some hardware exposure is especially helpful:
“Any education in the direction of programming is useful. But especially for a firmware developer it is good to learn a bit of hardware and get hardware experience.”
He suggests accessible options: online courses and small projects using mainstream platforms:
“An online course would be a cheap possibility. Then just try platforms like Arduino or Raspberry Pi and do small projects.”
Most importantly, keep projects small and avoid early frustration:
“It is important that you start with small, simple projects and do not frustrate yourself with too complex projects.”
And keep learning outside of work:
“I [learn] not only through work but also at home. I play with new stuff, do internet research and that is the right way.”
What we, as editors, take away
Three axes stand out from this session: closeness to hardware, accountability for structure and quality, and learning as practice. Kemetinger’s path — from calculator BASIC to C/C++, a respect for Assembly, and on to leadership — spells out a professional identity with precision at its core.
- Firmware is impact: it makes electronics live. That’s meaningful — and it demands care.
- Scarcity is a teacher: RAM, Flash, and power draw the lines. Optimization is the standard, not a special mode.
- Leadership is tech plus people: responsibility for architecture and quality must be matched with soft skills and team guidance.
- Learning is a practice: small projects, steady repetition, the right dose of fundamentals. Continue at home, explore new things, research online.
Together, these points form a compass for sustained, healthy practice in firmware teams.
Practical steps for aspiring firmware developers
If you want to follow Kemetinger’s advice, start with clear, small moves:
- Cement fundamentals: take an intro course to understand data types, control flow, memory, and simple systems concepts.
- Embrace C early: write your first microcontroller programs to exercise thinking within constraints.
- Use micro platforms: leverage Arduino or Raspberry Pi to build sensor/actuator experiments.
- Set small goals: pick mini-projects (e.g., a simple measurement, an LED pattern, a serial exchange) rather than complex systems.
- Grow iteratively: add one new detail per project — interrupts, logging, observing resource usage.
- Bake in code quality: readable functions, clear naming, simple tests — from day one.
- Practice architecture in small: modularize, encapsulate hardware access, define interfaces explicitly — even in small apps.
- Keep the rhythm: keep learning at home, read online sources, try new parts — as Kemetinger describes.
This is not a formula, but a practice track. The point is to keep momentum and treat the hardware as your teacher.
For leads: create conditions for quality
Kemetinger’s description of his lead responsibilities points straight at what matters:
- Make architecture explicit: document decisions, expose dependencies, call out resource budgets (RAM, Flash, power).
- Operationalize code quality: review norms, clear definitions of done, simple baselines for readability and efficiency.
- Support soft skills: create space for exchange, feedback, and conflict resolution — “interhuman” topics will surface.
- Choose tools pragmatically: chips and projects drive tools; flexibility is part of professionalism.
As ever, less can be more. Aim for clear principles over sprawling toolchains. Focus on feasibility and maintainability.
Guiding lines from the talk — in his spirit
A few lines from the session read like enduring guidance:
- “Electronics are everywhere” — and firmware makes them live.
- “It will never be boring” — new problems keep learning alive.
- “We have to optimize a lot” — treat constraints as a virtue.
- “Architecture and code quality” — two sides of the same responsibility.
- “Start small” — avoid frustration and build momentum.
- “Keep learning at home” — it’s a mindset, not a meeting.
These make the difference between just writing code and crafting robust firmware.
Closing note: a straight, learning-centric career
The session “Albert Kemetinger, Lead Firmware Developer bei Nuki” traces a career that begins with small number games on a calculator and, through clear educational and industry steps, grows into leadership. The throughline is steady: C, C++, a fascination with Assembly, closeness to hardware, a willingness to face new problems, and the recognition that people, ultimately, build products together.
For anyone drawn to firmware — or already in it — the message is encouraging: start small, stay close to the hardware, optimize with care, own architecture and quality, and invest in soft skills. Or, to paraphrase Kemetinger: program — program a lot — and never stop exploring new things.
