On Hiring: Difference between revisions

From Federal Burro of Information
Jump to navigationJump to search
No edit summary
No edit summary
 
Line 42: Line 42:


* [[Interview questions]]
* [[Interview questions]]
[[category:Corporate_Culture]]

Latest revision as of 17:01, 1 August 2023

Posted to Linkedin: https://www.linkedin.com/feed/update/urn:li:activity:6962815486673793024/

As an employer I've done lots of interviews over the years for systems folk aka DevOps, SRE, "Cloud engineer" ( groan ).

I see some trends:

1. Saying you know technology X neglecting the distinction between being a user of a technology and an administrator of a technology.

Kubernetes being the current best example; Sure you applied manifests, or installed helm charts.

But did you:

a. (destroy and re)build the cluster? b. update the cluster? c. monitor, maintain, fix, and scale the cluster? d. did you write the helm chart? e. Did you live with the decisions of your helm chart over months of releases?

2. Saying "I don't know".

This is a big thing. In an interview I need to hear you say "I don't know". This speaks to your character and your sense of self.

You might be a super-star, a 10X, but if you can't say "I don't know", then you can't communicate well. There is something you don't know.

You should be able to say "I don't know" and still think you are worthy of the job.

For your own sake you should say "I don't know" in the interview as well.

The last thing you want is to never say "I don't know" in the interview only to find that you could not say it in your day-to-day activities.

3. Not knowing your tools inside out.

At least the command line options. At least version issues. Don't _just_ do the tutorial. Read the manual. Do the training. Know your tools. You could go years in prod doing only "terraform apply" and squeak by. Don't do that. We can tell.

Be cautious of "Managed offerings". Practically they are invaluable and save you time and headache. But they mask the system from you, and can make it hard for you to understand what's going on when the requirements complicated or things start to break.

Also see: