I came across this position while scrolling LinkedIn. I just grabbed a resume I had used for other job applications and applied, and I got the first round right away. I think it was a direct interview with a team member. One thing I want to say: the posting required 8+ years of experience with Docker, Kubernetes, or Slurm, but I only have a bit over 4 years of total work experience, about 5 years of Docker, and no hands-on K8s experience. I applied anyway, and they still sent me an interview, so don't let those year counts hold you back. A few other positions I applied to said they wanted 5+ years, and I only have a little over 4, and I kept applying to those too. So treat the requirements as a rough reference only. You don't need to meet every minimum requirement to apply.
The first round was 45 minutes, with about 20 minutes on a simple coding problem and the rest of the time on a simple resume deep dive. From what I'd read online, I expected to be asked how to parse logs, but in the actual interview the logs they gave were already structured data, already categorized, so I just had to read the keys and values. I thought it was very easy. It was mainly testing how you handle scenarios. First I wrote a basic version of the code, and then they asked what I would do if a record was duplicated. There are many ways to handle it, depending on the scenario.
For an operations scenario, you might only need to look at the last healthcheck pass, meaning the server's uptime, and the earlier records might not matter. But if there is a service level agreement, then the earlier failed records might need to be counted as well. Then they asked: what if we come across a record that doesn't follow the predefined structure, how do we handle it? That is also a problem you would really run into. With some basic knowledge, you should be able to answer these questions.
The resume Q&A was pretty standard. This team is really more of a QA team, basically doing QA for GPUs and GPU software. What I actually want is to transfer from here into a team that does real SDE work. That path might be easier, but it might not be, because staying in QA for a long time is very bad for switching careers. Think it over for yourself.
Discussion
Loading comments…