A Break In The Clouds
Status Report, Two Weeks In:
Had a great technical interview with a promising opportunity yesterday! The role would be on a small team of other DevOps folks and I wouldn't be the most junior member on the team, both different dynamics than my last stints as a junior member of an SRE team and then an embedded SRE. I went into the interview with considerable stress weighing on me, but I answered most everything well based on feedback during and at the end of the interview. Hopefully, this leads to an offer -- there's one more interview, more social than technical, with the rest of the team to go.
Post-Interview Thoughts:
Some notes to jot down after the interview, from questions I struggled with or had to pass on to general interviewing considerations.
- Going too high level: At one point I was asked about scheduling data-heavy batch processes, or some other particular use case, onto an existing k8s cluster. Knowing they were using EKS, I launched into talking about using spot instances and managed node groups for batch processes that could withstand disruption or failure to save costs, but the question was more nuts and bolts, more about taints, affinities, etc. -- typical kubernetes scheduling. It's a pitfall I can trip up on that I think can position me worse than simply stumbling on a question, because I look like I'm grasping at straws, when really the higher level answer is what catches my interest and train of thought.
- "If you're not in this to be enthusiastic about it, as a nerd, what are you doing, as a professional nerd?": I asked something like this at one point, I think out of self-consciousness re: how excited and in-depth I can get on technical subjects. If I really am to see this as a boon and not a peril, I need to embrace it properly instead of being a huge dork and also being self-effacing for being a huge dork.
- TCP vs. UDP and the networking black hole: Wasn't able to off the top of my head describe well the differences and use cases here. Networking overall was/is an admitted spot where I'm growing and can stumble on even basics sometimes. I'm not sure how to best learn here, networking is fascinating but constantly feels like a confusing rabbit hole when I engage deeply with it.
- Measure out your serving first: Which is to say, before presenting an answer, I need to take a moment to make sure I can cover the whole thing. I tend to think best and answer questions best, I like to think, by thinking aloud through my thought process. That's a recommended tactic, but it doesn't lead itself to brevity and if, well, if I'm talking about freeing up system resources while troubleshooting a slow system by killing zombie processes, it helps to mention How in fact I would do that, and to consider being explicit that I'd kill a given parent process, vs. launching into an answer without fully scoping it out.
- When in doubt, build: A conversation with someone new to tech about 'tutorial hell' later in the day reminded me that I'm not currently building much or much that I can talk about in an interview, let alone documenting it. I should change that up -- even if it's something simple like static site or Wordpress hosting, both of which I see myself needing in the coming days -- by doing and documenting a project along the way.
Either way, a hopeful development, and pursuing more opportunities while I see where that one goes. The only way forward is through, not a step back.