Position: DevOps engineer
Category: DevOps
Experience: 6 years | English: upper

1. Saving private RabbitMQ, part 1: RabbitMQ cluster was unstable due default configuration - split-brain happened quite often and it was a real pain. I have configured pause minority feature and done some minor improvements to make RabbitMQ work as expected! 
2. Saving private RabbitMQ, part 2: developers faced with heartbeat problems as they used single threaded synchronous programming language (guess which one?). There are several solutions from application side, but all of them are not very sophisticated (like to fork child process to handle heartbeats, furthermore it is not  framework feature). Also, heartbeat could be disabled at all, but it is not what we wanted. I found the solution: we can use underling Linux network stack feature - tcp keapalives! It works like a charm! 
And RabbitMQ has become one of the most reliable service hosted in ECS. 
3.  Hand crufted ingress controller for ECS services: you have experience with nginx, but do not want to pay for nginx+ to get API and envoy was not so popular. Nginx + Consul + consul-template is your choice! Devops team is able to configure nginx using terraform - you write defined keys to consul and consul-template generates valid nginx configuration and reloads nginx.
4. And the latest Kubernetes news: I needed to run ECK (Elastic Cloud on Kubernetes), but there was not k8s cluster running. And standard way to create k8s cluster (EKS in current case) did not exist either. I decided to use terraform and community module. But it was only beginning: clean cluster is useless, so, I had to setup all necessary controllers/operators like ebs-csi-driver, lb-controller, external-dns etc. Finally, ECK is up and running and, yeap, we need a monitoring system. I chose prometheus, alertmanager, grafana stack and installed it using helm chart which includes prometheus operator. Essentially, ECK was a small part of the puzzle.

Almost forgot about two AWS certificates:
- Solutions architect associate
- Database specialty
Probably, I will not write every technology which I am familiar with, better I will try to tell about my working experience evolution for the last 5 years.

1. I started working as linux system administrator. It was pre cloud era for me and my toolkit was  bash, grep, awk, rsync, ssh, iptables (netfilter), kvm, lvm etc. Remember those discussions what distributive is better - Ubuntu or CentOS (Gentoo beats them all). A bit later I have been familiar with cluster concepts for databases(Mysql, Postgresql, redis), distributed FS (glusterfs), load balancers (haproxy, ipvs), web servers (nginx, apache2).
2. The next step was AWS and terraform - creating different cloud resources using IaC approach. At the same time I read a few books about python and it has become my another interest. 
3. Changed position to full time DevOps engineer. I have been heavily using my python knowledge to create CI/CD scripts invoked by TeamCity, automate backups using AWS lambda, automate everything for what terraform is not the best choice.
At that time I have already faced docker and had some basic knowledge about container orchestration. 
4. Microservices, containers and ECS. Also have got experience with message queue solutions like Redis (simple queues) and RabbitMQ (message broker with different routing rules).
5. Kubernetes and cloud native: EKS, helm, operators/controllers, servicemesh. 

My goal is to be a good engineer with deep knowledge in OS, distributed system(including kubernetes),  programming. I do not want to be a yaml programmer only.
I prefer working in product companies since you are part of some society and share success and loses together. 
And it allows to avoid supporting several quite different projects at the same time. In my opinion, frequent context switching is not very efficient (I had such experience).