DEV Community: zaina ahmed

"Beyond the Booth: How the Elevation 2026 Careers Expo by Engineers Australia sharpened My Edge in Australia's Tech Industry"

zaina ahmed — Wed, 01 Apr 2026 08:05:57 +0000

There are moments in your career that don't just add a line to your resume but they reshape how you see yourself professionally.

For me, that moment was walking into the Elevation 2026 Careers Expo by Engineers Australia at the Perth Convention and Exhibition Centre.

I attended as a Software Engineer with 2+ years of enterprise experience at Ericsson actively building Java microservices, Apache Kafka systems, and cloud-native infrastructure while simultaneously exploring what Australia's technology landscape has to offer someone with my background.

I came away with something far more valuable than a stack of business cards, genuine clarity, real confidence, and a sharp understanding of exactly where my skills fit in Australia's technology landscape.

This is the story of what happened, what I learned, and what it means for any internationally trained engineer looking to grow their presence in the Australian tech market.

🌏 The Context — An Engineer Expanding Her Horizons

Being part of Ericsson's engineering team while based in Perth, Western Australia puts me in an interesting position. The technical work is world-class building distributed systems at global telecom scale teaches you things that are hard to learn anywhere else.

But the professional ecosystem here is how engineers present themselves, what Australian employers actually look for, how relationships get built in this market that requires a completely different kind of learning. One that no amount of LeetCode practice or certification studying can give you.

The technical skills are universal. Java microservices work the same way in Perth as they do anywhere in the world. Apache Kafka doesn't care which continent you're on. Docker containers run identically regardless of timezone.

What isn't universal is understanding how to position those skills effectively in a new market and that's exactly what I came to the Elevation Expo to explore.

🏛️ Walking Into the Room — First Impressions

The Perth Convention and Exhibition Centre was buzzing. Engineers, recruiters, industry leaders, and emerging professionals filled the space. All gathered under one roof with one shared purpose: to connect the talent of tomorrow with the opportunities of today.

What immediately struck me was the diversity of industries represented. This wasn't just a software job fair. This was Australia's engineering ecosystem in microcosm. Infrastructure, resources, technology, construction, utilities, and everything in between.

For a Software Engineer whose work at Ericsson touches telecommunications infrastructure, cloud-native systems, and automation at scale, this breadth was genuinely exciting. My skills aren't niche here, they're relevant across multiple sectors.

🤝 The Conversations That Changed My Perspective

The most valuable part of any careers expo isn't the brochures or the booths. It's the unscripted conversations with people who are actually working in the industry you want to grow into.

My conversations with Katie Ryan, Mohammadreza Fekri, Seda Aygun, and Kaveen Lekamalage were exactly that honest, direct, and incredibly insightful.

Three things came up repeatedly across these conversations:

1. Australian employers value demonstrated impact over job titles

It's not enough to say you work at Ericsson. What do you build? What changes because of your work? What numbers can you attach to your contributions?

This aligned perfectly with how I frame my experience:

Reduced manual configuration time by 80% through a Kubernetes pod connectivity framework
Cut QA effort by 40% through 150+ automated test suites
Saved 40–60% in infrastructure costs through containerization

Specificity isn't bragging in Australia's tech market, it's expected.

2. Cloud-native and automation skills are in extremely high demand

Every conversation touched on this. Australian organizations across industries, not just pure tech are accelerating their cloud adoption. Engineers who can bridge the gap between traditional infrastructure and modern cloud-native architectures are rare and highly sought after.

My background in Docker, Kubernetes, Kafka, and CI/CD pipelines isn't just relevant to software companies. It's relevant to Bechtel, DT Infrastructure, Aurecon, and every major engineering firm modernizing their technology stack.

3. Personal brand matters as much as technical skill

This was the most unexpected insight. Multiple professionals mentioned that the engineers who stand out aren't always the most technically brilliant, they're the ones who can communicate their value clearly, confidently, and consistently.

This is something I've been actively building through this blog, my portfolio, and the way I present my experience in conversations like these.

🏢 Engaging With Industry Leaders

Bechtel Corporation

Speaking with the Bechtel team was a masterclass in understanding how software engineering intersects with large-scale civil and infrastructure projects. Their need for engineers who understand both the technical depth of systems engineering and the operational realities of major projects resonates deeply with my experience building reliable, fault-tolerant systems at Ericsson.

DT Infrastructure

DT Infrastructure's focus on digital transformation in Australia's infrastructure sector opened my eyes to how cloud-native technologies I work with daily containerization, event-driven architecture, automated pipelines are being applied to solve challenges far beyond traditional software contexts.

RSGx

The RSGx team's warmth was memorable. A genuine conversation, not a sales pitch. Their perspective on what makes engineers valuable in Australia's market reinforced that technical competence is the baseline, but curiosity, adaptability, and communication elevate you above the field.

Aurecon

Aurecon's presence highlighted the growing intersection of engineering consulting and technology. As firms like Aurecon increasingly deliver technology-enabled solutions, the demand for engineers who can operate comfortably across both technical and business domains is accelerating rapidly.

💡 What I Realized About My Own Value

Standing in that room, talking to these professionals, something clicked.

The skills I'm building at Ericsson, designing distributed systems, automating infrastructure, building reliable pipelines at scale are not just relevant to telecommunications. They are directly transferable to every major industry represented at that expo.

For infrastructure companies: My experience with Kubernetes orchestration and automated deployment pipelines maps directly to their needs for reliable, scalable operational systems.

For consulting firms: My ability to diagnose complex system problems, communicate findings clearly, and implement targeted solutions is exactly what consulting environments demand.

For technology companies: My Java microservices, Kafka, and CI/CD expertise speaks directly to their core engineering needs.

The expo didn't just help me understand Australia's market. It helped me understand that I had been underestimating the breadth of my own relevance.

🚀 What Building a Personal Brand Actually Means

One of the most repeated pieces of advice I received at the expo was this:

"The best time to build your brand was five years ago. The second best time is right now."

But what does "personal brand" actually mean for a software engineer? It's not about self-promotion or LinkedIn performance. It's about making your value visible and consistent across every touchpoint: your resume, your GitHub, your portfolio, your conversations, your writing.

Here's what I've been doing intentionally alongside my work at Ericsson:

1. Portfolio website
Built with Next.js and React, my portfolio at zee-projects.vercel.app showcases my projects, skills, and experience in a way that a resume simply can't. Every conversation I have now ends with: "Check out my portfolio."

2. Technical writing
This blog series covering Kafka, Docker, Kubernetes, prompt engineering, and now this is my way of demonstrating that I don't just use these technologies. I understand them deeply enough to teach them.

3. Showing up in the room
The Elevation Expo proved that nothing replaces physical presence. Being in the room, having real conversations, making eye contact with the people who make hiring decisions, this is irreplaceable.

4. Consistency over perfection
One article a week. One GitHub commit a day. One meaningful LinkedIn post per event I attend. Small, consistent actions compound into a brand that's hard to ignore.

📊 The Australian Tech Market — What I Now Understand

After the expo, here's my clearer picture of what Australian employers are actually looking for:

What They Say	What They Mean
"Strong communication skills"	Can you explain complex systems to non-technical stakeholders?
"Self-starter"	Will you take initiative without waiting to be told?
"Cultural fit"	Are you collaborative, direct, and genuine?
"Relevant experience"	Can you show specific impact, not just job descriptions?
"Passionate about technology"	Do you keep learning outside of work hours?

Every single one of these I can speak to, with specific examples, real numbers, and genuine enthusiasm.

🌟 The Moment That Meant the Most

Amid all the professional conversations and industry insights, the moment that meant the most was simpler than any of that.

It was standing in that room, surrounded by Australia's engineering community, realising that I belonged there.

Not because I had the most impressive title. Not because I knew everyone in the room. But because I am building something real, skills that matter, systems that work, a track record of solving hard problems and I am ready to bring that fully to Australia's technology ecosystem.

That realization, that quiet, confident I belong here is worth more than any job offer.

🔮 What's Next

The Elevation Expo was a catalyst, not a destination.

While continuing to build enterprise-grade systems at Ericsson, I am actively exploring opportunities across Perth and broader Australia where I can contribute and grow my expertise in:

Java microservices and distributed systems
Apache Kafka and event-driven architecture
Docker, Kubernetes, and cloud-native infrastructure
CI/CD pipeline automation and DevOps practices
AI-assisted development and prompt engineering

If you're building something challenging and need an engineer who brings both technical depth and genuine enthusiasm — let's talk!

And if you're an internationally trained engineer navigating Australia's tech market for the first time, the Elevation Expo is one of the best investments of time you can make. Show up, be genuine, and trust that the skills you've built have real value here.

They do. I promise.

💬 A Genuine Thank You

To Katie Ryan, Mohammadreza Fekri, Seda Aygun, and Kaveen Lekamalage, thank you for your time, your candour, and your generosity in sharing your perspectives. Those conversations mattered more than you know.

To the teams at Bechtel Corporation, DT Infrastructure, RSGx, and Aurecon, thank you for engaging genuinely with an engineer who is passionate about contributing to Australia's technology landscape. The insights you shared will shape how I approach the next chapter of my career.

To Engineers Australia and the Elevation Expo organizers, thank you for creating a space where connections like these are possible.

The conversations have started. The opportunities are ahead.

Looking forward to what's next. 🚀

I'm Zaina Nazimudeen Ahmed, a Software Engineer currently at Ericsson, based in Perth, Australia, building Java microservices, Apache Kafka systems, and cloud-native infrastructure. I'm actively exploring opportunities in Australia's technology sector while continuing to grow my expertise at Ericsson.

Connect with me on LinkedIn, explore my work at zee-projects.vercel.app, or reach out directly at zainaahmed003@gmail.com.

If this resonated with you, whether you're an engineer navigating a new market or an employer looking for someone exactly like this, drop a comment or a ❤️. Let's connect.

How I Cut Infrastructure Costs by 60% by developing a Fast Feedback Development Platform using containerization technologies.

zaina ahmed — Wed, 01 Apr 2026 06:16:38 +0000

When I joined Ericsson's R&D team as an intern, our development environment had a problem that every engineer on the team silently accepted as normal: spinning up a full local environment took over 30 minutes, consumed enormous cloud resources, and cost the team 40–60% more in infrastructure than it needed to.

Six months later, I managed to cut that cost by 60%, reduced memory footprint per machine by 60%, and validation time from 30 minutes to under 10 minutes by smartly optimizing resources.

The tools that made it possible? Docker and Kubernetes.

This is exactly how I did it.

🐳 What Is Docker — And Why Should You Care?

Before Docker, deploying software meant:

"It works on my machine" — classic
Different OS versions breaking builds
Manual dependency installation on every server
Hours wasted on environment setup

Docker solves this by packaging your application and everything it needs into a single portable unit called a container.

Think of it like this:

Without Docker	With Docker
"Install Java 17, then Maven, then..."	`docker run my-app`
Works on my machine, breaks on server	Runs identically everywhere
Manual environment setup per developer	One command, same environment
Dependency conflicts between services	Each container is isolated

📦 Docker Basics — The Essential Commands

Your first Dockerfile:

# Start from official Java 17 base image
FROM eclipse-temurin:17-jre-alpine

# Set working directory inside container
WORKDIR /app

# Copy the built jar file
COPY target/notification-service.jar app.jar

# Expose the port your app runs on
EXPOSE "port-number"

# Command to run when container starts
ENTRYPOINT ["java", "-jar", "app.jar"]

Build your image:

# Build the Docker image and tag it
docker build -t notification-service:1.0 .

# Verify it was created
docker images

Run your container:

# Run container on port "port_number"
docker run -p "port_number":"port_number" notification-service:1.0

# Run in background (detached mode)
docker run -d -p "port_number":"port_number" --name notification notification-service:1.0

# Check running containers
docker ps

# View logs
docker logs notification

# Stop container
docker stop notification

🔗 Docker Compose — Running Multiple Services Together

A real application has multiple services, your app, a database, Kafka, Redis. Docker Compose lets you define and run them all together.

Our notification service stack:

# docker-compose.yml
version: '3.8'

services:
  # Spring Boot notification service
  notification-service:
    build: .
    ports:
      - "port_number":"port_number"
    environment:
      - SPRING_PROFILES_ACTIVE=dev

  # PostgreSQL database
  postgres:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB: notifications
      POSTGRES_USER: "user_name"
      POSTGRES_PASSWORD: "password"
    volumes:
      - postgres-data:/var/lib/postgresql/data
    networks:
      - notification-network

  # Apache Kafka
  kafka:
    image: confluentinc/cp-kafka:7.4.0
    depends_on:
      - zookeeper
    ports:
      - "port_number":"port_number"

  # Zookeeper (required by Kafka)
  zookeeper:
    image: confluentinc/cp-zookeeper:7.4.0

  # Redis cache
  redis:
    image: redis:7-alpine
    ports:
      - "port_number":"port_number"
    networks:
      - notification-network

networks:
  notification-network:
    driver: bridge

volumes:
  postgres-data:

Start everything:

# Start all services
docker-compose up -d

# Check all running
docker-compose ps

# View logs for specific service
docker-compose logs -f notification-service

# Stop everything
docker-compose down

# Stop and remove volumes (fresh start)
docker-compose down -v

☸️ What Is Kubernetes — And When Do You Need It?

Docker Compose is great for local development. But in production you need:

Auto-scaling — handle traffic spikes automatically
Self-healing — restart crashed containers automatically
Load balancing — distribute traffic across instances
Rolling updates — deploy new versions with zero downtime

This is what Kubernetes does.

Kubernetes (K8s) is a container orchestration platform that manages your containers in production, deciding where they run, scaling them up and down, and keeping them healthy.

🏗️ Core Kubernetes Concepts

Pod

The smallest unit in Kubernetes, one or more containers running together.

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: notification-pod
spec:
  containers:
    - name: notification-service
      image: notification-service:1.0
      ports:
        - containerPort: "port_number"

Deployment

Manages multiple pod replicas and handles rolling updates.

Service

Exposes your pods to network traffic — internal or external.

🛠️ How We Used Kubernetes-in-Docker (Kind) at Ericsson

Running full Kubernetes clusters in the cloud for every developer is expensive. We solved this using Kind (Kubernetes in Docker) — a tool that runs a full Kubernetes cluster inside Docker containers on your local machine.
Note: Kind is a multi-node cluster suitable for fast, lightweight, and disposable Kubernetes testing and development directly on a local machine.

Install Kind:

# On Linux/WSL
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.20.0/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

# Verify
kind version

Create a local cluster:

# Create cluster
kind create cluster --name kind

# Verify it's running
kubectl cluster-info --context kind-kind

# See nodes
kubectl get nodes

Deploy our notification stack locally:

# Apply all manifests
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

# Check deployments
kubectl get deployments

# Check pods
kubectl get pods

# Check logs
kubectl logs -f deployment/notification-deployment

# Scale up to 5 replicas
kubectl scale deployment notification-deployment --replicas=5

🎯 Helm — Kubernetes Package Manager

Managing dozens of YAML files manually gets messy fast. Helm is the package manager for Kubernetes, it templates and packages all your Kubernetes manifests into reusable charts.

Install Helm:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Create a Helm chart:

helm create notification-chart

Chart structure:

notification-chart/
├── Chart.yaml          ← chart metadata
├── values.yaml         ← default configuration values
└── templates/
    ├── deployment.yaml ← deployment template
    ├── service.yaml    ← service template
    └── configmap.yaml  ← config template

values.yaml — configure everything in one place:

replicaCount: 3

image:
  repository: notification-service
  tag: "1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: "port_number"

Deploy with Helm:

# Install chart
helm install notification ./notification-chart

# Upgrade with new values
helm upgrade notification ./notification-chart \
  --set replicaCount=5 \
  --set image.tag=2.0

# Check releases
helm list

# Rollback to previous version
helm rollback notification 1

This is exactly how we scaled down 10+ microservices at Ericsson, reducing memory footprint by 60% by optimising the resources.requests values in each chart's values.yaml.

📊 The Results at Ericsson

Here's what we achieved after moving to a fully containerised, Kubernetes-orchestrated setup:

Metric	Before	After	Improvement
Environment setup time	30+ mins	Under 10 mins	3x faster
Cloud infrastructure cost	Baseline	Reduced	40–60% saving
Memory per developer machine	Baseline	Optimized	60% reduction
Manual configuration steps	~20 steps	1 command	95% reduction
Onboarding time for new developers	2 days	2 hours	8x faster

🐛 Mistakes I Made (So You Don't Have To)

1. Not setting resource limits

# ❌ Wrong — no limits, one service can eat all memory
containers:
  - name: my-service
    image: my-service:1.0

# ✅ Correct — always set requests and limits
containers:
  - name: my-service
    image: my-service:1.0
    resources:
      requests:
        memory: "mem"
        cpu: "cpu"
      limits:
        memory: "mem"
        cpu: "cpu"

2. Storing secrets in environment variables directly

# ❌ Wrong — secret visible in plain text
env:
  - name: DB_PASSWORD
    value: "mysecretpassword"

# ✅ Correct — use Kubernetes Secrets
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

Create the secret:

kubectl create secret generic db-credentials \
  --from-literal=password=mysecretpassword

3. No health checks

# ✅ Always add readiness and liveness probes
readinessProbe:
  httpGet:
    path: /actuator/health
    port: "port_number"
  initialDelaySeconds: 30
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /actuator/health
    port: "port_number"
  initialDelaySeconds: 60
  periodSeconds: 30

🚀 Getting Started Checklist

[ ] Install Docker Desktop
[ ] Write your first Dockerfile
[ ] Build and run a container locally
[ ] Write a docker-compose.yml for your full stack
[ ] Install Kind and create a local cluster
[ ] Write your first Deployment and Service YAML
[ ] Install Helm and create a chart
[ ] Deploy with Helm and test scaling

🔮 What's Next

Once you're comfortable with the basics:

Kubernetes Ingress — expose services externally with routing rules
Horizontal Pod Autoscaler — auto-scale based on CPU/memory
Kubernetes Operators — automate complex stateful applications
ArgoCD — GitOps continuous deployment for Kubernetes
Istio — service mesh for advanced traffic management

Container orchestration is the backbone of modern cloud-native engineering. Every major cloud provider — AWS (EKS), Azure (AKS), Google (GKE) is built around Kubernetes. Learning it now puts you ahead of the curve.

Thanks for reading! I'm Zaina, a Software Engineer based in Perth, Australia, working with Java microservices, Apache Kafka, Docker and Kubernetes at Ericsson. Connect with me on LinkedIn or check out my portfolio.

Found this useful? Drop a ❤️ and share it with a fellow engineer just getting started with containers!

Getting Started with Apache Kafka: What I Learned Building Event-Driven Microservices at Ericsson

zaina ahmed — Wed, 01 Apr 2026 05:44:46 +0000

When I first heard the word "Kafka" in a technical meeting at Ericsson, I nodded confidently while quietly Googling it under the table. A few months later, I was designing Avro schemas, building consumer groups, and debugging lag metrics in production.

This is everything I wish someone had told me when I started.

🎯 What Is Apache Kafka ?

Imagine a post office. Instead of letters, services send events things that happened, like "user logged in" or "notification dispatched". Instead of delivering directly to recipients, every event goes into a central post box (Kafka). Any service that cares about that event can pick it up whenever it's ready.

This is event-driven architecture. And Kafka is the most battle-tested way to build it.

The technical version:
Apache Kafka is a distributed event streaming platform that lets you:

Publish events from producer services
Store events reliably and durably
Subscribe to events from consumer services
Process streams of events in real time

At Ericsson, every customer notification: SMS, push, email, in-app is flown through a Kafka-based pipeline. Getting this right was critical. Getting it wrong meant missed messages at scale.

🏗️ Core Concepts You Must Understand

Topics

A topic is a named category for events. Think of it like a database table, but append-only.

notification-events     ← all notification events
user-activity-events    ← all user activity events
payment-events          ← all payment events

Producers

A producer is any service that writes events to a topic.

@Service
public class NotificationProducer {

    private final KafkaTemplate<String, NotificationEvent> kafkaTemplate;
    private static final String TOPIC = "notification-events";

    public NotificationProducer(KafkaTemplate<String, NotificationEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void sendNotification(NotificationEvent event) {
        kafkaTemplate.send(TOPIC, event.getUserId(), event);
        log.info("Notification event sent for userId: {}", event.getUserId());
    }
}

Consumers

A consumer is any service that reads events from a topic.

@Service
public class NotificationConsumer {

    private final NotificationProcessor processor;

    @KafkaListener(topics = "notification-events", groupId = "notification-service")
    public void consume(ConsumerRecord<String, NotificationEvent> record) {
        log.info("Received event for userId: {}", record.key());
        processor.process(record.value());
    }
}

Consumer Groups

Multiple consumers can form a group to share the work of processing events. Kafka automatically distributes partitions across group members, this is how you scale horizontally.

notification-events (3 partitions)
        |
Consumer Group: notification-service
        |
    ┌───┴───┐
Consumer1  Consumer2  Consumer3
(partition 0) (partition 1) (partition 2)

Partitions

Topics are split into partitions, this is what enables parallelism. Events with the same key always go to the same partition, preserving order.

// Events for the same userId always land on the same partition
kafkaTemplate.send(TOPIC, event.getUserId(), event);
//                         ↑ this is the partition key

📦 Avro Schemas — Why They Matter

Raw JSON Kafka messages are flexible but dangerous at scale. One typo in a field name can break every downstream consumer silently.

Avro schemas solve this by defining the exact structure of every message, enforced at the Schema Registry level before a message is even sent.

Define your schema (notification-event.avsc):

{
  "type": "record",
  "name": "NotificationEvent",
  "namespace": "com.ericsson.notifications",
  "fields": [
    {
      "name": "eventId",
      "type": "string",
      "doc": "Unique identifier for this event"
    },
    {
      "name": "userId",
      "type": "string",
      "doc": "Target user identifier"
    },
    {
      "name": "channel",
      "type": {
        "type": "enum",
        "name": "Channel",
        "symbols": ["EMAIL", "SMS", "PUSH", "IN_APP"]
      }
    },
    {
      "name": "message",
      "type": "string"
    },
    {
      "name": "timestamp",
      "type": "long",
      "logicalType": "timestamp-millis"
    },
    {
      "name": "priority",
      "type": ["null", "string"],
      "default": null,
      "doc": "Optional priority level — backward compatible field"
    }
  ]
}

⚡ Setting Up Kafka Locally

The fastest way to run Kafka locally for development:

docker-compose.yml:

version: '3.8'

Start everything:

docker-compose up -d

Verify Kafka is running:

docker ps
# You should see zookeeper, kafka, and schema-registry all running

🔍 Monitoring Kafka Lag

Consumer lag is the number of unprocessed messages sitting in a partition. High lag = your consumers are falling behind.

At Ericsson we monitored this constantly.

Output:

GROUP                TOPIC                PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG
notification-service notification-events  0          1250            1250            0
notification-service notification-events  1          980             985             5
notification-service notification-events  2          1100            1100            0

Partition 1 has a lag of 5 minor, but worth watching. If lag grows consistently, you need more consumer instances.

Add a second consumer instance by simply running another instance of your service, Kafka automatically rebalances partitions across the group.

🐛 Common Mistakes I Made (So You Don't Have To)

1. Not setting a partition key

// ❌ Wrong — no key, random partition assignment
kafkaTemplate.send(TOPIC, event);

// ✅ Correct — keyed by userId, preserves order per user
kafkaTemplate.send(TOPIC, event.getUserId(), event);

2. Creating ObjectMapper inside the consumer loop

// ❌ Wrong — new ObjectMapper on every message = slow
public void consume(String message) {
    ObjectMapper mapper = new ObjectMapper();
    Event event = mapper.readValue(message, Event.class);
}

// ✅ Correct — inject as Spring Bean
@Autowired
private ObjectMapper mapper;

3. Not handling deserialization errors

// ✅ Always configure an error handler
@Bean
public DefaultErrorHandler errorHandler() {
    return new DefaultErrorHandler(
        new DeadLetterPublishingRecoverer(kafkaTemplate),
        new FixedBackOff(1000L, 3)
    );
}

4. Forgetting idempotency

Kafka guarantees at least once delivery, your consumer may receive the same message twice. Always make processing idempotent:

public void process(NotificationEvent event) {
    // Check if already processed before doing work
    if (processedEventRepository.exists(event.getEventId())) {
        log.warn("Duplicate event ignored: {}", event.getEventId());
        return;
    }
    // Process and mark as done
    notificationService.send(event);
    processedEventRepository.save(event.getEventId());
}

📊 What I Learned in Production

After months of running Kafka in production at Ericsson:

Lesson	Detail
Partition key matters	Always key by the entity that needs ordering (userId, orderId)
Monitor lag daily	Lag growth is an early warning sign
Dead letter queues	Always have a DLQ for failed messages
Schema evolution	Add fields as nullable with defaults — never remove fields
Consumer group naming	Use descriptive group IDs — `notification-service` not `group1`
Replication factor	Always 3 in production for fault tolerance

🚀 Getting Started Checklist

If you're setting up Kafka for the first time:

[ ] Run Kafka locally with Docker Compose (see above)
[ ] Create your first topic
[ ] Write a simple producer in Spring Boot
[ ] Write a simple consumer with @KafkaListener
[ ] Define an Avro schema for your messages
[ ] Add error handling and a dead letter queue
[ ] Monitor consumer lag
[ ] Test with multiple consumer instances

🔮 What's Next

Kafka is one of those technologies where the basics are approachable but the depth is enormous. Once you're comfortable with the fundamentals, explore:

Kafka Streams — real-time stream processing
KSQL — SQL-like queries over Kafka streams
Exactly-once semantics — guaranteeing no duplicates
Kafka Connect — integrating Kafka with databases and external systems

The investment in learning Kafka properly pays dividends across your entire engineering career. Event-driven architecture is how modern distributed systems are built and Kafka is at the center of it.

Thanks for reading! I'm Zaina, a Software Engineer based in Perth, Australia, working with Java microservices, Apache Kafka, and cloud-native technologies at Ericsson. Connect with me on LinkedIn or check out my portfolio.

Found this useful? Drop a ❤️ and share it with a fellow engineer who's just getting started with Kafka!

Prompt Engineering at Workplace: How I Used Amazon Q Developer to Boost Team Productivity by 30%

zaina ahmed — Wed, 01 Apr 2026 05:25:52 +0000

If someone had told me a year ago that learning how to talk to an AI would become one of the most valuable skills in my engineering career, I probably would have laughed. But here I am. A certified Prompt Engineer at Ericsson, having driven a 30% improvement in team developer efficiency simply by integrating AI-assisted tooling into our daily workflows.

This is the story of how it happened, what I learned, and how you can apply it too.

A Little Background

I'm Zaina, a Software Engineer at Ericsson, one of the world's largest telecommunications technology companies. My day-to-day work involves building Java microservices, working with Apache Kafka event-driven systems, and maintaining CI/CD pipelines at enterprise scale.

Like most engineers, I was skeptical when AI coding tools started appearing. "It'll write buggy code." "You still have to review everything." "It's just autocomplete on steroids."

All of that is partially true. But I was missing the bigger picture.

🤖 What Is Amazon Q Developer?

Amazon Q Developer is AWS's AI-powered coding assistant, think of it as an engineer who:

Writes boilerplate code on demand
Explains complex codebases in plain English
Generates documentation automatically
Suggests fixes for bugs and code smells
Answers questions about AWS services instantly

It's similar to GitHub Copilot but with deeper AWS and enterprise integration which made it a natural fit for Ericsson's infrastructure.

💡 What Is Prompt Engineering really?

Most people think prompt engineering means typing clever questions into ChatGPT. In a professional engineering context, it's much more structured than that.

Prompt engineering is the discipline of crafting precise, contextual instructions that consistently produce accurate, useful AI outputs.

Think of it like writing a function specification. A vague spec gives you vague code. A precise spec gives you exactly what you need.

Bad prompt:

Write documentation for this function

Good prompt:

Write technical documentation for the following Java Spring Boot function. 
Format it as a Javadoc comment. Include: purpose, parameters, return value, 
exceptions thrown, and one usage example. Keep it under 150 words.

public NotificationResponse sendNotification(String userId, String message, NotificationType type) {
    validateInput(userId, message);
    Notification notification = notificationBuilder.build(userId, message, type);
    return notificationService.dispatch(notification);
}

The difference in output quality is dramatic.

🔧 How I Applied It at Ericsson

1. Documentation Generation

Our team had a backlog of undocumented internal APIs, a classic engineering problem. Manually writing Javadoc for 50+ methods would have taken days.

Using Amazon Q Developer with a structured prompt template, I reduced that to hours. The key was creating a reusable prompt template that the whole team could use:

Prompt I used:

You are a senior Java engineer writing internal API documentation.
Given the following Spring Boot method, generate a Javadoc comment that includes:
- One sentence summary
- @param descriptions for each parameter
- @return description
- @throws for any exceptions
- Keep professional tone, under 100 words

public ServiceResponse registerPodConnection(
    String podId, 
    String targetServiceId, 
    ConnectionConfig config) throws PodConnectionException {

    if (!podRegistry.exists(podId)) {
        throw new PodConnectionException("Pod not found: " + podId);
    }
    ConnectionResult result = connectionManager.establish(podId, targetServiceId, config);
    return ServiceResponse.success(result);
}

AI Output:

/**
 * Registers a new connection between a pod and a target service using the provided configuration.
 *
 * @param podId           the unique identifier of the source pod
 * @param targetServiceId the identifier of the service to connect to
 * @param config          the connection configuration including timeout and retry settings
 * @return a {@link ServiceResponse} containing the result of the connection attempt
 * @throws PodConnectionException if the specified pod does not exist in the registry
 *
 * Example usage:
 * ServiceResponse response = registerPodConnection("pod-001", "kafka-service", defaultConfig);
 */

Result: Documentation that previously took 3 hours took 25 minutes.

2. Test Case Generation

Writing unit tests is important but time-consuming. I used Amazon Q Developer to generate JUnit test skeletons:

Prompt I used:

Generate JUnit 5 test cases for the following Java method.
Include:
- Happy path test
- Null input edge case
- Boundary value test
- Use Mockito for dependencies
- Follow AAA pattern (Arrange, Act, Assert)
- Add descriptive test method names

public KafkaMessage buildNotificationEvent(String userId, String payload, EventType eventType) {
    if (userId == null || payload == null) {
        throw new IllegalArgumentException("userId and payload must not be null");
    }
    return KafkaMessage.builder()
        .userId(userId)
        .payload(payload)
        .eventType(eventType)
        .timestamp(Instant.now())
        .build();
}

AI Output:

@ExtendWith(MockitoExtension.class)
class NotificationEventBuilderTest {

    @InjectMocks
    private NotificationEventBuilder eventBuilder;

    @Test
    @DisplayName("Should build Kafka message successfully with valid inputs")
    void shouldBuildKafkaMessageSuccessfully() {
        // Arrange
        String userId = "user-123";
        String payload = "{\"message\": \"Hello\"}";
        EventType eventType = EventType.PUSH;

        // Act
        KafkaMessage result = eventBuilder.buildNotificationEvent(userId, payload, eventType);

        // Assert
        assertNotNull(result);
        assertEquals(userId, result.getUserId());
        assertEquals(payload, result.getPayload());
        assertEquals(eventType, result.getEventType());
        assertNotNull(result.getTimestamp());
    }

    @Test
    @DisplayName("Should throw IllegalArgumentException when userId is null")
    void shouldThrowExceptionWhenUserIdIsNull() {
        // Arrange
        String userId = null;
        String payload = "{\"message\": \"Hello\"}";

        // Act & Assert
        assertThrows(IllegalArgumentException.class, () ->
            eventBuilder.buildNotificationEvent(userId, payload, EventType.PUSH)
        );
    }

    @Test
    @DisplayName("Should throw IllegalArgumentException when payload is null")
    void shouldThrowExceptionWhenPayloadIsNull() {
        // Arrange
        String userId = "user-123";
        String payload = null;

        // Act & Assert
        assertThrows(IllegalArgumentException.class, () ->
            eventBuilder.buildNotificationEvent(userId, payload, EventType.PUSH)
        );
    }

    @Test
    @DisplayName("Should throw IllegalArgumentException when payload is empty string")
    void shouldHandleEmptyPayloadAsEdgeCase() {
        // Arrange
        String userId = "user-123";
        String payload = "";

        // Act
        KafkaMessage result = eventBuilder.buildNotificationEvent(userId, payload, EventType.SMS);

        // Assert
        assertNotNull(result);
        assertEquals("", result.getPayload());
    }
}

The generated tests still needed review and refinement but having a solid skeleton cut test writing time by roughly half.

3. Code Review Assistance

Before submitting code for peer review, I started running my changes through Amazon Q Developer:

Prompt I used:

Review the following Java code for:
1. Potential bugs or logic errors
2. Performance issues
3. Security vulnerabilities
4. Violations of SOLID principles
5. Missing error handling

Provide specific line-by-line feedback where relevant.

@Service
public class KafkaConsumerService {

    private final NotificationRepository repository;

    public void processMessage(ConsumerRecord<String, String> record) {
        String payload = record.value();
        ObjectMapper mapper = new ObjectMapper();
        Notification notification = mapper.readValue(payload, Notification.class);
        repository.save(notification);
        System.out.println("Saved: " + notification.getId());
    }
}

AI Output:

Code Review Feedback:

1. LINE 9 — PERFORMANCE: ObjectMapper is being instantiated on every method call.
   This is expensive. Inject it as a Spring Bean instead.
   Fix: @Autowired ObjectMapper mapper;

2. LINE 10 — ERROR HANDLING: mapper.readValue() throws JsonProcessingException 
   but it is not handled. Add try-catch or declare in method signature.

3. LINE 12 — LOGGING: System.out.println should be replaced with SLF4J logger.
   Fix: private static final Logger log = LoggerFactory.getLogger(KafkaConsumerService.class);

4. LINE 7 — SOLID: processMessage() is doing too much (parsing + saving + logging).
   Consider separating parsing logic into a dedicated MessageParser class.

5. MISSING: No null check on record.value() before parsing.
   If payload is null, mapper.readValue() will throw NullPointerException.

This caught several issues before they reached my colleagues, improving code quality and reducing review back-and-forth.

4. Knowledge Base Articles

Prompt I used:

Write an internal engineering guide explaining Avro Schema Evolution 
for a team of Java backend engineers. Assume they are familiar with 
Spring Boot and Kubernetes but new to Avro schemas. Include:
- Overview (2 paragraphs)
- Step by step setup
- Common pitfalls
- Example configuration
Keep it under 500 words, technical but approachable.

AI Output:

# Avro Schema Evolution — Internal Engineering Guide

## **Overview**
Apache Avro is a binary serialisation format used with Apache Kafka to define 
the structure of messages exchanged between services. Unlike JSON, Avro schemas 
are strongly typed and versioned, meaning changes to the schema must be managed 
carefully to avoid breaking existing consumers.

Schema evolution allows you to update your Avro schema over time — adding fields, 
removing fields, or changing defaults without breaking services that depend on 
older versions. The Schema Registry (Confluent) acts as the central store for all 
schema versions and enforces compatibility rules.

## **Step-by-Step Setup**

1. Add dependency to pom.xml:
<dependency>
    <groupId>io.confluent</groupId>
    <artifactId>kafka-avro-serializer</artifactId>
    <version>7.4.0</version>
</dependency>

2. Define your initial schema (notification.avsc):
{
  "type": "record",
  "name": "Notification",
  "namespace": "com.ericsson.notifications",
  "fields": [
    {"name": "userId", "type": "string"},
    {"name": "message", "type": "string"},
    {"name": "timestamp", "type": "long"}
  ]
}

3. Add new optional field safely (backward compatible):
{"name": "priority", "type": ["null", "string"], "default": null}

## **Common Pitfalls**
- Never remove a required field — use ["null", "type"] union with default instead
- Never rename a field — add a new field and deprecate the old one
- Always set default values for new fields to maintain backward compatibility

## **Compatibility Rules**
- BACKWARD: New schema can read old data (safest, recommended)
- FORWARD: Old schema can read new data
- FULL: Both directions supported

What used to take an afternoon became a 30-minute task.

📊 The Results

After three months of consistent use and sharing prompt templates with the team:

Metric	Before	After
Documentation time	~3 hrs	~25 mins
Test skeleton writing	~2 hrs	~45 mins
Knowledge base articles	~4 hrs	~1 hr
Developer efficiency (quarterly review)	Baseline	+30% improvement

The 30% figure came from our quarterly engineering efficiency review.
A real, measured outcome, not an estimate.

🎓 Getting Certified

Ericsson offered a formal Prompt Engineering for Professionals (BCSS BOS) certification, which I completed in November 2024. The certification covered:

Fundamentals of large language models
Prompt design patterns
Chain-of-thought prompting
Few-shot and zero-shot techniques
Responsible AI usage in professional environments

If your company offers AI training, take it! If not, there are excellent free resources on platforms like Coursera, DeepLearning.AI, and AWS Skill Builder.

My Top 5 Prompt Engineering Tips for Engineers

1. Be specific about format
Always tell the AI exactly what format you want — bullet points, table, Javadoc, code block.

2. Give it a role
Start with "You are a senior Java engineer..." — this sets the context and dramatically improves output quality.

3. Set constraints
"Under 100 words", "Java 17 only", "no more than 3 bullet points" — constraints prevent verbose responses.

4. Use examples
Show the AI one example of what good output looks like before asking it to generate more.

5. Always review
AI output is a first draft, not a final answer. Treat it like code from a junior developer — useful, but needs your expert eye.

🔮 What's Next

AI-assisted development is not a trend, it's the new baseline. The engineers who learn to use these tools effectively will move faster, produce higher quality work, and have more time for the complex problems that actually require human creativity.

I'm now exploring how prompt engineering applies to Kafka event schema design, automated test generation for distributed systems, and CI/CD pipeline optimisation.

If you're an engineer who hasn't yet experimented with AI-assisted tools, start today. The learning curve is smaller than you think, and the productivity gains are very real.

Thanks for reading! I'm Zaina, a Software Engineer based in Perth, Australia, working with Java microservices, Apache Kafka, and cloud-native technologies. Connect with me on LinkedIn or check out my portfolio.

If this article helped you, drop a ❤️ and share it with a fellow engineer!