I wasn't initially looking when I was cold-approached by their in-house recruiter for a role on the Confluent Cloud team (Kafka as a Service on top of Kubernetes). I was enthusiastic in the beginning since I had used their products in the past and enjoyed reading their blogs and books. The company hires top talent in marketing and PM; they seem very open and are constantly pushing the envelope of building out their data-centric platform. The idea of using Kafka as a central nervous system in large-scale systems resonates with many.

In hindsight, I wish I had paid more attention to some feedback presented here on GD and superficial pontifications by certain team members on Medium and LinkedIn. Anyone who states they were among “300+ applicants for a job and won” deserves an independent opinion on their sanity. Do your research and make sure you are well aware of these online personas.

The interview process consists of:

• A phone screen with the recruiter
• A phone screen with the hiring manager
• A take-home code assignment
• A take-home design assignment to present in person
• An in-person/Zoom meeting in Palo Alto, CA, and possibly other stages.

I would recommend against spending much time on the take-home assignments. Instead, ask for a technical Zoom chat before you fly out, if your time is important to you. I will post the take-home materials on GitHub to save you some time.

The office is nice, with a subtle millennial vibe (rooms called IMHO, TLDR, IRL, etc.). Okay.

I met most of the team in person at the office or over Zoom. On the surface, everyone seemed genuinely nice, polite, and technically capable based on the questions asked. Some folks appear to be roughly 8-10 years younger than I am, so there's likely not a lot of relatable experience. Most have a track record of working for successful web companies in the valley, which is great for what they are doing. Nobody seems to have had to experience the need to change direction in their career quite yet. Or maybe they made better career choices; that happens.

In-person/Zoom meetings were well-organized. A person from a different team took me to lunch, and it was a great experience. It was good to get a different perspective from someone who had been with the company from the very start; the conversation was super insightful.

I don't think I aced the interview, but I don't think I flunked it either. It was hard to tell since there wasn't an immediate reaction. If I had noticed a negative reaction, I would have tried to correct it. The recruiter's verdict did not get into any detail, and that wiped out the entire experience.

In terms of questions to expect, they don't seem to be super hardcore into system development, so no nasty concurrency stuff (like RW locks, condvars, Java thread pools, or tricks with goroutines, or god forbid RxJava). There were also no brain teasers, no distributed systems concepts like replication or consensus. No deep Kubernetes or AWS probing, and no streaming problems, which surprised me. It was pretty much all around building vanilla web APIs and a basic LRU problem.

Over a week passed with no feedback – dead silence. I sent a friendly ping and received an opaque response that ended in, “unfortunately, we are looking for someone to join the team who has more coding experience, from a design, planning and implementing perspective.” (This spelling is verbatim).

To translate this into hipster speak: “Bro, do you even code?”

Since this blanket statement lacks any specificity, my suggestion: Don't do it. It makes you sound quite dumb, given the company's caliber. It also comes across as pretty offensive. I just happen to have a good sense of humor.

A couple of conclusions:

• The recruiter is pretty careless and doesn't really know how to handle rejections. Good rejections are an art; they should make the applicant feel good and willing to come back. Nothing of that here. Not keeping it open-ended means not caring for building a network. Indeed, why network with a complete failure on a different coast?
• The process is not optimal for an early pass. Maybe come up with a different way to filter based on take-home assignments? It's pretty much a waste of everyone's time otherwise.
• You need to be a cool kid / tech bro ninja rockstar to qualify. If you don't exude "I am living on GitHub 24/7," maybe don't apply? Differences in experiences, views, career paths, and curiosity don't seem to matter here. Given this attitude, maybe hire friends of rockstars through referrals and do no outside recruiting?

Lastly, the point about the "300+ applicants winner" blogger hero. I'm relieved I don't have to figure that out and don't need to look further into team dynamics. It would be bad if there's even a small chance that these concerns are true. I'm not looking forward to any toxicity; I've had enough in the past.

Bottom line: do your research, proceed with caution, cap your time, and finally, it's OK to be an OK developer.

But remember: "You miss 100% of shots you don’t take." So good luck!

Take-home coding assignment: Build a Feed Reader API.

Take-home design assignment: Design Confluent's Kafka as a Service offering.

In-person assignment: Design a URL shortening service.

In-person assignment: Design an LRU cache in Go.