I was initially contacted by a recruiter on LinkedIn. My first interview was a half-hour with the recruiter, where I answered filter questions such as "order speed of access" for 3-4 types of memory/storage and "What does a Hadoop NameNode do?"
A couple of weeks later, I interviewed with someone in a managerial role via a phone interview. Half of this hour-long interview focused on systems questions, and the other half on coding.
The systems questions were at a level between SysAdmin and Senior SysAdmin, including some Hadoop questions regarding the NameNode and, I believe, some thread processing/interrupt-handling.
The coding interview involved picking a language and implementing a string processor to compress/decompress a series of letters in CollabEdit. The algorithm was basic but effective.
They are a Python/Java shop, as one might expect when developing Hadoop, but they also use both Puppet and Chef (Ruby).
A few weeks passed, and I assumed they had moved on, which was fine. They appear to be building out a cloud-based service to finally live up to the name "Cloud-era," rather than "Cloud-on-prem" as they are known. However, I don't think the joke landed, which was a shame you can't laugh at yourself.
They hired a brand-new manager for the team they are building, and this manager wanted to interview me for a half-hour. So, I had a second technical interview with the new manager, where I was asked about my experience with Continuous Integration and Continuous Deployment for most of the time.
There were a few technical questions at the end after I discussed my CI/CD experience:
From a systems standpoint, I answered that you could scale out another server from a high availability perspective, as balancing should allow service to be split (e.g., take a capacity server out of the pool).
Alternatively, you could add a new file system as a mountpoint or consolidate small files into larger files, as is common with many Hadoop issues.
"Can inodes be increased, or are they fixed?"
I answered they can be increased (given file systems like XFS), but I was told that "they're fixed in ext2/ext3 at creation but could be expanded in ext4."
It was clear the manager hadn't touched XFS, for instance, or knew that even ext4 has limits, even with 'extents'.
I answered a firewall at the edge of the network or on your server has a blocking rule, which he seemed happy with.
"You're getting the SYN packet after adding the rule, and SYNACK packets are being sent back but are being dropped at the firewall on the WAN for one of a few servers. What is a possible cause?"
I said 'asynchronous routing' is the most likely cause because traffic, as mentioned, is stateful on modern firewalls. This means that, depending on the server's location, it may be routed out a separate firewall. This answer also pleased him.
The interview ended after I asked some questions.
They have "no meeting" Wednesdays. They weren't sure about customer growth. They are planning a 4-5 person SRE team (meaning one week a month on-call) and weren't aware of competitors in the space for the service they are building, which is concerning.
Instituting a "no meeting" Wednesday policy is an indication that people talk more than they do in the organization, which was enough for me.
The manager seemed overwhelmed by meetings already, and I sensed he was a little annoyed that I would be considered for this role, even after passing one interview and fitting the job requirements. Were you looking for a release engineer?
In total, two months passed for two technical interviews for one position.
For my own records, after thanking them for their time, I asked the recruiter the day I received the notice "why" they were moving on from me, but received no response.
Only about 5% of the recruiter "prep guide" from the initial contact was helpful (thread processing).
By and large, recruiters in the tech industry, at least, remain abysmal: scheduling, hospitality (after the process is over), and consistency in organization.
Eventually, machine learning will have replaced them and improved scheduling/interactions for managers, interviewers, and candidates.
What is an inode?
The following metrics were computed from 1 interview experience for the Cloudera Site Reliability Engineer role in Palo Alto, California.
Cloudera's interview process for their Site Reliability Engineer roles in Palo Alto, California is extremely selective, failing the vast majority of engineers.
Candidates reported having very negative feelings for Cloudera's Site Reliability Engineer interview process in Palo Alto, California.