Logo HID Global GmbH

HID Global GmbH

Established Company
Show all Videos

Anna Dziarkowska, Software Engineer bei HID Global

Description

Anna Dziarkowska von HID Global erzählt im Interview wie sie zum Software Engineering gekommen ist, mit welchen Themen sie sich aktuell als Software Engineer beschäftigt und was sie Anfängern empfehlen würde.

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

Video Summary

In "Anna Dziarkowska, Software Engineer bei HID Global," Anna Dziarkowska traces her path from a love of math and problem solving to discovering programming during an Electronics and Telecommunication degree in Kraków, starting as an intern at HID Global and joining the R&D team, now favoring C# after beginning with C. She builds a library that underpins the test bench and developer enablement tools—web UIs, command-line tools, and AWS functionality—enjoying modern tech and emphasizing architecture to adapt to shifting requirements. Her advice: follow hands-on tutorials (like a simple game), learn to break large features into small connected tasks, and note that a technical university degree can ease the start and help clarify interests.

From Math and Problem Solving to C# and R&D: The Developer Journey of Anna Dziarkowska (HID Global GmbH)

What stood out in “Anna Dziarkowska, Software Engineer bei HID Global”

Listening to “Anna Dziarkowska, Software Engineer bei HID Global” (Speaker: Anna Dziarkowska, Company: HID Global GmbH), we heard a compact, clear journey: an early love for math and problem solving, a broad technical degree that opened options, a student internship that became a full‑time path, and a present‑day focus on architecture and developer enablement in R&D. Throughout, Anna grounds her story in first principles: choose tools that fit the problem, keep architecture adaptable, and learn by building small, tangible projects.

“For me it all started with basically love for math and problem solving.”

“It’s more for a problem that you need to solve and what fits this problem. So it’s not really about the language itself.”

These remarks frame a mindset that transfers well across teams and technologies: clarity of purpose, a bias for practicality, and an appreciation for design that survives changing requirements.

The spark: math first, programming later

Anna encountered programming in high school but didn’t expect it to become her profession. The turning point came at university: once she started coding in earnest, she realized she genuinely enjoyed it. This arc is familiar to many engineers—what hooks you isn’t necessarily the syntax of a language but the structure and reasoning of solving real problems.

  • Early drivers: a taste for logic and systematic thinking.
  • Academic inflection point: university work made programming click.
  • Lasting lesson: don’t fetishize tools—optimize for the problem at hand.

A broad degree to keep doors open

Anna studied Electronics and Telecommunication at a technical university in Kraków, choosing the field precisely because it covered a wide range of topics while she was still unsure about a future specialization.

“I chose this field because it covered a wide spectrum of topics and I wasn’t sure myself what I would like to do with my profession. But I soon realized that I really enjoy programming.”

For students who want enough breadth to discover what fits, this is instructive. A broad curriculum supplies context and cross‑disciplinary awareness—useful later when architecture demands trade‑offs that span hardware, protocols, and software.

Languages as means, not ends

Anna’s first language was C; today she enjoys C# the most. Yet the more important throughline is her problem‑first approach.

“My first language was probably C. But for me, it’s more for a problem that you need to solve and what fits this problem. So it’s not really about the language itself. But now I enjoy working with C Sharp the most.”

What we take from this:

  • Tool fit over tool worship: choose languages and frameworks by how well they map to requirements.
  • Breadth unlocks modeling options: exposure to different paradigms makes trade‑offs clearer.
  • Practice beats fashion: let use cases and quality attributes drive the stack, not trends.

Intern to engineer: growing with HID Global GmbH

Anna joined HID Global GmbH during her studies as an intern and has now been with the company for four years, working as a Software Engineer in R&D. It’s a linear, credible path: early exposure to practical work, then deepening responsibility within a technical team.

“I started four years ago at the company, but I started as an intern. So I applied still during my studies for an internship there. And now I’m a part of an R&D team.”

For aspiring engineers, the playbook is straightforward:

  • Apply early: internships translate coursework into production‑minded code.
  • Build relevance: real problems, even in small scope, create tangible signals of capability.
  • Grow inside the system: internships can turn into long‑term roles when curiosity and contribution align.

Building the backbone: library, test bench, and developer enablement

In R&D, Anna is responsible for developing a library that acts as a backbone for the team’s test bench as well as other developer tools and enablement utilities. The scope includes web UI interfaces for developers, command‑line tools, and “any AWS functionality.”

“I am responsible for developing a library that is a backbone for our test bench and also for other development developers tools or enablement tools. So we build some web UI interfaces for developers or command line tools or any AWS functionality.”

Several themes stand out in this brief description:

  • Developer productivity front and center: enablement tools reduce friction and raise quality.
  • Testability and reuse: a shared library for the test bench reinforces consistency.
  • Wide touchpoints: from UI to CLI to cloud functionality—breadth is part of the job.

It’s a portrait of R&D that’s notably practical: building foundations others can rely on, and doing so across interfaces that developers use daily.

Enjoying modern tech—while treating architecture as non‑negotiable

Anna highlights two sources of motivation: working with modern technologies and designing new features. Her strongest emphasis, however, is on architecture, especially because requirements change frequently and teams need to adapt quickly.

“What I really enjoy about my job is that I am fortunate to work with modern technologies. And I also like to design new features and solve other problems. I think we really need to also focus on architecture since the requirements that we have are changing a lot. So we need to be able to adapt quickly.”

If requirements evolve often, architecture is the lever that sustains both speed and robustness. For engineering teams, this typically implies:

  • Good boundaries: design modules and interfaces to localize change.
  • Evolvability: plan for extension without breaking what works.
  • Clarity: record and communicate decisions so adaptation stays coherent across the team.

It’s a cultural point as much as a technical one: architecture is not academic—it’s what keeps a codebase maneuverable when reality shifts.

Adaptation as a rhythm, not an exception

The need to adapt quickly, as Anna describes it, is a day‑to‑day posture. Architecture sets the stage; disciplined increments and a steady learning cadence do the rest. Especially when a codebase spans test infrastructure, developer tools, and cloud functionality, changes in one place can ripple. A well‑designed library helps channel that complexity.

Practical patterns that support this:

  • Make change small and observable—ship in slices.
  • Minimize and expose dependencies—reduce surprise.
  • Keep decisions reversible when possible—enable safe experimentation.

This dovetails directly with Anna’s advice on how to start learning and how to structure work.

Learning path: tutorials and small, motivating projects

Anna’s entry recommendation is concrete: follow a tutorial and build something small—a simple game or a feature you personally care about. For her, that was the most effective way to begin.

“I would recommend starting with a tutorial, for example, to follow a programming tutorial to create an easy game or any feature you’re interested in to look it up and follow a tutorial. For me, it was the best way to start.”

Why this works:

  • Low friction: a guided track lowers the barrier to begin.
  • Immediate feedback: small wins keep motivation high.
  • Practice over abstraction: you learn the mechanics by doing, then generalize.

A minimal playbook for newcomers:

  1. Pick a tiny project that you actually want to see running.
  2. Follow a well‑structured tutorial end‑to‑end, including debugging and small variations.
  3. After shipping, reflect: what did you learn, what broke, what patterns repeat?

Split big features into small tasks—then reconnect them

Anna also points to a core engineering competency: decomposing a large feature into smaller tasks so it’s easier to implement and understand—and then connecting those parts into a coherent whole.

“It’s helpful also if you know how to split a big feature into smaller tasks. So it’s easier to implement for everybody and also to understand, but you need to be able to connect it somehow.”

Decomposition without integration yields silos. Integration without good decomposition yields chaos. The balance typically rests on:

  • Clear, incremental goals: define the smallest valuable slices.
  • Interfaces as contracts: specify inputs/outputs and expectations.
  • Feedback loops: after each slice, verify the overall design still holds.

Teams that practice this rhythm make steady progress and avoid the trap of “big bang” merges.

A technical degree as a helpful on‑ramp and exploration space

Anna is explicit that her technical degree helped her—both by making the start easier and by giving her a clearer sense of what she liked.

“I think it also helps to have a degree from a technical university, at least for me, then short and easier start. And also, I wasn’t sure myself what I wanted to do. And this also gave me an idea what I like the most and how to continue from that.”

This isn’t a judgment on other paths; it’s a personal assessment. A structured program can provide:

  • Breadth: exposure to multiple areas to test interests.
  • Time and scaffolding: room for projects, internships, and electives.

When paired with real‑world practice—internships, student jobs, small side projects—a degree can accelerate the transition into roles like the one Anna holds now.

Day‑to‑day impact: R&D in service of developer experience

Even with few operational details, Anna’s outline conveys a practical mission: build the backbone for testing and developer enablement—libraries, web UIs, CLIs, AWS functionality. That’s a developer experience mandate: reduce friction, standardize what repeats, and bring testing closer to everyday work.

Her recurring themes translate cleanly to this mission:

  • Design features consciously: think about how parts fit together before building.
  • Treat architecture as ongoing: revisit decisions as requirements shift.
  • Use modern tech deliberately: choose it because it fits, not because it’s shiny.

Concrete takeaways for engineers and teams

We distilled the following, based on Anna’s remarks:

  • Start small and concrete: a tutorial plus a tiny project is a strong on‑ramp.
  • Think in problems, not languages: pick tools for fit.
  • Decompose and reconnect: slice features into small tasks and design the integration.
  • Respect architecture: fast‑changing requirements demand structures that survive change.
  • Seek early practice: internships bridge study and production work.
  • Keep learning: let curiosity about problem solving guide your next step.

Quotes worth remembering

A few lines from Anna capture the essence succinctly:

“It’s not really about the language itself.”

“We need to be able to adapt quickly.”

“For me, [following a tutorial] was the best way to start.”

They’re simple, but they’re durable. They describe teams that ship reliably: tools as means, architecture as leverage, learning as a habit.

Closing thoughts: a career powered by curiosity

“Anna Dziarkowska, Software Engineer bei HID Global” sketches a developer’s path many can relate to: math and problem solving as the seed, a broad technical degree as a discovery space, an internship that led to R&D, and an everyday focus on building the foundations others rely on—library, test bench backbone, web UIs, command‑line tools, and AWS functionality at HID Global GmbH.

From our DevJobs.at editorial vantage point, the throughline is clear: love the problem, choose tools by fit, use architecture to keep pace with change, and learn by building. That combination—problem first, architecture as enabler, learning as default—runs through Anna’s story and makes it relevant for developers at any stage.

More Tech Talks

More Tech Lead Stories

More Dev Stories