All jobs / IT support / sysadmin

Scripting interview questions

Scripting questions a IT support / sysadmin can be asked, from first job to senior. Open one to see the strongest answer and why it works.

1. You can do the task in the console in two minutes. Why would anyone write a script for it?

   The strongest answer: Because it comes out the same every time, whoever is on shift can reuse it, and it leaves a record of what ran — which matters the moment it has to happen on forty machines

   Why it works: Exactly. Consistency, reuse and a record are the reasons; saved minutes are a side effect.

   • Same result every time.
   • Anyone on shift can reuse it.
   • It leaves a record of what ran.
   • Repetition is the test, not pride.

2. You have a PowerShell command that will act on every account matching a filter. How do you check it before it runs for real?

   The strongest answer: Run the filter on its own and read the list it returns, then use -WhatIf on the command that changes things so it prints what it would do, then run it against one test account first

   Why it works: Right. The filter is where the mistake usually is, and one test account catches what the preview cannot.

   • Check the filter before the action.
   • Read the list it returns.
   • Preview the change with -WhatIf.
   • Run one test account first.

3. A maintenance script carried on after a command failed and removed the wrong directory.

   What do you change about how you write them?

   The strongest answer: Make the script stop on an error and on an unset variable, make a pipeline fail when any stage fails, quote every variable that could hold a path, and check the target exists before acting on it

   Why it works: Right. Failing loudly and quoting paths are what stop an empty variable turning a cleanup into a disaster.

   • Fail loudly and early.
   • Stop on error and on unset variables.
   • Fail the whole pipeline.
   • Quote paths; check before you act.

4. An onboarding script stopped half-finished when the network dropped. The technician is about to run it again from the top.

   What should the script already do?

   The strongest answer: Check before it changes anything, skip what is already in place, and log what it did and did not do — so a second run finishes the job instead of creating a second mailbox and a duplicate group

   Why it works: Exactly. Check-then-change plus a log of what it skipped is what makes a half-finished run recoverable.

   • Check before you change.
   • Every step safe to repeat.
   • Log what was skipped and why.
   • There is no rollback to lean on.

5. A scheduled script on a server signs in with an administrator password written on line four.

   What do you change, and what do you do about the password that is already there?

   The strongest answer: Treat it as exposed: rotate it, give the script its own identity with least rights, and fetch the credential from a managed store at run time — and check history and backups, which still hold the old one

   Why it works: Right. Rotating first is what people skip, and the old copies in history and backups are why the exposure outlives the fix.

   • Assume it is already exposed.
   • Rotate first, then redesign.
   • Own identity, least rights, managed store.
   • History and backups still hold it.

6. The team’s automation lives in a folder on one technician’s laptop, runs under their own account, and nobody else knows which scripts still matter.

   What do you change?

   The strongest answer: A repository with an owner and review, run from a server under a service account with least rights, each script carrying a purpose and a review date — and anything nobody can explain gets switched off and watched

   Why it works: Right. Ownership, an identity that is not a person, and a way to retire the unexplainable — that is what turns scripts into a service.

   • Automation needs an owner.
   • Repository, review, stated purpose.
   • Run under a service identity.
   • Retire what nobody can explain.