Yes, you’re doing work, so are others, you’re managing time (your own or others), there’s always other people involved… it’s always helpful to you to understand common work methodologies or have experience with soft skills in order to accomplish anything.
1 Like
I recommend you read this book
Its important IMO to understand that a lot of tools like Kubernetes or frameworks such as Spring or Laravel or whatever are just plumbing and should be treated as lower level things and try not to marry your system to these things with such a high coupling.
1 Like
“DevOps” has become a buzzword mangled by consultants, what do you mean when you say DevOps?
To me (and Amazon, Atlassian, etc.) DevOps is a set of practices to shorten development lifecycles. There are no “required” technologies, it all depends on your environment what you could, and should, use.
Generally there is still a division between devs and ops, they come at the same problem from a different angle, where there is tooling overlap the usage of the tools is usually different between the two.
For ops, going more in the DevOps direction is learning about automated deployment and provisioning. I’m not sure what would be required for cloud deployments, but managing virtual machines, administering stuff like Kubernetes, and automating with software like Puppet would go on the non-cloud side (or the “in-house cloud”).
If you want to become a dev then you’re looking at, well, first becoming a dev, and not just a programmer (just know that the difference is seldom appreciated). The tooling on that end of the spectrum is more focused on automated quality control (test automation, static analysis), automated builds and automated deployment (which is where dev and ops tend to meet).
Any company that expects a single person to do all of the above imho needs to hire a therapist, not an IT-person.
On the topic of “the cloud”: it’s optional, as long as you automatically deploy it doesn’t make a difference where it goes, could be a bunch of CGI scripts to some Apache instances, as long as it’s tested and automated it qualifies as DevOps.
All that said I’d argue focusing on the tools is the wrong approach, DevOps is not a position, or job title (well at some companies it is, you likely don’t want to work there), just like Agile is not Scrum, or Kanban, it’s about finding a better way to get something out the door and handle changing requirements effectively without requiring ridiculous effort from your employees (and massive uncertaintly at management level).
As far as finding a DevOps job goes, my recommendation to get into DevOps at a competent place would be to see if some form of agile is practiced. (Good) agile and DevOps tend to go hand-in-hand, so ask them about build automation, CICD or how they automate their environments. If they only do agile and no other automation then their agile is probably “fragile” and I’d recommend giving them a pass, since agile without automation just doesn’t work particularly well in IT.
If you find a place then you’ll be able to just pick up the tools they use, instead of gambling on what would be “desirable” for the “market”.
Hi thank you for your information.
what do you mean when you say DevOps?
I’m using the term quiet loosely here as right now my background is Ops, and limited experience in deployment, mostly automation and improvement of existing processes.
However I do have great ambition to improve on my skills in development and really see great beauty in the agile framework.
So I’d like to work on improving my skill set to mainly be in Ops but have the opportunity to work with devs in a CI environment in the future. I don’t wish to be both Ops and Dev at the same time - Ain’t nobody got time for that.
All that said I’d argue focusing on the tools is the wrong approach
I’d expect that if I would want to in a sector that uses such tools then it’s expect that I have some knowledge of those tools if possible. I understand that the tools are not the aspect to focus on and it’s better to have overall foundation knowledge. I think the tools are easier to understand and use which is why it’s heavily suggested, while the actual principles are best grasped when actually faced with the problems presented in that role.
Thank you!
The likes of Puppet and Ansible are, from what I understand of friends that are in that space, the way to go. Anything related with monitoring is also high on the priority list, so log aggregation, metrics and monitoring, examples being Grafana, the ELK stack (Elasticsearch, Logstash, Kibana).
Of course virtualisation and containerisation are pretty important, so setting up VMs, containers and managing them. This has been covered already by others, but Kubernetes is a good one there, though there’s also Rancher (which is related to Kubernetes, firstly by being a fork, secondly, in the sense that many of the Rancher features eventually make it back into Kubernetes). There’s also RedHat’s OpenShift, so learning Kubernetes and ending up in an OpenShift environment might result in, well, having spent effort in the wrong place (I have a hard time considering learning anything to be “wasted time”,
and concepts will more than likely carry over since they’re both Docker underneath)
Personally I’d start by focusing on the creation and managing of plain old Docker via the command line, in my experience understanding what tools do for you makes you understand them better (and makes it easier to debug things when they do go south) and it also makes you appreciate them more for the work they save you.
Glad we’re on the same page there. Unrealistic expectations are a staple in IT, so you’ll have to pardon me for being careful here 
Any good company that’s hiring juniors will consider any prior knowledge a bonus rather than a requirement, focusing on the right “direction”, and, as has been mentioned by others, having the basics down, is, in my experience, a lot more important. At least when I’m interviewing I’m less interested in what they know now than what they expect to learn and what their thoughts are on an organisational level (eg. do they enjoy thinking outside of the box).
If probing for containerisation knowledge I’ll focus on Docker, any higher level tools are nice to haves and should be relatively easy to pick up if they have the basics down.
For programmers (since I mostly deal with those, so I’ll use that as an example) I generally probe for development methodologies, are they stuck in the mindset of the OO/Procedural languages (eg. Java, C#, Python,…) or do they actually understand different methodologies (set-based programming, functional programming,…).
Further I usually try to gauge their interest in topics not directly related to programming as such: do they only want to be code-monkeys, or do they have opinions about design/architecture, project organisation (eg. opinions on agile, relationship with other business entities, like operations/internal, or external customers, management,…), etc.
I’d also note that having some stuff on your CV that isn’t directly “marketable” at a job interview, but is IT related, is, at least to the more technologically enthusiastic interviewers, generally a good thing as it indicates you’re probably not just into it to get a well paying job but are actually enthusiastic about the field.
Yes.
(for practice… that’s like 20 VMs which may be tight on a typical 16G ram laptop even with ksm, but at least ram is cheap these days, it’s not unreasonable to see 64G in a typical developer workstation)
I just figure out that indeed VMs are needed if I want multiple clusters (instead of single node cluster like minikube), which led me to vagrant + virtualbox or microk8s + multipass combos.
ugh, I need to figure out which one allows to assign storage to different physical volume since I only have 120GB (avail: ~42GB) on system disk
I only have 16GB in my desktop 
kind might be the best way to go in terms of tight resources, but I’d opt for option that’s closer to majority of production out there.
Would be interested to know what option you went with in the end as I am looking to do the same, i have 16GB I7 which 120GB storage to use as a lab.
Containers go a long, long way at preserving resources. I used a RockPRO64 and three VMs to set up a little Kubernetes cluster. All in all it was like 10GB of RAM
Don’t forget that AWS and Google Cloud give you a year of “Free Tier” services. With something like Terraform or Ansible you could spin up a ton of resources, make a few requests/calls, and tear it all down in a few minutes.
so when you say VMs were you running on a base OS like Centos/Debian and then installed those via docker or did you set up 3 separate VMs and within that run your containers?
I have Debian Buster on a RockPRO64 with kubectl, kublet, and whatever else was required. It’s the control plane. Then I have a Dell T410 with CentOS 8 installed and KVM configured. I setup three virtual machines via KVM (also CentOS 8) and installed the same services that were installed on the RockPRO64.
From there, I “synced” the VMs to the RP64 (it was the “master node”). After that, I ran most commands through the RP64. I say “most” because if you build a container on ARM64 it won’t run on AMD64.
So a RP64 with Debian Buster + Kubernetes and containerd installed, plus the networking stuff.
Three CentOS VMs (on a KVM host) + Kubernetes and containerd installed.
Each VM was 2 CPU and 2GB of RAM. Don’t remember the specs of the RP64 but it’s like 6 cores and 4GB of RAM?
Ah, not even. 6 cores and 2GB of RAM
Great thanks for the write up, much appreciated 
1 Like
I’m in the middle of this journey and have found it hard to be taken seriously in DevOps related interviews coming from more traditional sysadmin activities. To the point where every interview I’ve had has asked why I didn’t get a CS degree if I was interested in “developer” work.
I’ve also found my CISSP cert means next to nothing to these positions as they prefer to build their own tooling and often talk down about anything they consider archaic.
It really seems like many companies are treating DevOps/SRE positions as the dumping ground for low quality CS majors they feel wouldn’t cut it in SWE roles, this mentality is reflected in compensation and work hours for positions.
I know I commented in your other thread, and this one may get necro’d, but I think that you are interviewing at the wrong places, or you just don’t have enough experience to counter the arguments. There is no need to have CS degree if you want to be a developer. The Software Engineering degree and path is more than suited for that. If you want to architect stuff, that is where a CS degree would be better suited. It does not take much to be a coder honestly.
I would have countered with something like, “I did choose to do a CS track because CS does not guarantee that I would have a solid software, networking, and hardware troubleshooting background. There are developers that cannot even setup their IDE, let alone troubleshoot computer issues. For DevOps, you need to have solid all around working knowledge of the back ends and the front ends, and everything in between.”
One thing that I would like to stress about interviewing is to learn how and when to take control of the interview process to achieve you goals. Remember that the questioning goes both way. It is not just to see if they think you are a good fit for their desired outcomes, it is also for you to ask them questions to see where they fit in you career path and goals. If their moral compass does not fit with yours, walk away. If they seem to pushy or you feel uneasy or uncomfortable about something and you cannot resolve it during the interview, walk away. Don’t get to cocky, but remember that they need you just as much as you need a job. It is okay to push back because, if they were not interested, they would have never called [you in].
2 Likes
what the actual fuck
what kind of companies are those?
where’s all that “you don’t need a CS degree to be a software developer” we can see all over youtube (from people with CS degree)?
Depending on the tone of the question, it could be a fair question, or it could be snarky/demeaning.
It could be the interviewers were just poorly trained, you would do well to ask them, why they would be asking that - since most people in the industry keep saying how background doesn’t matter as long as you have the knowledge, the skill, and culture fit to do the job.
Do you care to share the company names or would that be to de-anonymyzing? (I’ll take the names over a PM if you don’t want to post publicly).
If you apply for a “pure dev” position, do your interviews, and they’re not sure, but you mention something sys admin-y on your resume or mention it in interview, they might decide to “re-interview” you for a SWE/DevOps position. What you may lack in theoretical algorightm knowledge, you may make up (and more?) for in systems knowledge, and two together may make you a useful DevOps/SRE person.
Most places determine pay by having some kind of job ladder, where you get paid more for more responsibility. Each rung on the ladder corresponds to a band of pay.
“work hours” shouldn’t really be up for discussion. Typically there’d be normal business hours ; for DevOps once in a while you’d typically get an oncall shift. That ideally should never be 24/7 and should be compensated.
Ideal rotation size (number of people) and length varies from company to company and org to org. Where I work, 3 people is considered not sustainable, 6 people is “ideal” minimum, 10-12 people works and is ok, but at that point you may want to consider sharding the team along technology lines. So instead of 10-12 people caring about a lot of stuff, you have 2 groups of 5-6 people in each caring about half of a lot of stuff.
For example, we have two tiers of oncall compensation depending on oncall response time for the oncall rotation you’re a part of. While you’re oncall, you get compensated for time you’re oncall outside of regular business hours. If you’re response time for your rotation is <= 5min (from receiving a page, to fingers on keyboard working on a problem… plenty of time to get out of the shower typically, or wake up early morning) you get 66% of your base pay for time you spend oncall . (33% for 15m+response time). There’s no expectation to be online and working while oncall, unless you’re paged.
This means that if you’re oncall for well behaved services, you just get paid extra for not doing much extra. If your service sucks, you’re paid less than business hours for lots of work … you’re financially incentivized to make the service not suck … beyond it being a part of your core job.
2 Likes
Sure I don’t mind talking about the mess that was interviewing. IBM, Amazon, Facebook, were the most hostile ones I can think of.
IBM is a dumpster fire so no harm in being gated from the job over not being a CS student, their programming interview was a disaster that expected I’d import pandas to do some CSV analysis with no indication outside libraries were expected.
Amazon the interviewer asked why I didn’t commit to CS if I was interested in software engineering as a career. They didn’t seem to like my explanation that my degree was taught under the engineering department but focused on system design and business integration rather than AI theory and algorithm complexity in my senior year.
Facebook the interviewer asked a lot of probing questions about my algorithms abilities and commented that CS students were preferred as they had more advanced algorithm exposure to “do the real work”
Keep in mind my entire interview exposure was during the pandemic and I might not have been dealing with the normal process
2 Likes
what the actual fuck
that was unexpected
that’s bad, but have you gotten algorithms and programming figured out?
have you got a good github?
When I interview folks I tend to pose a problem and then let them tease out some of the parameters of the interview.
So e.g. pandas … if they’d asked if they can use it, I’d ask why? and I’d expect an answer along the lines of “it’s got a relatively efficient albeit somewhat limited parser written in C” and it’s common these days with all the cool kids using it for ML. As long as we can hold a dataset in ram. That’d take a whole 30s-60s. From there we could discuss inner workings of data frames and memory layout, python object models and metaclasses, or we could go back to the original problem… In general the goal would be to find the edges of the candidates knowledge and abilities and confidently recommend hire/no hire and if hire then at what level.
1 Like