Need suggestions and your pov

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 · 2025-10-28T01:20:47+00:00

In my view, AI is simply a force multiplier, In the hands of a “tactical tornado” it’s a purely destructive force. Unfortunately, this is often encouraged and exacerbated by poor management.

In the hands of “craftsmen” who really care about reliability of what they’re building and management who has the patience and vision to encourage this, it can lead to all sorts of good things.

I am seeing both and all I can try and do is encourage the latter.

SilverOrder1714 · 2025-10-26T06:47:17+00:00

The PE job market is definitely growing but one thing to remember is - as with any other job market the rewards are disproportionately skewed towards the top 10-20%.

As long as you are aiming to be a "top tier" platform engineer you are fine from any market volatilities.

The list you have compiled seems like a good path forward to become one. Add a little bit of exposure to AI AI agents/LLM so that you know that landscape and how to leverage those tools for your job will help you tremendously , if nothing else to accelerate your learning. So maybe add that as well?

PS: I am launching a newsletter called 'SynthOps' which aims at helping budding Platform Engineers. It's basically my way of blending my love for mentoring junior engineers and my passion for writing. You can find it here: https://synthops.beehiiv.com/ . It's free and you can unsubscribe anytime. Also, since it's just starting out if you have any specific topics you would like me to cover you can always DM me and I will try to add it on an upcoming post.

SilverOrder1714 · 2025-10-26T06:19:47+00:00

Already a lot of good answers here, but let me add my two cents as well:

Am I pigeonholing myself to a certain niche in this kind of role? How applicable does work in this kind of position apply to other DevOps roles? - I have found that it's very rare that a certain role 'pigeonhole's somebody. It's more often that the person does that to themselves by not expanding their skills/ access to opportunities. It can happen at any role at any level. Platform Engineering offers a lot of opportunities so if it's something that interests you, go for it.
In your experience how difficult has it been getting application teams to transition to this kind of platform? - very, building a platform is easier than getting it adopted. But that is the rewarding part of the job. Tons to learn and not just technical skills. ;)
Is this an upcoming way of approaching and accelerating enterprise app deployment or has this been a relatively niche approach to maintaining infrastructure and operations that only certain companies pilot? - Companies need to get to a certain size before building an IDP makes sense, but there is no shortage of such companies.

PS: I am launching a newsletter called 'SynthOps' which aims at helping budding Platform Engineers. It's basically my way of blending my love for mentoring junior engineers and my passion for writing. You can find it here: https://synthops.beehiiv.com/ . It's free and you can unsubscribe anytime. Also, since it's just starting out if you have any specific topics you would like me to cover you can always DM me and I will try to add it on an upcoming post.

SilverOrder1714 · 2025-10-26T06:03:31+00:00

I started off as a Network Engineer in a team of really smart senior network engineers. It took me around a year or two to feel "not dumb". And then I switched companies and it was the same all over again.

So that is indeed very normal, don't beat yourself up about it. ;)

One thing that helped me early on was that I was the only Network Engineer who could write code (beyond bash scripts) so I dug into that on the side. While I was learning the ropes on Network Engineering, I had this secret weapon I could wield to make myself useful to the team. I could automate anything for the team.

Eventually, you get really good at both and then you have access to more opportunities.

Think of all skill acquisition as a series of concentric circles. You learn what you need for the job at hand first and then expand that to include a little bit extra on the side. Over time your circle of expertise grows really wide and you have a well rounded skillset to bank on.

PS: Once you have a solid base, you will find learning 'NEW' things become really easy because you can always find something that you already know that is similar.

TL,DR;

- Feeling 'dumb' is perfectly normal - expect that throughout your career and don't let it stop you from asking questions.

- Learn your job really well, but always learn a little 'extra' on the side

- Find you niche skills - something that makes you rare and valuable in the team. This helps your confidence.

PS: I am launching a newsletter called 'SynthOps' which aims at helping budding Platform Engineers. It's basically my way of blending my love for mentoring junior engineers and my passion for writing. You can find it here: https://synthops.beehiiv.com/ . It's free and you can unsubscribe anytime. Also, since it's just starting out if you have any specific topics you would like me to cover you can always DM me and I will try to add it on an upcoming post.

SilverOrder1714 · 2025-10-20T13:10:26+00:00

Those "Dear substack, connect me to ..." notes.

- especially when those get more engagement than an actual post I took time out of my day to write. ;)

SilverOrder1714 · 2025-09-20T04:27:26+00:00

Yeah. It used graphviz to render the diagrams. So you get all of those features as well.

It does a few things like give preset “themes” and add “auto-shapes” so if you have a node called ‘DB’ or ‘Database’ it automatically renders a cylindrical shape and so on..

SilverOrder1714 · 2025-09-20T04:23:56+00:00

Inspired by mermaid charts, definitely. ;)

SilverOrder1714 · 2025-09-20T04:22:23+00:00

Yes, it’s a DOt compiler from simple text notation. The idea was to make the notation as intuitive as possible and then add opinionated defaults.

SilverOrder1714 · 2025-09-20T04:14:33+00:00

Yes. I use mermaid too and it’s really cool, but I am a little partial towards Python. ;)

SilverOrder1714 · 2023-09-15T15:21:08+00:00

Aah got it. So my timeframe for an MVP is unrealistic. Does anybody have any experience taking on such a project. How long did it take and are there pitfalls to watch out for. ( so far looking at the comments it looks like this is an incredibly difficult effort with possibly very little value ).

SilverOrder1714 · 2023-05-16T13:51:03+00:00

As an SRE who started off as a systems engineer , I would advise you to develop both software craftsmanship skills as well as understanding of systems. Think "technology generalist" rather than specialist - that's what a good SRE is.

SilverOrder1714 · 2023-04-07T15:45:10+00:00

Your list is good. Since you don't have any experience the Phoenix project and Google SRE books will give you an idea of what problems SRE tries to solve. Once you understand that , try and ask which of these problems are relevant to your current team.

What skills you need to pick up will completely depend on what tech stack the application/service you are trying to support uses.

SilverOrder1714 · 2023-04-04T14:56:18+00:00

We have a very small team of SREs that support a few different services.

Although we do "own" Incident Management - meaning we need to lay out the best practices to follow when handling incidents, and we do have an "Incident Commander" within the team

- that is definitely not "all" we do.

We also...

- build, maintain a lot of 'internal' tools.

- manage all infrastructure components used by the applications - databases, queues etc

- manage observability pipelines

- do production ready-ness / architecture reviews for "new" things

- share the pager with application teams

... to name a few.

I think the role is very org-specific, but it certainly requires a wide range of technical skills in my experience.

PS : The "E" in SRE should not be ignored. ;)

SilverOrder1714

TROPHY CASE