4 ms·

Kubernetes Devops guy checking in - this is the way! Also think about it from the company side: Would you rather hire someone that solves your "exact" problem

Kubernetes Devops guy checking in - this is the way! Also think about it from the company side: Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you?

drewcoo 4y ago
> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you? Well . . . people always assume they have the answers, so they've designed an exact position to do what they think they need. But if they need it and can't fulfill the need themselves, they probably don't know what they need. The company, composed of vain people, is more likely to hire someone that solves their "exact" not-really-problem.
- jhoelzel 4y ago
  In my opinion it's okay to not be able to pinpoint the exact problem, thats what I tried to imply by using the quotations. This is why I position myself as Consultant and Engineer, because you will know you have a problem with your cluster, and I should know how to solve it. When you are at the point, where your question is: "I need someone to fix my internal ingress-controller because traefik binds all services to the public one", you might simply need to open an issue with the developers of traefik. Yet if your problem is: "we would like to completly separate internal traffic from external traffic inside our own datacenter", you are looking for the kubernetes devops guy with the neccesairy experience.
tinco 4y ago
I'd rather hire someone who is effective and passionate about solving problems in a particular space. If I hire a full stack web developer, and then they burn out because I had only frontend tickets for them for half a year, that's not so nice. I don't mind rebranding your LinkedIn to make it look like you're the Kubernetes DevOps guy, as long as that means you're totally fine with working the DevOps for my Kubernetes clusters for the foreseeable future. In an ideal world we could shove around generalist developers to whatever is necessary at the moment, but the reality is each developer is a human with hopes and dreams and ambitions and not every role will fit those.
- b112 4y ago
  As a generalist, you've not only got my goat, you just took it to town and got it drunk. This sort of over reasoning is part of what bugs me about this industry. Many devs change jobs at the drop of a hat, turnover is already high. Yet here you are, worried about job retention, trying to second guess what a dev knows about their own happiness. I know you mean well, both for the org, and the person, but what makes you think you know, better than the dev, what will stress them out or not? You aren't them, so just ask, and as long as it is clear they have thought of it, and want to move ahead, you should 100% drop the matter. Frankly (as if I could be more frank, heh), likely there will be something entirely unrelated which will bug the dev. And all your concerns will be for naught. Except, of course, you are throwing people's resumes in the trash bin, thus reducing your talent pool, due to unfounded concerns.
  - tinco 4y ago
    Over reasoning? Because I ask a developer what they want to work on during an interview? Guess what, turnover is high when your developers are unhappy with the work they're doing. I've had developers do work that they didn't like to do, and they quit, so now I make sure they're gonna be happy where I want them. I'm not second guessing anything, in fact my comment says the exact opposite. If a developer reworks their LinkedIn to highlight some expertise they're interested in working on, then I fully trust them on that and will gladly hire them. I'm not sure where your whole angle of not trusting developers to know their own happiness comes from. But let me be clear, if you're a generalist with relevant experience I will definitely ask you to come over for an interview. I'm not throwing valuable resumes in the trash. But during the interview I will be frank about what the job entails, and I'll gauge your response to figure out if you'll be content. Whether I'm effective or not I don't know, but I'm going to have to at least try to get the right person at the right position. edit: BTW I'm not just saying this as a CTO at a small startup, I'm also saying this as a generalist with highly valuable frontend skills and I pray to god I don't have to get into another frontend job (either directly, or by being lured into it after applying as a generalist).
    - b112 4y ago
rjzzleep 4y ago
I'm a generalist and I've had a bunch of DevOps jobs where I had to come in to fix what the complete mess the kubernetes devops specialist left behind. I think the question is more who a generalist markets to. Some people have multiple resume's depending on what they apply for, they come in through one angle and then build some trust and take over more. Or it's a startup that needs help, but doesn't really know what they need help with. The fundamental mistake is that people think that just because someone is specialized on a topic he's also good at it.
- jhoelzel 4y ago
  Absolutely true, but those are two different things. I -AM- a generalist and it's also a requirment for being actually any good in devops, but I position myself as Freelance Sr. Engineer with Kubernetes / DevOps / Golang Focus, because thats what I like doing and also what I am good at. There is a whole longtail of skills that are required to do any of this, also quite a few that are not even tech related, like proper communication or empathy. But yeah, if you require assitance, I am definitly the kubernetes-dude that you can call and it should be as simple as that.
- trashtester 4y ago
  I happen to think that "DevOps" is one of those fields that really require some kind of generalist to do well, from the hardware (and virtual hardware) level and a fairly deep understanding of networking to how to build and optimize the kinds of apps and services that will run in the infra. Many get the title "DevOps" who are basically Ops people with a new toolkit. One of the problems with the DevOps stack, though, as working in the infra-as-code needs a dev mentality to be done right. Many traditional ops people will "program" the infra-as-code using pretty bad quality code. (often using way too much cut&paste for stuff that could be generalized.) On the other hand, when devs switch to "devops" they often fail to have the attention to detail and sense of responsibility found with many traditional ops people. So finding good candidates for DevOps roles is really hard, and often those positions are staffed with people who are not really suited for the paradigm.
HWR_14 4y ago
> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? I tend to contract to the guy who can solve my exact problem. Because if the problem can be solved I don't want to pay for headcount permanently. I tend to hire long-term the guy who can solve multiple problems, but less speedily. Which, of course, is different if you mean "hire someone who solves a class of recurring problems I have with a specialized skillset" from "solve the exact problem"

drewcoo 4y ago

> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you? Well . . . people always assume they have the answers, so they've designed an exact position to do what they think they need. But if they need it and can't fulfill the need themselves, they probably don't know what they need. The company, composed of vain people, is more likely to hire someone that solves their "exact" not-really-problem.

jhoelzel 4y ago
In my opinion it's okay to not be able to pinpoint the exact problem, thats what I tried to imply by using the quotations. This is why I position myself as Consultant and Engineer, because you will know you have a problem with your cluster, and I should know how to solve it. When you are at the point, where your question is: "I need someone to fix my internal ingress-controller because traefik binds all services to the public one", you might simply need to open an issue with the developers of traefik. Yet if your problem is: "we would like to completly separate internal traffic from external traffic inside our own datacenter", you are looking for the kubernetes devops guy with the neccesairy experience.

tinco 4y ago

I'd rather hire someone who is effective and passionate about solving problems in a particular space. If I hire a full stack web developer, and then they burn out because I had only frontend tickets for them for half a year, that's not so nice. I don't mind rebranding your LinkedIn to make it look like you're the Kubernetes DevOps guy, as long as that means you're totally fine with working the DevOps for my Kubernetes clusters for the foreseeable future. In an ideal world we could shove around generalist developers to whatever is necessary at the moment, but the reality is each developer is a human with hopes and dreams and ambitions and not every role will fit those.

b112 4y ago
As a generalist, you've not only got my goat, you just took it to town and got it drunk. This sort of over reasoning is part of what bugs me about this industry. Many devs change jobs at the drop of a hat, turnover is already high. Yet here you are, worried about job retention, trying to second guess what a dev knows about their own happiness. I know you mean well, both for the org, and the person, but what makes you think you know, better than the dev, what will stress them out or not? You aren't them, so just ask, and as long as it is clear they have thought of it, and want to move ahead, you should 100% drop the matter. Frankly (as if I could be more frank, heh), likely there will be something entirely unrelated which will bug the dev. And all your concerns will be for naught. Except, of course, you are throwing people's resumes in the trash bin, thus reducing your talent pool, due to unfounded concerns.
- tinco 4y ago
  Over reasoning? Because I ask a developer what they want to work on during an interview? Guess what, turnover is high when your developers are unhappy with the work they're doing. I've had developers do work that they didn't like to do, and they quit, so now I make sure they're gonna be happy where I want them. I'm not second guessing anything, in fact my comment says the exact opposite. If a developer reworks their LinkedIn to highlight some expertise they're interested in working on, then I fully trust them on that and will gladly hire them. I'm not sure where your whole angle of not trusting developers to know their own happiness comes from. But let me be clear, if you're a generalist with relevant experience I will definitely ask you to come over for an interview. I'm not throwing valuable resumes in the trash. But during the interview I will be frank about what the job entails, and I'll gauge your response to figure out if you'll be content. Whether I'm effective or not I don't know, but I'm going to have to at least try to get the right person at the right position. edit: BTW I'm not just saying this as a CTO at a small startup, I'm also saying this as a generalist with highly valuable frontend skills and I pray to god I don't have to get into another frontend job (either directly, or by being lured into it after applying as a generalist).
  - b112 4y ago

rjzzleep 4y ago

I'm a generalist and I've had a bunch of DevOps jobs where I had to come in to fix what the complete mess the kubernetes devops specialist left behind. I think the question is more who a generalist markets to. Some people have multiple resume's depending on what they apply for, they come in through one angle and then build some trust and take over more. Or it's a startup that needs help, but doesn't really know what they need help with. The fundamental mistake is that people think that just because someone is specialized on a topic he's also good at it.

jhoelzel 4y ago
Absolutely true, but those are two different things. I -AM- a generalist and it's also a requirment for being actually any good in devops, but I position myself as Freelance Sr. Engineer with Kubernetes / DevOps / Golang Focus, because thats what I like doing and also what I am good at. There is a whole longtail of skills that are required to do any of this, also quite a few that are not even tech related, like proper communication or empathy. But yeah, if you require assitance, I am definitly the kubernetes-dude that you can call and it should be as simple as that.
trashtester 4y ago
I happen to think that "DevOps" is one of those fields that really require some kind of generalist to do well, from the hardware (and virtual hardware) level and a fairly deep understanding of networking to how to build and optimize the kinds of apps and services that will run in the infra. Many get the title "DevOps" who are basically Ops people with a new toolkit. One of the problems with the DevOps stack, though, as working in the infra-as-code needs a dev mentality to be done right. Many traditional ops people will "program" the infra-as-code using pretty bad quality code. (often using way too much cut&paste for stuff that could be generalized.) On the other hand, when devs switch to "devops" they often fail to have the attention to detail and sense of responsibility found with many traditional ops people. So finding good candidates for DevOps roles is really hard, and often those positions are staffed with people who are not really suited for the paradigm.

HWR_14 4y ago

> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? I tend to contract to the guy who can solve my exact problem. Because if the problem can be solved I don't want to pay for headcount permanently. I tend to hire long-term the guy who can solve multiple problems, but less speedily. Which, of course, is different if you mean "hire someone who solves a class of recurring problems I have with a specialized skillset" from "solve the exact problem"