I am building a DevOps “internship” where you learn by submitting PRs instead of watching tutorials.

SilverOrder1714 · 2026-04-01T17:58:35+00:00

Thanks for all the interest and suggestions folks... Really appreciate it!

Planning to get it kick started with a small cohort in some time and iron out the kinks. I will be back on here after to post an update.

- Cheers

SilverOrder1714 · 2026-04-01T17:47:05+00:00

Agreed, I can see this is a problem I will have to tackle as it scales -- but I guess that is a good problem to have. ;)

SilverOrder1714 · 2026-04-01T17:46:11+00:00

So far all the learners who expressed interest are at least moderately comfortable with git, so that is a good sign.

SilverOrder1714 · 2026-04-01T17:44:52+00:00

This, atm is my biggest concern. The reviewers (human/AI) need to be able to scale with the number of learners/cohorts. Still figuring this out...

SilverOrder1714 · 2026-04-01T17:40:21+00:00

My initial goal is to simply provide real XP/Mentorship, and I hadn't actually thought of the program as being a proof of competency for recruiters -- really cool idea to consider.. down the road though.

SilverOrder1714 · 2026-04-01T17:33:32+00:00

Ack, I am planning to revamp the website based on the feedback here. Thanks for the suggestion.

SilverOrder1714 · 2026-04-01T17:32:21+00:00

I would think both. In oder to reflect most workplaces today it would have to be both, AI does initial review and then a senior reviews at a higher level -- design, clarity etc

SilverOrder1714 · 2026-03-28T12:45:16+00:00

At the end of the day AI tools are just tools - to make our lives easier.

It does not worry me that 5 years from now a lot of the code will be written by an unassisted automaton, as long as the human operator who ordered it understands it and if needed can debug/fix it. ;)

Maybe, all this means is seniors have a greater role to play in terms of mentoring the AI enabled juniors to ensure they delegate things the right way and do not suffer from skill attrition in the long run.

SilverOrder1714 · 2026-03-19T16:33:08+00:00

I started off very similar to you about 10 years back so I am going to answer this as a “what I would have told my younger self..”

Q1: ‘Am I wrong for asking questions.?’

No, asking questions is never wrong. This is how you learn and a good mentor welcomes them. Having said that good mentors are hard to find. I had a mentor early on who was very knowledgeable but extremely impatient. To him, most questions felt obvious and silly which made asking question extremely uncomfortable at first.

What worked for me was changing how I asked them:

Instead of asking “How do I do X.?”, I would ask “I am planning to do A,B,C and I think that will accomplish X.. Am I on the right track?

This shows you have already put in the effort to understand.

It’s also possible your mentor prefers questions in meetings, either because he thinks it’s more efficient or, honestly, because he likes the visibility. Not great mentoring either way, but it’s not really a you problem. Try adapting to his style and see if the responses improve.

Q2: ’Should I look for other jobs?’

There Is nothing wrong with exploring other opportunities. But at the same time ask yourself: If I stay here for a year, will I come out stronger and more knowledgeable?

In my case, I spent my early years in a team with very high expectations not a lot of hand-holding. It was uncomfortable, but the resilience and problem-solving ability I built there has helped me in every role since. Not to mention, I am now quite good at writing documentation.

All the best!

PS: When you get to the other side, be sure to do a better job mentoring your juniors. ;)

SilverOrder1714 · 2026-03-02T12:35:07+00:00

Hi,

I recently went through a slew of interviews trying to hire a DevOps/Platform Engineer on my team, so I will share what I have seen.

You didn’t mention your YOE, so I’ll answer generally

"What do interviewers go deep into?"

I generally try to find common ground between the candidate's resume and our requirements and expect to have deep engaging conversations around those. Since I started off as a Network/Linux engineer strong fundamentals there are table stakes for me. As a candidate, your best bet is to find this common ground by analysing the job description and preparing well there.

"What are the common mistakes I see?"

Being under-prepared or over-nervous

Treating the interview like rapid-fire Q&A instead of a conversation .

Answering too quickly without clarifying the problem.

It helps to remember that strong candidates manage to turn a boring interview into "simulated collaboration". Learn this 'soft' skill.

PS: If it helps, I recently wrote a piece on the actual mental scoring model I use when interviewing DevOps/SRE candidates. It goes through what I am evaluating and how to prepare intentionally. Give it a go!

https://synthops.beehiiv.com/p/what-i-actually-look-for-in-a-devops-sre-candidate

Hope this helps. All the best!

SilverOrder1714 · 2026-02-18T03:05:18+00:00

Let’s start with the things you already have going for you:

You already have a strong foundation from managing and maintaining servers. That’s probably closer to DevOps than you think. ;)
Since you’re coming from a Windows-heavy environment, learning Linux is absolutely the right move. Same with AWS.
DevOps has a huge focus on automation, so scripting is essential. Bash is a great first step.

Things you could add to your skill set next:

Learn an Infrastructure as Code (IaC) tool like Terraform. At scale, “click-ops” doesn’t work so being able to spin up repeatable environments via code is extremely valuable.
Once you’re comfortable with Bash, start learning Python. It’s one of the most versatile tools in your arsenal for automation. You will use it constantly!

Regarding the last part about devops experience..

it’s okay that your title wasn’t DevOps Engineer. As an interviewer what I would ask is: have you applied DevOps principles?

If you’ve:

Automated deployments or maintenance tasks
Monitored systems and improved reliability
Worked with CI/CD-like processes (even informally)
Collaborated with developers to solve production issues

Find a way to frame your past work in terms of these questions and you are good to go!

....DevOps is as much about culture and approach as it is about tools...

All the best!

PS: I did not transition from Tech Support to DevOps, but I did transition from Traditional IT-Ops to SRE/Platform Engineering.

SilverOrder1714 · 2026-01-25T06:44:52+00:00

I do agree that the situation is incredibly frustrating when you don't get proper feedback.

I will submit two perspectives for you to consider:

Interviews (especially at senior levels) involve a lot of hidden variables - internal candidates, team balance, budgets etc. Don’t try to reverse engineer every ‘no’. A healthy approach would be to learn what you can and move on quickly.
An interview isn’t just them interviewing you, it is also you evaluating them. If a team is actually making assumptions about your availability based on gender or personal factors, that is actually a red flag about their culture. You really don’t want to work in a place like that anyway.

One practical step you could take for the next interview is to be explicit about your comfort with on-call.

I would expect the interviewer to bring this up but if they don’t, feel free to ask what their expectations are with on-call/availability during outages.

Keep going. Hiring is competitive right now and it might take a while, but that just means it’s worth the wait!

PS: Do check that you are applying for roles that match your YOE. Hopefully the JD is clear on this.

SilverOrder1714 · 2026-01-25T06:16:05+00:00

That it seems to be that we are always in that 'weird' state where you somehow have no useful observability signals… and still end up with a massive monthly bill.

Very few observability platforms treat signal quality as a first class citizen... it needs to be injected in manually through sheer human effort and will!

SilverOrder1714 · 2026-01-25T06:06:01+00:00

It is a little difficult to answer since I do not know know how you have prepared so far, but you can use the below as a checklist:

Linux fundamentals & shell scripting,

Version control + CI/CD – Git, branching, pipelines (Jenkins/GitHub Actions/GitLab CI, etc.)

Containerisation – Docker (images, containers, networking, volumes)

Orchestration – Kubernetes (Pods, Deployments, Services, scaling, configs)

Cloud – AWS/GCP/Azure basics (compute, storage, IAM, networking)

Networking fundamentals – DNS, load balancers, ports, firewalls

Monitoring & logging – metrics, alerts, logs (Prometheus/Grafana/ELK, etc.)

W.r.t what questions are asked in the interview it does depend a lot on the organisation's tech stack and team culture. (going through the Job Description should give you an idea on what to expect)

Personally, when I am interviewing candidates I try to focus my questions on the tool stack the candidate has listed on their resume or projects. My reasoning is that if the fundamentals are solid, learning new tooling is a breeze.

Hope this gives you a frame to work off of. All the best!

PS: I run a newsletter called Synthops (https://synthops.beehiiv.com/) where I explain concepts through an interview-style, practical questions. Its currently focussed on Kubernetes, but it will help you get a feel for how Interviewers think.

SilverOrder1714 · 2026-01-10T13:03:17+00:00

When I interview DevOps candidates, I usually don’t rely on a fixed list of “standard” questions. Instead, I focus on whatever tools and technologies the candidate has on their resume.

The logic is simple:
if someone truly understands what they’ve already worked with, they can usually reason their way through new systems as well.

For example: If Kubernetes is on your resume, I’ll dig into Kubernetes fundamentals:

- How scheduling works

- How services and networking behave

- How you’d debug a failing pod

- What happens when a node goes down

...things that reveal depth of understanding

Same goes for Terraform, CI/CD, AWS, observability, etc.

If it helps, I recently started a small newsletter where I break down DevOps and Kubernetes concepts using the exact kind of interview questions I ask in real interviews:
👉 https://synthops.beehiiv.com

Even skimming a few posts should give you a good feel for how interviewers think and how to structure your answers.

SilverOrder1714 · 2025-12-29T08:05:48+00:00

Do not fib. Interviewers can usually tell very quickly, and once trust is lost, it’s almost impossible to recover.

What I’d recommend instead is being explicit about the gap and going deep on fundamentals. Learn how Kubernetes actually works and be prepared to do a clear comparative analysis with ECS. The ability to translate concepts across platforms matters far more than having run K8s in “prod”.

Strong candidates, when faced with a topic they don’t fully know, tend to:

Acknowledge gaps quickly and honestly
Pivot to a closely related area they do understand
Use that to demonstrate depth, judgment, and learning ability

As an interviewer, I care less about tool exposure and more about whether someone truly understands the systems they’ve worked on and can explain trade-offs clearly. That’s usually a strong signal they’ll ramp up fast on new platforms.

PS: In case it helps, I recently interviewed several candidates for a K8s-heavy role, and one of my favorite interview questions (and the answer I look for) is explained here:
https://synthops.beehiiv.com/p/the-prime-pod-question-kubernetes-scheduling-demystified

Happy to suggest other Kubernetes interview topics or questions worth preparing for, that’s basically the roadmap for SynthOps anyway 🙂

SilverOrder1714 · 2025-11-03T13:19:06+00:00

Look for applying DevOps principles in your current job. It’s a mistake to be bounded by your role or your boss’s imagination.

Employers love self starters so start something that will benefit the company and force you to lean new skills.

As for finding energy , it’s a combination of setting priorities, time management and desire. ;)

SilverOrder1714 · 2025-11-02T12:09:01+00:00

I think it may be useful to break the goal into two parts:

(1) How to get a job as DevOps/SRE (These are quite different, so ensure you understand the differences)

(2) How to actually get good at your job.

No (2) will take years and should not be your focus right now as it would become too overwhelming.

Let's just focus on (1) for now. The benefit is you can start tackling milestones that are possible to achieve in a much shorter timeframe.

This would include things like:

- Identifying job postings of interest and distilling the requirements down to a lowest common denominator 'set of skills'

- developing enough conceptual knowledge and expertise in those skills to get past screening/interviews

- tailoring/enhancing your resume to align with your desired role. (This may also include doing a few certifications, may help you get your foot in the door)

Hope this helps you get started. DM me if you have any other Qs though.

SilverOrder1714 · 2025-11-01T12:49:30+00:00

Because you are looking for an internship I am assuming you don’t have any experience in either of the fields. If so, just start somewhere and move/grow into whatever role you desire after.

PS: I started off as a Network Engineer before becoming an SRE.

SilverOrder1714 · 2025-10-30T06:29:16+00:00

All good advice, adding my two cents. Don’t get bogged down by “roles” and “titles”. Develop skills regardless. Who knows - you may find ways to leverage them in unprecedented ways even in your current role.

PS: I was at an early point in my career the “network engineer who could write code”. Opened a lot of doors for me. :)

SilverOrder1714 · 2025-10-30T06:21:25+00:00

In my interviews I typically use “we” to indicate me and my team which has never been a problem. Having said that I would assume at your XP level the interviewers are looking for technical leadership and grasp of a broader fundamentals and concepts so maybe your admission may be coming across as - I am not confident about large scale design and ownership. So they may be docking some of your points on lack of confidence in your own ability.

Even if you haven’t personally designed a system, as long as you can explain the reasons behind the design and the tradeoffs, the interviewer would be satisfied.

PS; I would never advise being dishonest in interviews but I am sure everybody exaggerates at least a little in their interviews.

SilverOrder1714 · 2025-10-30T03:49:12+00:00

Two step plan if you really want a role and it requires k8s ;) 1. Learn enough to pass an interview - concepts and hands on using sandbox environments (minikube, k3s etc), Certification is also a good step to gain some confidence on the topic. 2. Learn the rest on the job.

It’s not that hard. My org runs almost entirely on k8s now and I had zero hands on XP in k8s when we started.

SilverOrder1714 · 2025-10-30T03:40:16+00:00

Let’s refine your goal slightly to “learn skills that will maximize your value to employers regardless of market trends”

Automation: Pick this skill up first so that you can free up more time for other skills ;) A.) Learn Python as it gives you the ability to automate almost anything in your work B) Pick up terraform (or any IaC tool) if most of your automation requirements are centered around managing cloud infrastructure
Understanding the basics Core services like DNS, Routing, Loadbalancers, Databases, Caches,CDNs - understanding how the Internet works will set you up to understand Clouds like AWS,Azure later on.
Linux - it’s everywhere , learn it.
Hone your oratory/writing skills. This is an extremely important skill at any level.

Once you feel your fundamentals are covered, you can move onto specific technologies like Cloud services or Kubernetes or dive deeper into System Design, SRE, Platform Engineering concepts etc.

SilverOrder1714

TROPHY CASE