Systems Engineer

Uses the log viewer already built into your operating system. Nothing to install.

1. 1

   Open the record

   Your machine has been writing down what it does, continuously, for as long as you have owned it. Most people never look.

   Windows

   eventvwr.msc  →  Windows Logs  →  System

   macOS

   Console.app  →  select your Mac under Devices

   Linux

   journalctl -b --no-pager | less

2. 2

   Find yourself in it

   Locate the moment you logged in this morning. Note the exact timestamp and the event id. You have just done the core move of every investigation: anchoring to one known event so everything else can be measured against it.

   Windows

   Security log → filter Event ID 4624 (successful logon)

   Linux

   journalctl -b | grep -i "session opened"

3. 3

   Establish what normal looks like

   Scroll a full day. Find three things that happen every single day at roughly the same time — an update check, a backup, a scheduled task. Write them down. This is baselining, and it is the skill that separates people who spot a real intrusion from people who chase noise for a year.

4. 4

   Find the one that only happened once

   Now look for something that appears exactly once in the last week. A driver failure, an unexpected shutdown, a service that crashed. Read the surrounding twenty entries either side. Can you tell a story about what happened, and what happened next as a consequence?

5. 5

   Write the timeline

   Pick five events, put them in order with timestamps, and write three sentences explaining what occurred. Show it to someone non-technical. If they understand it, you have just done the part of security work that most people are worst at — the writing, which is what actually gets acted on.

PowerShell ships with Windows; bash ships with macOS and Linux. You already have everything you need.

1. 1

   Pick a real chore

   Not a toy problem — something that genuinely annoys you. Sorting a Downloads folder full of four hundred files. Renaming photos to a consistent format. Finding every file over 500MB. It has to be real, or the payoff at the end will not land.

2. 2

   Do it by hand once, and time it

   Actually time it. Write the number down. This is the figure you are going to beat, and it is also how you will one day justify automation work to a manager who wants to know why it is worth your afternoon.

3. 3

   Make a copy to work on

   Duplicate the folder. Everything from here runs against the copy. This is not caution for beginners — it is what people do professionally, because the cost of being wrong is asymmetric.

   Windows

   Copy-Item -Path .\Downloads -Destination .\Downloads-copy -Recurse

   macOS

   cp -R ~/Downloads ~/Downloads-copy

   Linux

   cp -R ~/Downloads ~/Downloads-copy

4. 4

   Ask what it WOULD do, before it does anything

   Run the operation in preview mode first. Nothing changes; it just tells you what it intends. Read that output properly. This habit is the single biggest difference between someone safe to give automation to and someone who is not.

   Windows

   Get-ChildItem .\Downloads-copy -File | Group-Object Extension | Format-Table Name, Count

   macOS

   find ~/Downloads-copy -type f | sed "s/.*\.//" | sort | uniq -c | sort -rn

   Linux

   find ~/Downloads-copy -type f | sed "s/.*\.//" | sort | uniq -c | sort -rn

5. 5

   Now let it run

   Sort every file into a folder named after its extension. Five lines or so. It will not work first time — read the error, change one thing, run it again. That loop, repeated, is the actual job.

   Windows

   Get-ChildItem .\Downloads-copy -File | ForEach-Object { $d = ".\Downloads-copy\" + $_.Extension.TrimStart("."); New-Item -ItemType Directory -Force -Path $d | Out-Null; Move-Item $_.FullName $d }

   macOS

   cd ~/Downloads-copy && for f in *.*; do d="${f##*.}"; mkdir -p "$d"; mv "$f" "$d"/; done

   Linux

   cd ~/Downloads-copy && for f in *.*; do d="${f##*.}"; mkdir -p "$d"; mv "$f" "$d"/; done

6. 6

   Compare it to your number

   You wrote down how long it took by hand. It now takes under a second, and it will take under a second every time from now on. Sit with that for a moment — that gap, multiplied across an organisation, is the entire economic argument for automation as a career.

One free single-file download (Terraform). No account, no cloud provider, no credit card, and nothing here can cost you money — you will be creating files on your own disk, not servers. Delete the binary afterwards if you like.

1. 1

   Get the tool

   Download Terraform from terraform.io — it is a single executable. Put it somewhere on your PATH, or just work in the folder you downloaded it to. Check it runs.

   Any

   terraform -version

2. 2

   Describe something that does not exist yet

   Make a new empty folder and create a file called main.tf. You are not writing instructions here — you are describing a desired end state, and that distinction is the whole idea.

   Any

   terraform {
     required_providers {
       local = { source = "hashicorp/local" }
     }
   }
   
   resource "local_file" "hello" {
     filename = "${path.module}/out/hello.txt"
     content  = "built by terraform\n"
   }

3. 3

   Ask what it WOULD do

   Initialise, then run a plan. Read the output properly. It tells you exactly what will be created, changed or destroyed, and nothing has happened yet. This preview-before-acting habit is most of what separates infrastructure people who are safe from ones who are not.

   Any

   terraform init
   terraform plan

4. 4

   Make it real

   Apply it. Look in the out/ folder — the file exists. Now run plan again: it reports no changes, because reality already matches your description.

   Any

   terraform apply
   terraform plan

5. 5

   Break reality and watch it notice

   Delete the file it made, by hand. Run plan again. It has detected drift — reality no longer matches the description — and it tells you precisely how to get back. Apply again and it repairs itself. This is the moment the idea usually lands.

   Any

   terraform plan
   terraform apply

6. 6

   Add three more, then destroy everything

   Change the resource to create three files instead of one using count = 3. Plan, apply. Then run destroy: everything it made is gone, and only your description remains. You can rebuild it identically, forever, from four lines of text. That property is what the whole cloud industry is built on.

   Any

   terraform destroy

Needs one other person who is not technical, and a real problem they actually have. That is the only requirement, and it is the hard part.

1. 1

   Find a real complaint

   Ask a family member, housemate or friend what annoys them about their computer or phone. Do not accept a technical description — you want the raw version. "It's slow." "The printer never works." "It keeps logging me out." That vagueness is the actual starting condition of the job.

2. 2

   Resist fixing it for ten minutes

   This is the discipline the whole trial is built around. Ask questions instead. When did it start? What changed around then? Does it happen every time, or sometimes? Show me. Watch them do it — you will almost always see something they did not mention, because they did not know it mattered.

3. 3

   Reproduce it yourself

   Make the problem happen on demand, with your own hands. If you cannot reproduce it, you cannot know you have fixed it — you can only know it has stopped happening for now, which is not the same thing and will come back.

4. 4

   Halve the problem, repeatedly

   Is it that app or all apps? That network or all networks? That account or all accounts? Each answer eliminates half of what it could be. Keep going until only one thing is left. Notice how few questions this actually takes when you choose them well.

5. 5

   Fix it — then explain it without jargon

   Make the fix. Then tell them what was wrong in language they understand, without being condescending and without pretending it was harder than it was. Watch their face. This skill is worth more to an early IT career than any certification, and almost nobody practises it deliberately.

6. 6

   Write the runbook

   Five lines: the symptom, how to confirm it is this and not something else, the fix, and how to tell it worked. Written so someone else could follow it at 3am without ringing you. This is the artefact that turns a fix into an asset.

A spreadsheet is enough — Excel, Numbers, or free LibreOffice. There is an optional SQL path at the end if you want it. No account needed.

1. 1

   Get something real and unhelpful

   Download a CSV from a public data portal — data.gov.uk, data.gov, or your national statistics office. Pick a subject you actually care about: crime near you, rainfall, energy prices, hospital waiting times. Deliberately do not pick a tutorial dataset. Real data is messy, and the mess is the job.

2. 2

   Write your question down before you look

   One sentence, on paper, before you open the file. "Has burglary in my area gone up or down over five years?" Doing this first is what stops you finding whatever the data happens to show and calling it a finding afterwards.

3. 3

   Meet the mess

   Open it. Find the problems: blank cells, dates in three formats, a total row hiding at the bottom that will corrupt every average you take, categories renamed halfway through the period. Write a list of every defect you find before you fix any of them.

4. 4

   Clean it, and keep a record of what you changed

   Fix the defects — but write down each decision as you go. "Dropped 214 rows with no date." "Treated blank as zero." Those decisions change the answer, and being unable to say what you did to the data is the difference between analysis and guessing.

5. 5

   Answer the question

   Pivot table, chart, or a formula. Get to a number. Then do the part almost everyone skips: try to disprove it. Is the trend just one anomalous year? Did the collection method change? Would a different but equally reasonable cleaning decision have flipped the result?

   Any

   Optional SQL path — sqlite3 ships with macOS and Linux:
   
   sqlite3 data.db
   .mode csv
   .import yourfile.csv t
   SELECT year, COUNT(*) FROM t GROUP BY year ORDER BY year;

6. 6

   Say it in three sentences

   What you found, how confident you are, and what it does not tell you. Show it to someone who has not seen the data. If they ask a question you cannot answer, that is not a failure — that is you discovering the limit of your own finding, which is the most valuable output of the whole exercise.

Uses the account settings pages you already have. Nothing to install. You will likely also improve your own security materially, which is a decent side effect.

1. 1

   Find the account that owns all the others

   Start at your main email. Now list every service that would send a password reset there. That is not a list of accounts — it is a list of things someone gets for free the moment they take that one. Security people call this blast radius, and it is the single most useful concept in identity work.

2. 2

   Check what is actually guarding it

   Look at the security settings of that email account. Is there a second factor? Is it SMS — which is interceptable — or an app or hardware key? Now check the recovery options: an old phone number or a disused backup address is a back door that bypasses everything else you just checked.

3. 3

   Review what you have handed out

   Find the third-party access page on your Google, Microsoft or Apple account — the list of apps you signed in to using it. Most people have twenty to eighty entries and recognise perhaps half. Read what each was granted. Some will have read access to your entire mailbox from a service you used once in 2019.

   Any

   Google:    myaccount.google.com/permissions

   Any

   Microsoft: account.microsoft.com/privacy → apps and services

   Any

   Apple:     appleid.apple.com → Sign in with Apple

4. 4

   Revoke, and notice how that feels

   Remove everything you do not currently use. Notice the hesitation — "what if something breaks?" That exact hesitation, multiplied across ten thousand employees and twenty years, is why organisations accumulate permissions nobody dares remove. You are feeling the central problem of identity engineering firsthand.

5. 5

   Check the sessions still open

   Most services list active sessions and signed-in devices. Look for a device you no longer own or a location you do not recognise. Sign them all out. Note how many services do not offer this at all — that absence is itself a finding.

6. 6

   Write the one-page assessment

   What is your most valuable account? What is the weakest path into it — is it the password, the second factor, the recovery method, or an app you granted access to years ago? What would you fix first if you had one hour? That prioritised write-up is exactly the deliverable an identity or GRC role produces, and doing it for yourself is the cheapest possible practice.

Built-in wireless tools plus your own feet. The optional hardware section needs a computer you own and are willing to open — no purchase required.

1. 1

   Measure what you have been assuming

   Find your current signal strength, right now, where you are sitting. Note the number and the units — dBm is a negative figure where closer to zero is better, and −50 is excellent while −80 is barely usable.

   Windows

   netsh wlan show interfaces

   macOS

   Hold Option, click the Wi-Fi menu — or open Wireless Diagnostics from Spotlight

   Linux

   iw dev wlan0 link    # or: nmcli -f IN-USE,SSID,SIGNAL,CHAN dev wifi

2. 2

   Walk the building and write numbers down

   Take a reading in every room, and at the far corner of each. Write them on a rough floor plan. You are producing a coverage survey — the same artefact, at smaller scale, that a wireless engineer produces before a hospital or a warehouse deployment.

3. 3

   Find the wall that eats your signal

   Look for the sharp drop, not the gradual fade. A gentle decline is distance; a cliff between two adjacent readings is something physical — a wall with foil-backed insulation, a mirror, a boiler, a fridge, a chimney. Go and identify the actual object. This is the moment radio stops being theoretical.

4. 4

   Discover you are not alone on the air

   List the networks around you and the channels they occupy. Count how many are on the same channel as yours. Wi-Fi is a shared medium in a public commons — your neighbour's router degrades yours, and no configuration on your side can fully fix it. That constraint is the defining fact of wireless work.

   Windows

   netsh wlan show networks mode=bssid

   Linux

   nmcli -f SSID,CHAN,SIGNAL dev wifi list

   macOS

   Wireless Diagnostics → Window → Scan

5. 5

   Trace one cable end to end

   Pick any cable in your home — the one from the wall to the router. Follow it physically to both ends. Where does it enter the building, and what is on the other side of that wall? Almost nobody knows. Documenting exactly this, across a building, is a real job that real people are paid to do because the records are always wrong.

6. 6

   Optional — open something and name every part

   Power off, unplug, ground yourself, then open a desktop or an old laptop you own. Identify: the processor and its cooler, the memory, the storage, the power supply, the fans. Trace where the air enters and leaves. Ask where the heat goes. Now imagine ten thousand of these in one room — that question of heat, power and airflow is most of what data centre design actually is.