Headquartered in Hamburg, quantilope created an AI-based tool for automating market research projects with access to advanced analytic tools, live reporting, and interactive visualisations. They recently opened an office in New York and have over 100 people on board in total. We had a chat with one of their employees, Khaled Elkhawaga, who is a DevOps Engineer. Here's his story of moving to Hamburg for the role.
How did your career start? Why did you move to Hamburg?
I was always passionate about technology, so pursuing a degree in computer engineering seemed natural to me. After I started university, I got into the world of programming first through university. Then, a teaching assistant suggested that I participate in some programming contests, so I got more into it.
I started as a Frontend Developer. In the company I joined, many processes were still manual. I decided to act on it, suggesting to the co-founder of the company to promote me to the DevOps role. I succeed!
Later on, I moved to Hamburg to join quantilope, a great startup that changed the market research industry. The team and the company's culture made a difference. Judging by the co-founder's character, I felt optimistic about working with quantilope and was excited about where the company was headed.
What's DevOps' role? What is your secret of being good at it?
A DevOps Engineer implements processes that empower other developers to become more efficient and deliver a better-quality outcome. They also give a better understanding of the entire application's lifecycle, from design all the way to production. A person with this role also implements automated processes that allow applications to scale reliably and efficiently.
Being a great DevOps implies having a huge learning mindset, and understanding that you are integrating different parts of the teams — you are the link in-between. The best thing is to improve continuously and keep learning.
What book has had the biggest impact on your career?
Site Reliability Engineering: How Google Runs Production Systems. It is the bible for DevOps, gathering case studies from the Google Engineering team. One interesting part was reading about error budgets in a section titled “Embracing Risk”. It goes like this: if you aim for 99.9% uptime for your application as an acceptable goal (of course factoring in cost, user impact, and so on), this means that you can have up to 8.76 hours of downtime per year. And while yes, you should exceed it in meeting your goal, you don't need to exceed it by too much. These hours are your budget, and you should use them. If that target is exceeded by a lot, you can think about releasing updates more frequently, for example. It's all about managing risk and embracing it, not avoiding errors entirely.
What would you suggest to someone seeking a new job? Any tips for relocation?
When you are willing to change your career, the first criteria is always the team. I put people first! I think that if the team is good, you are going to enjoy it no matter what. How motivated the team seems doesn't only allow me to feel how would it be to work with them, but also how good the management is.
For relocation, I'd say that you are never going to know how will it go unless you try — just go for it! Before moving to Hamburg, I contacted a few friends who moved here before me to ask a few questions about the city. Also, be prepared for a few weeks of dealing with German paperwork.
Any pieces of advice for the Hiring Managers/Recruiters?
- Being straight forward and human;
- A great Hiring Manager/Recruiter shouldn't judge on a number of years' experience. I have seen people with half a year of experience who are amazing at their jobs. And same with people who worked longer, of course;
- If you want to improve the candidate experience, provide the feedback fast and give enough of it to allow the candidate to improve. A recruiter shouldn't send generic messages.