AI news is getting noisy again.

New models. Coding agents. Cybersecurity benchmarks. Cloud agent platforms. Open-source AI tools. Huge infrastructure spending.

But if you are learning cloud, Linux, AWS, automation, or practical AI, I think the useful question is not:

"What is the best AI tool?"

It is:

"What skills help me use any AI tool better?"

My current answer:

1. Learn delegation, not just prompting
2. Learn enough cybersecurity to verify AI output
3. Learn the cloud stack around AI
4. Use GitHub trends as a learning signal, not entertainment
5. Build durable foundations

Linux, networking, cloud, automation, debugging, security, data handling, and technical writing will still matter whether the AI hype grows or cools.

Curious how others are thinking about this: if you are learning tech right now, are you focusing more on AI tools, cloud, Linux, coding, or security?

https://preview.redd.it/qfejbfsmxvyg1.png?width=1672&format=png&auto=webp&s=edf56bfbe020d0bd8d0eca785ff5479f0d9f6495

AI news is getting noisy again.

New models. Coding agents. Cybersecurity benchmarks. Cloud agent platforms. Open-source AI tools. Huge infrastructure spending.

But if you are learning cloud, Linux, AWS, automation, or practical AI, I think the useful question is not:

"What is the best AI tool?"

It is:

"What skills help me use any AI tool better?"

My current answer:

1. Learn delegation, not just prompting
2. Learn enough cybersecurity to verify AI output
3. Learn the cloud stack around AI
4. Use GitHub trends as a learning signal, not entertainment
5. Build durable foundations

Linux, networking, cloud, automation, debugging, security, data handling, and technical writing will still matter whether the AI hype grows or cools.

Curious how others are thinking about this: if you are learning tech right now, are you focusing more on AI tools, cloud, Linux, coding, or security?

I recently went through the AWS Data Center Technician (DCO) interview process. I got rejected, but I prepared seriously, and I want to share everything in one place so others don't have to start from scratch.

This is the guide I wish I had found before I started.

Table of Contents

1. What the role actually is
2. What the interview looks like
3. Technical areas to study
4. The troubleshooting formula that works
5. Behavioral prep — STAR stories
6. Amazon Leadership Principles for DCO
7. Full list of expected questions
8. Questions to ask the interviewer
9. What not to say
10. The honest lesson

1. What the Role Actually Is

AWS DCO is not a desk job. It is a hands-on, shift-based, operational role inside a data center.

Day to day, you are:

• Handling tickets for hardware failures, network issues, and component replacements.
• Following runbooks and safety procedures.
• Documenting everything — every step, every result.
• Escalating issues with clean evidence when they are outside your scope.
• Working rotating shifts, weekends, and on-call rotations.

The interview reflects this. They want to know if you can think clearly under pressure, follow process safely, and communicate honestly when things go wrong.

2. What the Interview Looks Like

• Expect 1.5 to 2+ hours total, sometimes split across multiple rounds.
• The split is roughly 20–30% technical and 70–80% behavioral / leadership principles.
• Yes, you read that right. Most of it is not hardware questions. It is psychology and storytelling.
• The interviewer may guide you through questions to give you chances to hit the right points, but the bar is still real.

3. Technical Areas to Study

You do not need to be a hardware engineer. You need to be able to troubleshoot logically and explain your reasoning clearly.

Hardware Basics

• BIOS / UEFI and POST.
• CPU, RAM, DIMMs, motherboard, PSU.
• HDD vs SSD vs NVMe.
• IPMI / BMC, what it is and when you use it.
• ESD precautions and thermal paste basics.
• Basic RAID concept (redundancy and disk failure).

Networking Basics

• OSI Layers 1, 2, and 3.
• Switch vs router.
• DHCP and DNS.
• TCP handshake (SYN, SYN-ACK, ACK).
• SSH — what it is and what port it uses.
• Subnets and default gateway.

Fiber Basics

• Single-mode vs multi-mode fiber.
• SFP transceivers.
• VFL (Visual Fault Locator) — what it does and when to use it.
• Loopback tests.
• Light meter basics.

Linux Commands to Know

• ping — basic reachability.
• ip addr — Check the interface and IP.
• ip route — Check the gateway.
• traceroute — trace path to destination.
• nslookup / dig — DNS testing.
• journalctl — system logs.
• dmesg — kernel and hardware messages.
• systemctl status — check service status.
• lsblk — list block storage.

4. The Troubleshooting Formula That Works

Use this structure for every single technical question. Everyone.

1. Clarify — confirm the symptom and scope from the ticket.
2. Impact — which service is affected, and how severe?
3. Safety — ESD, access rules, what procedure applies?
4. Physical checks — start with the simplest things first.
5. Isolate — one variable at a time.
6. Runbook — follow the approved procedure.
7. Verify — confirm the fix actually worked.
8. Document — every step, every result, timestamps.
9. Escalate — with clear evidence if it is outside your scope.

This formula shows them exactly what they want: structured thinking, safety awareness, and documentation discipline.

5. Behavioral Prep — STAR Stories

This is where most people underestimate the prep needed.

You need at least 8 to 10 stories, covering different situations. Using the same story twice across interviewers is one of the biggest mistakes you can make — they compare notes.

Story Types to Prepare

• Difficult technical problem with a root cause that wasn't obvious.
• Frustrated or stressed customer.
• Mistake you made and how you recovered.
• Time you disagreed with a decision and how you handled it.
• Time you had to learn something quickly.
• Time you worked under high pressure.
• Process or documentation improvement you drove.
• Escalation where you handed off clean evidence.
• Ambiguous situation with incomplete information.
• Long-term result that required consistency.

STAR Format

• S — Situation (15–25 seconds): context, what was happening.
• T — Task (10–15 seconds): your specific responsibility.
• A — Action (45–75 seconds): exact steps you took. Say I, not we.
• R — Result (15–30 seconds): what changed, with numbers if possible.
• Lesson — add one sentence on what you learned or would do differently.

Most Important Rule

The result is what most people make too weak. If your story ends without a clear, concrete outcome, the whole story feels unfinished. Every story needs a landing.

6. Amazon Leadership Principles for DCO

You do not need to memorize all 16. Focus on these 8 for DCO specifically.

Principle	What it means in DCO
Customer Obsession	Protect service availability; act on impact
Ownership	Own the quality of your escalation, not just your fix
Dive Deep	Diagnose layer by layer; do not guess
Insist on Highest Standards	Do not close a ticket until the fix is verified and documented
Bias for Action	Move fast on safe, approved steps; escalate early on risk
Earn Trust	Say what you know and what you don't; be honest about mistakes
Learn and Be Curious	Use every ticket to build your knowledge
Deliver Results	Balance speed, safety, quality, and SLA together

7. Full List of Expected Questions

Opening

• Tell me about yourself.
• Why AWS? Why DCO specifically?
• Why are you making this transition?
• What do you know about the DCO role?

Behavioral

• Tell me about a time you solved a difficult technical problem.
• Tell me about a time you had a frustrated customer.
• Tell me about a time you made a mistake.
• Tell me about a time you disagreed with a decision.
• Tell me about a time you had to learn something quickly.
• Tell me about a time you worked under pressure.
• Tell me about a time you simplified a complex process.
• Tell me about a time you had to deal with ambiguity.
• Tell me about something you are proud of.
• Tell me about a project that didn't go the way you wanted.

Technical

• How would you troubleshoot a server that does not power on?
• How would you troubleshoot a server that does not POST?
• A server has 12 DIMM slots but only 6 are recognized. What do you do?
• What is IPMI / BMC?
• Explain OSI Layers 1, 2, and 3.
• What is DHCP? What is DNS?
• What is the difference between a switch and a router?
• How would you troubleshoot no network connectivity?
• What is a VFL?
• What is an SFP?
• How would you troubleshoot Layer 1? Layer 2?

Role Fit

• Are you okay with rotating shifts, weekends, and on-call?
• Are you comfortable with physical handling?
• What would you do if you didn't know the answer?
• What would you do if a senior told you to skip a runbook step?
• How would you prioritize three urgent tickets at once?

8. Questions to Ask the Interviewer

Do not skip this. Not asking questions is a red flag. Prepare at least four.

1. What does success look like for a new DCO technician after 3 to 6 months?
2. What are the most common tickets a new technician should master first?
3. How does the team balance speed, SLA pressure, and safety when they are in tension?
4. How is training structured for new technicians?
5. What mistakes do new technicians most commonly make?
6. What separates a good DCO technician from a great one after the first year?
7. What does great ticket documentation look like here?

9. What Not to Say

Instead of this	Say this
"That's not my job."	"I own the quality of the handoff."
"I just escalated it."	"I escalated with full documentation of what I'd already tested."
"I'd try parts until it works."	"I'd isolate one variable at a time, following the runbook."
"I prefer not to work nights."	"I understand this is 24/7 and I'm ready for rotating shifts."
"I don't know." (and nothing else)	"I don't know that yet — I'd check the runbook, ask a senior, and learn it properly."
"I've never failed."	(Use a real failure story. Every interviewer knows this answer is false.)
"We did..."	"I did..." — Amazon interviewers want individual evidence.

10. The Honest Lesson

I prepared for four days before the interview. That was not enough for this role.

The technical part is not impossible — if your background is in engineering or support, you can handle it. But the behavioral side and the story quality matter just as much, maybe more. My stories were not strong enough in the result part, and that cost me.

If you are preparing for AWS DCO:

• Start at least 2 weeks out.
• Practice stories out loud, not just in your head.
• Treat the behavioral section as the main event.
• Make every story end with a concrete, specific result.
• If you use AI tools to prep — use them for bullet points and structure, not as a replacement for actually knowing your material.

Good luck. The interview is fair. The process is transparent. You just need to actually prepare for it.

I recently went through the AWS Data Center Technician (DCO) interview process. I got rejected, but I prepared seriously, and I want to share everything in one place so others don't have to start from scratch.

This is the guide I wish I had found before I started.

Table of Contents

1. What the role actually is
2. What the interview looks like
3. Technical areas to study
4. The troubleshooting formula that works
5. Behavioral prep — STAR stories
6. Amazon Leadership Principles for DCO
7. Full list of expected questions
8. Questions to ask the interviewer
9. What not to say
10. The honest lesson

1. What the Role Actually Is

AWS DCO is not a desk job. It is a hands-on, shift-based, operational role inside a data center.

Day to day, you are:

• Handling tickets for hardware failures, network issues, and component replacements.
• Following runbooks and safety procedures.
• Documenting everything — every step, every result.
• Escalating issues with clean evidence when they are outside your scope.
• Working rotating shifts, weekends, and on-call rotations.

The interview reflects this. They want to know if you can think clearly under pressure, follow process safely, and communicate honestly when things go wrong.

2. What the Interview Looks Like

• Expect 1.5 to 2+ hours total, sometimes split across multiple rounds.
• The split is roughly 20–30% technical and 70–80% behavioral / leadership principles.
• Yes, you read that right. Most of it is not hardware questions. It is psychology and storytelling.
• The interviewer may guide you through questions to give you chances to hit the right points, but the bar is still real.

3. Technical Areas to Study

You do not need to be a hardware engineer. You need to be able to troubleshoot logically and explain your reasoning clearly.

Hardware Basics

• BIOS / UEFI and POST.
• CPU, RAM, DIMMs, motherboard, PSU.
• HDD vs SSD vs NVMe.
• IPMI / BMC, what it is and when you use it.
• ESD precautions and thermal paste basics.
• Basic RAID concept (redundancy and disk failure).

Networking Basics

• OSI Layers 1, 2, and 3.
• Switch vs router.
• DHCP and DNS.
• TCP handshake (SYN, SYN-ACK, ACK).
• SSH — what it is and what port it uses.
• Subnets and default gateway.

Fiber Basics

• Single-mode vs multi-mode fiber.
• SFP transceivers.
• VFL (Visual Fault Locator) — what it does and when to use it.
• Loopback tests.
• Light meter basics.

Linux Commands to Know

• ping — basic reachability.
• ip addr — Check the interface and IP.
• ip route — Check the gateway.
• traceroute — trace path to destination.
• nslookup / dig — DNS testing.
• journalctl — system logs.
• dmesg — kernel and hardware messages.
• systemctl status — check service status.
• lsblk — list block storage.

4. The Troubleshooting Formula That Works

Use this structure for every single technical question. Everyone.

1. Clarify — confirm the symptom and scope from the ticket.
2. Impact — which service is affected, and how severe?
3. Safety — ESD, access rules, what procedure applies?
4. Physical checks — start with the simplest things first.
5. Isolate — one variable at a time.
6. Runbook — follow the approved procedure.
7. Verify — confirm the fix actually worked.
8. Document — every step, every result, timestamps.
9. Escalate — with clear evidence if it is outside your scope.

This formula shows them exactly what they want: structured thinking, safety awareness, and documentation discipline.

5. Behavioral Prep — STAR Stories

This is where most people underestimate the prep needed.

You need at least 8 to 10 stories, covering different situations. Using the same story twice across interviewers is one of the biggest mistakes you can make — they compare notes.

Story Types to Prepare

• Difficult technical problem with a root cause that wasn't obvious.
• Frustrated or stressed customer.
• Mistake you made and how you recovered.
• Time you disagreed with a decision and how you handled it.
• Time you had to learn something quickly.
• Time you worked under high pressure.
• Process or documentation improvement you drove.
• Escalation where you handed off clean evidence.
• Ambiguous situation with incomplete information.
• Long-term result that required consistency.

STAR Format

• S — Situation (15–25 seconds): context, what was happening.
• T — Task (10–15 seconds): your specific responsibility.
• A — Action (45–75 seconds): exact steps you took. Say I, not we.
• R — Result (15–30 seconds): what changed, with numbers if possible.
• Lesson — add one sentence on what you learned or would do differently.

Most Important Rule

The result is what most people make too weak. If your story ends without a clear, concrete outcome, the whole story feels unfinished. Every story needs a landing.

6. Amazon Leadership Principles for DCO

You do not need to memorize all 16. Focus on these 8 for DCO specifically.

Principle	What it means in DCO
Customer Obsession	Protect service availability; act on impact
Ownership	Own the quality of your escalation, not just your fix
Dive Deep	Diagnose layer by layer; do not guess
Insist on Highest Standards	Do not close a ticket until the fix is verified and documented
Bias for Action	Move fast on safe, approved steps; escalate early on risk
Earn Trust	Say what you know and what you don't; be honest about mistakes
Learn and Be Curious	Use every ticket to build your knowledge
Deliver Results	Balance speed, safety, quality, and SLA together

7. Full List of Expected Questions

Opening

• Tell me about yourself.
• Why AWS? Why DCO specifically?
• Why are you making this transition?
• What do you know about the DCO role?

Behavioral

• Tell me about a time you solved a difficult technical problem.
• Tell me about a time you had a frustrated customer.
• Tell me about a time you made a mistake.
• Tell me about a time you disagreed with a decision.
• Tell me about a time you had to learn something quickly.
• Tell me about a time you worked under pressure.
• Tell me about a time you simplified a complex process.
• Tell me about a time you had to deal with ambiguity.
• Tell me about something you are proud of.
• Tell me about a project that didn't go the way you wanted.

Technical

• How would you troubleshoot a server that does not power on?
• How would you troubleshoot a server that does not POST?
• A server has 12 DIMM slots but only 6 are recognized. What do you do?
• What is IPMI / BMC?
• Explain OSI Layers 1, 2, and 3.
• What is DHCP? What is DNS?
• What is the difference between a switch and a router?
• How would you troubleshoot no network connectivity?
• What is a VFL?
• What is an SFP?
• How would you troubleshoot Layer 1? Layer 2?

Role Fit

• Are you okay with rotating shifts, weekends, and on-call?
• Are you comfortable with physical handling?
• What would you do if you didn't know the answer?
• What would you do if a senior told you to skip a runbook step?
• How would you prioritize three urgent tickets at once?

8. Questions to Ask the Interviewer

Do not skip this. Not asking questions is a red flag. Prepare at least four.

1. What does success look like for a new DCO technician after 3 to 6 months?
2. What are the most common tickets a new technician should master first?
3. How does the team balance speed, SLA pressure, and safety when they are in tension?
4. How is training structured for new technicians?
5. What mistakes do new technicians most commonly make?
6. What separates a good DCO technician from a great one after the first year?
7. What does great ticket documentation look like here?

9. What Not to Say

Instead of this	Say this
"That's not my job."	"I own the quality of the handoff."
"I just escalated it."	"I escalated with full documentation of what I'd already tested."
"I'd try parts until it works."	"I'd isolate one variable at a time, following the runbook."
"I prefer not to work nights."	"I understand this is 24/7 and I'm ready for rotating shifts."
"I don't know." (and nothing else)	"I don't know that yet — I'd check the runbook, ask a senior, and learn it properly."
"I've never failed."	(Use a real failure story. Every interviewer knows this answer is false.)
"We did..."	"I did..." — Amazon interviewers want individual evidence.

10. The Honest Lesson

I prepared for four days before the interview. That was not enough for this role.

The technical part is not impossible — if your background is in engineering or support, you can handle it. But the behavioral side and the story quality matter just as much, maybe more. My stories were not strong enough in the result part, and that cost me.

If you are preparing for AWS DCO:

• Start at least 2 weeks out.
• Practice stories out loud, not just in your head.
• Treat the behavioral section as the main event.
• Make every story end with a concrete, specific result.
• If you use AI tools to prep — use them for bullet points and structure, not as a replacement for actually knowing your material.

Good luck. The interview is fair. The process is transparent. You just need to actually prepare for it.

I recently went through the AWS Data Center Technician (DCO) interview process. I got rejected, but I prepared seriously, and I want to share everything in one place so others don't have to start from scratch.

This is the guide I wish I had found before I started.

Table of Contents

1. What the role actually is
2. What the interview looks like
3. Technical areas to study
4. The troubleshooting formula that works
5. Behavioral prep — STAR stories
6. Amazon Leadership Principles for DCO
7. Full list of expected questions
8. Questions to ask the interviewer
9. What not to say
10. The honest lesson

1. What the Role Actually Is

AWS DCO is not a desk job. It is a hands-on, shift-based, operational role inside a data center.

Day to day, you are:

• Handling tickets for hardware failures, network issues, and component replacements.
• Following runbooks and safety procedures.
• Documenting everything — every step, every result.
• Escalating issues with clean evidence when they are outside your scope.
• Working rotating shifts, weekends, and on-call rotations.

The interview reflects this. They want to know if you can think clearly under pressure, follow process safely, and communicate honestly when things go wrong.

2. What the Interview Looks Like

• Expect 1.5 to 2+ hours total, sometimes split across multiple rounds.
• The split is roughly 20–30% technical and 70–80% behavioral / leadership principles.
• Yes, you read that right. Most of it is not hardware questions. It is psychology and storytelling.
• The interviewer may guide you through questions to give you chances to hit the right points, but the bar is still real.

3. Technical Areas to Study

You do not need to be a hardware engineer. You need to be able to troubleshoot logically and explain your reasoning clearly.

Hardware Basics

• BIOS / UEFI and POST.
• CPU, RAM, DIMMs, motherboard, PSU.
• HDD vs SSD vs NVMe.
• IPMI / BMC, what it is and when you use it.
• ESD precautions and thermal paste basics.
• Basic RAID concept (redundancy and disk failure).

Networking Basics

• OSI Layers 1, 2, and 3.
• Switch vs router.
• DHCP and DNS.
• TCP handshake (SYN, SYN-ACK, ACK).
• SSH — what it is and what port it uses.
• Subnets and default gateway.

Fiber Basics

• Single-mode vs multi-mode fiber.
• SFP transceivers.
• VFL (Visual Fault Locator) — what it does and when to use it.
• Loopback tests.
• Light meter basics.

Linux Commands to Know

• ping — basic reachability.
• ip addr — Check the interface and IP.
• ip route — Check the gateway.
• traceroute — trace path to destination.
• nslookup / dig — DNS testing.
• journalctl — system logs.
• dmesg — kernel and hardware messages.
• systemctl status — check service status.
• lsblk — list block storage.

4. The Troubleshooting Formula That Works

Use this structure for every single technical question. Everyone.

1. Clarify — confirm the symptom and scope from the ticket.
2. Impact — which service is affected, and how severe?
3. Safety — ESD, access rules, what procedure applies?
4. Physical checks — start with the simplest things first.
5. Isolate — one variable at a time.
6. Runbook — follow the approved procedure.
7. Verify — confirm the fix actually worked.
8. Document — every step, every result, timestamps.
9. Escalate — with clear evidence if it is outside your scope.

This formula shows them exactly what they want: structured thinking, safety awareness, and documentation discipline.

5. Behavioral Prep — STAR Stories

This is where most people underestimate the prep needed.

You need at least 8 to 10 stories, covering different situations. Using the same story twice across interviewers is one of the biggest mistakes you can make — they compare notes.

Story Types to Prepare

• Difficult technical problem with a root cause that wasn't obvious.
• Frustrated or stressed customer.
• Mistake you made and how you recovered.
• Time you disagreed with a decision and how you handled it.
• Time you had to learn something quickly.
• Time you worked under high pressure.
• Process or documentation improvement you drove.
• Escalation where you handed off clean evidence.
• Ambiguous situation with incomplete information.
• Long-term result that required consistency.

STAR Format

• S — Situation (15–25 seconds): context, what was happening.
• T — Task (10–15 seconds): your specific responsibility.
• A — Action (45–75 seconds): exact steps you took. Say I, not we.
• R — Result (15–30 seconds): what changed, with numbers if possible.
• Lesson — add one sentence on what you learned or would do differently.

Most Important Rule

The result is what most people make too weak. If your story ends without a clear, concrete outcome, the whole story feels unfinished. Every story needs a landing.

6. Amazon Leadership Principles for DCO

You do not need to memorize all 16. Focus on these 8 for DCO specifically.

Principle	What it means in DCO
Customer Obsession	Protect service availability; act on impact
Ownership	Own the quality of your escalation, not just your fix
Dive Deep	Diagnose layer by layer; do not guess
Insist on Highest Standards	Do not close a ticket until the fix is verified and documented
Bias for Action	Move fast on safe, approved steps; escalate early on risk
Earn Trust	Say what you know and what you don't; be honest about mistakes
Learn and Be Curious	Use every ticket to build your knowledge
Deliver Results	Balance speed, safety, quality, and SLA together

7. Full List of Expected Questions

Opening

• Tell me about yourself.
• Why AWS? Why DCO specifically?
• Why are you making this transition?
• What do you know about the DCO role?

Behavioral

• Tell me about a time you solved a difficult technical problem.
• Tell me about a time you had a frustrated customer.
• Tell me about a time you made a mistake.
• Tell me about a time you disagreed with a decision.
• Tell me about a time you had to learn something quickly.
• Tell me about a time you worked under pressure.
• Tell me about a time you simplified a complex process.
• Tell me about a time you had to deal with ambiguity.
• Tell me about something you are proud of.
• Tell me about a project that didn't go the way you wanted.

Technical

• How would you troubleshoot a server that does not power on?
• How would you troubleshoot a server that does not POST?
• A server has 12 DIMM slots but only 6 are recognized. What do you do?
• What is IPMI / BMC?
• Explain OSI Layers 1, 2, and 3.
• What is DHCP? What is DNS?
• What is the difference between a switch and a router?
• How would you troubleshoot no network connectivity?
• What is a VFL?
• What is an SFP?
• How would you troubleshoot Layer 1? Layer 2?

Role Fit

• Are you okay with rotating shifts, weekends, and on-call?
• Are you comfortable with physical handling?
• What would you do if you didn't know the answer?
• What would you do if a senior told you to skip a runbook step?
• How would you prioritize three urgent tickets at once?

8. Questions to Ask the Interviewer

Do not skip this. Not asking questions is a red flag. Prepare at least four.

1. What does success look like for a new DCO technician after 3 to 6 months?
2. What are the most common tickets a new technician should master first?
3. How does the team balance speed, SLA pressure, and safety when they are in tension?
4. How is training structured for new technicians?
5. What mistakes do new technicians most commonly make?
6. What separates a good DCO technician from a great one after the first year?
7. What does great ticket documentation look like here?

9. What Not to Say

Instead of this	Say this
"That's not my job."	"I own the quality of the handoff."
"I just escalated it."	"I escalated with full documentation of what I'd already tested."
"I'd try parts until it works."	"I'd isolate one variable at a time, following the runbook."
"I prefer not to work nights."	"I understand this is 24/7 and I'm ready for rotating shifts."
"I don't know." (and nothing else)	"I don't know that yet — I'd check the runbook, ask a senior, and learn it properly."
"I've never failed."	(Use a real failure story. Every interviewer knows this answer is false.)
"We did..."	"I did..." — Amazon interviewers want individual evidence.

10. The Honest Lesson

I prepared for four days before the interview. That was not enough for this role.

The technical part is not impossible — if your background is in engineering or support, you can handle it. But the behavioral side and the story quality matter just as much, maybe more. My stories were not strong enough in the result part, and that cost me.

If you are preparing for AWS DCO:

• Start at least 2 weeks out.
• Practice stories out loud, not just in your head.
• Treat the behavioral section as the main event.
• Make every story end with a concrete, specific result.
• If you use AI tools to prep — use them for bullet points and structure, not as a replacement for actually knowing your material.

Good luck. The interview is fair. The process is transparent. You just need to actually prepare for it.

1. I interviewed for an AWS DCO role in Berlin and got rejected.
2. Fair enough. The interview was way more serious than I expected.
3. I started preparing only 4 days before, which in hindsight was basically me showing up to a marathon with one energy drink and a dream.

What I learned

• This was not a normal interview.
• It was about 20–30% technical and the rest was basically:
  • Leadership Principles.
  • STAR stories.
  • Psychology.
  • How you think under pressure.
• The interview was around 2 hours, which is long enough to make you question your life choices halfway through.

What actually mattered

1. Technical basics mattered, but not in some super advanced way.
2. I finished electrical engineering 15 years ago, so I was not walking in with fresh hands-on experience.
3. The technical part was manageable, but the real challenge was the storytelling.
4. My stories were a bit weak.
5. I could explain what happened, but I did not always close the story strongly enough with a clear result.
6. That matters a lot more than I expected.

What I prepared

• I had multiple docs for the important stuff:
  • Introduction.
  • Data center equipment.
  • Support spaces.
  • Power and electrical basics.
  • Security and fire protection.
  • Amazon Leadership Principles.
  • Interview questions.
  • Story prep.
• That helped a lot, but it still was not enough because I did not prepare early enough or practice enough out loud.

What the interviewer was like

• Calm.
• Professional.
• Guided me through the questions.
• Not hostile at all.
• Honestly, it felt like he was trying to help me hit the right points.

My honest takeaway

• If you are preparing for AWS DCO, do not focus only on technical knowledge.
• You need:
  1. The basics of hardware, networking, Linux, RAID, BIOS/UEFI, POST, and troubleshooting.
  2. Strong STAR stories.
  3. Clear results in your stories.
  4. A good understanding of Amazon Leadership Principles.
  5. More prep time than I gave it.

If I had to do it again

• I would start earlier.
• I would rehearse my stories out loud more.
• I would make the result part of every story much stronger.
• I would treat the behavioral side like the main event, because it basically was.

If anyone is going for AWS DCO, my advice is simple: don’t wing it.
This interview is less “do you know what a server is” and more “can you think like someone who belongs in a data center without panicking.”

1. I interviewed for an AWS DCO role in Berlin and got rejected.
2. Fair enough. The interview was way more serious than I expected.
3. I started preparing only 4 days before, which in hindsight was basically me showing up to a marathon with one energy drink and a dream.

What I learned

• This was not a normal interview.
• It was about 20–30% technical and the rest was basically:
  • Leadership Principles.
  • STAR stories.
  • Psychology.
  • How you think under pressure.
• The interview was around 2 hours, which is long enough to make you question your life choices halfway through.

What actually mattered

1. Technical basics mattered, but not in some super advanced way.
2. I finished electrical engineering 15 years ago, so I was not walking in with fresh hands-on experience.
3. The technical part was manageable, but the real challenge was the storytelling.
4. My stories were a bit weak.
5. I could explain what happened, but I did not always close the story strongly enough with a clear result.
6. That matters a lot more than I expected.

What I prepared

• I had multiple docs for the important stuff:
  • Introduction.
  • Data center equipment.
  • Support spaces.
  • Power and electrical basics.
  • Security and fire protection.
  • Amazon Leadership Principles.
  • Interview questions.
  • Story prep.
• That helped a lot, but it still was not enough because I did not prepare early enough or practice enough out loud.

What the interviewer was like

• Calm.
• Professional.
• Guided me through the questions.
• Not hostile at all.
• Honestly, it felt like he was trying to help me hit the right points.

My honest takeaway

• If you are preparing for AWS DCO, do not focus only on technical knowledge.
• You need:
  1. The basics of hardware, networking, Linux, RAID, BIOS/UEFI, POST, and troubleshooting.
  2. Strong STAR stories.
  3. Clear results in your stories.
  4. A good understanding of Amazon Leadership Principles.
  5. More prep time than I gave it.

If I had to do it again

• I would start earlier.
• I would rehearse my stories out loud more.
• I would make the result part of every story much stronger.
• I would treat the behavioral side like the main event, because it basically was.

If anyone is going for AWS DCO, my advice is simple: don’t wing it.
This interview is less “do you know what a server is” and more “can you think like someone who belongs in a data center without panicking.”

1. I interviewed for an AWS DCO role in Berlin and got rejected.
2. Fair enough. The interview was way more serious than I expected.
3. I started preparing only 4 days before, which in hindsight was basically me showing up to a marathon with one energy drink and a dream.

What I learned

• This was not a normal interview.
• It was about 20–30% technical and the rest was basically:
  • Leadership Principles.
  • STAR stories.
  • Psychology.
  • How you think under pressure.
• The interview was around 2 hours, which is long enough to make you question your life choices halfway through.

What actually mattered

1. Technical basics mattered, but not in some super advanced way.
2. I finished electrical engineering 15 years ago, so I was not walking in with fresh hands-on experience.
3. The technical part was manageable, but the real challenge was the storytelling.
4. My stories were a bit weak.
5. I could explain what happened, but I did not always close the story strongly enough with a clear result.
6. That matters a lot more than I expected.

What I prepared

• I had multiple docs for the important stuff:
  • Introduction.
  • Data center equipment.
  • Support spaces.
  • Power and electrical basics.
  • Security and fire protection.
  • Amazon Leadership Principles.
  • Interview questions.
  • Story prep.
• That helped a lot, but it still was not enough because I did not prepare early enough or practice enough out loud.

What the interviewer was like

• Calm.
• Professional.
• Guided me through the questions.
• Not hostile at all.
• Honestly, it felt like he was trying to help me hit the right points.

My honest takeaway

• If you are preparing for AWS DCO, do not focus only on technical knowledge.
• You need:
  1. The basics of hardware, networking, Linux, RAID, BIOS/UEFI, POST, and troubleshooting.
  2. Strong STAR stories.
  3. Clear results in your stories.
  4. A good understanding of Amazon Leadership Principles.
  5. More prep time than I gave it.

If I had to do it again

• I would start earlier.
• I would rehearse my stories out loud more.
• I would make the result part of every story much stronger.
• I would treat the behavioral side like the main event, because it basically was.

If anyone is going for AWS DCO, my advice is simple: don’t wing it.
This interview is less “do you know what a server is” and more “can you think like someone who belongs in a data center without panicking.”