It was a hell of a ride. I applied through an employee referral and received an answer after 1-2 days. The whole process took about two weeks, but only because I did not have time to attend interviews during the first week.
I marked the interview as easy because, for me, it was. It required broad knowledge in many areas and deep knowledge in a few. Some parts were a weakness for me, but the interviewers were understanding. They recognized that I had an overview of the area, even if I lacked deep experience or knowledge in those specific parts.
The first interview was a recruiter screening, a simple walkthrough of my resume, the projects I worked on, and why I wanted to apply. The interesting part was that it was the first hiring round for a second shift in the Budapest office, and I had to explain why I wanted to apply for this position, as it was clearly not ideal for my social life if I worked until 11 PM every weekday. However, as I am pretty much a night owl, I prefer to be able to stay up until 3 or 4 AM, and if I don't have to get up until noon, that's perfect for me. Of course, as I am not a native English speaker, there was a small English communication skills check as well. The rest of the interviews went in English, except for one with a local manager.
The next round was with the regional manager via a call. It was mostly about personality and resume details, but at the end, we moved on to customer handling scenarios where I needed to prove that I could communicate even difficult things or handle harsh, escalated situations.
The third round was with one of the local managers, who is primarily a technical person and started as a CEO. He was also coming from the Java development field, similar to me. This was the best interview I have ever had. We discussed system administration-related topics, Linux shell commands, and shell scripting, which were not my strongest points. However, it wasn't about hands-on knowledge but my perspective on the problems. The best part was when I told him I had never done something before, but if given access to Google, I was sure I could find the solution. He then handed over his laptop with a clear browser and said, "Then find it out and show me how you do it." I was able to do it. After these parts, we talked about the projects and problems I had faced. The main aim was to understand how I approach a problem, what things I try to check, what I ask for, and how I find a solution. It went well, and at the end, I re-solved an already solved case from scratch.
The fourth round was a purely technical interview via call with one of the COEs located in London. We deep-dived into Java internals (Java Frameworks, concepts, memory management, GC, references, threads, locking, everything) as that was my strongest skill. Then we touched on shell scripting and file system internals, processor and hardware specifics, networking, and database concepts (that was my weakest, as my last database-related project was eight years before the interview). I felt the main aim was to see what I knew and what I didn't. If I said I didn't know something, we moved on.
After this, I was accepted. We agreed that I would receive my offer the following year, as the last interview round was on December 23rd.
What would you do if a customer calls you loudly and angrily because they do not have an answer for their problem, but they really need it ASAP?
What is the most important thing to do with a customer if you have a serious issue at hand, and the problem is complex and involves many people and time to solve?
How to create a thread/heap dump, how to find a file, what nsswitch.conf configures, how to check system performance, what tools you can name that can be used for network troubleshooting, and such system and network-related questions.
Java internals from the very heart of the collections framework to threads, executors, locks, references, GC, memory management, generations, GC tuning, String internals, and some J2EE concepts as well.
Stored procedures, views, materialized views, query planning, transaction isolation, consistency models, and database internals.
Filesystem internals, what is an inode, how metadata is stored, how certain operations are done at the low-level filesystem implementation.
What would you do if you see the following log and problem description?
The following metrics were computed from 5 interview experiences for the Cloudera Customer Operations Engineer role in Budapest, Hungary.
Cloudera's interview process for their Customer Operations Engineer roles in Budapest, Hungary is incredibly easy as the vast majority of engineers get an offer after going through it.
Candidates reported having very good feelings for Cloudera's Customer Operations Engineer interview process in Budapest, Hungary.