Following a recent interview which went, ok, but, not so ok at the same time, I have since come away from that day with a clear objective to ensure that my fundamental IT knowledge and skills, are up to scratch. To ensure that I never ever have to come away from an interview again telling myself, "my fundamentals weren't fundamental enough..", I went about looking for similar '100 things..' out on the web. Whilst I came across a few, none of them really felt very rounded, either being too heavy on hardware, networking, software, etc.
I was wondering whether anyone would be interested in contributing to this post, and helping to carve out a solid list of things that every IT tech should know. I'm working on the basis of a technician that has been in their role for 4-5 years - not to discriminate against those clever bods out there that might be fit for a network/sysadmin position within their first 2 years or so of an IT career, but mainly the fact that 4-5 years is enough time to have gained exposure to many areas of administration.
I should add that I thought it best to base the list around Windows operating systems, where specific software procedures may feature.
If however, this idea has already been followed up in the past, or that the good majority of folk believe this to be a poorly-conceived idea, don't hesitate to tell me whether this is a waste of time!
Last edited by MrJDH; 20th May 2014 at 10:30 PM.
You only need one for IT in schools, I'd it has a plug, it's yours :-D
This is really difficult to answer as every JD differs and the basics for one role will be different to another. There is no substitute for reading the JD thoroughly and asking on here if you are not sure how to interpret part of it.
Knowledge of AD and GPO may be needed, but it may not ... and if it is, then the depth of knowledge will depend on the job. Every employer would like you to have detailed knowledge of lots of things, but what they get is best fit for the role from those who apply. Another day, your fundamentals may have been good enough!
What is needed is a good working knowledge of the basic problems that affect most departments... printer jams, mains power switches, understanding the operating systems of the client hardware from the user's point of view. After that, knowing where to get the knowledge you need fast... google and edugeek for example... is important.
While I do agree with @elsiegee40 that each job description will have differing requirements and the most important thing any applicant can do is read it thoroughly and match their skills and experiense to it, I also think @MrJDH is on to something. There must be certain basic skills and knowledge common to all IT Techs. If anywhere could come up with a top 100 list I'm sure Edugeek can...
I'll start with a few ideas:
- Basic problem solving. The ability to break down a problem into a series of steps that will ultimately lead to a solution. A bit abstract, but methodical thinking skills is probably the single biggest, key, requirement of the job -IMHO.
- Names and functionality of basic components. Do you know what the Motherboard is? Hard Drive? CPU? RAM? Can you confidently walk into PC-World and match the specification to a users requirements?
- Software knowledge. Can you install and OS and drivers from scratch on bare hardware? (no manufacturers restore disks). How well do you know your way around the Windows control panel and the various setting there? How confident are you in using MS Office? Especialy Publisher, Powerpoint and Excel?
- Basic networking. TCP/IP? DHCP? DNS? Domain Controllers? Default Gateway? Understanding how these function and why they are important, from the client side, is essential.
- Where to find the answers. Google, Edugeek, Peers. Never be afraid to ask for help.
In a school environment you may want add things like:
- Child protection
- Lesson/Timetable structure
- Management Information Systems
For someone looking to move on/up after 4-5 years, I think alot will be networking based:
- Server installation
- Storage management
- Active Directory
- Switch configuration
- bit of SQL and scripting
I think that's it from the top of my head. No doubt lots more I haven't thought of...
mac_shinobi (21st May 2014)
Always verify the fault ! Never ever take whatever is said to you as gospel.
hallb15 (21st May 2014)
1. How to make a decent brew.
1) When troubleshooting a recalcitrant bit of equipment always make sure you
switch it off
wait 30 seconds
& switch it back on
People laugh but it clears an amazing array of faults
2) Believe in your super powers. Just arriving in a room mysteriously fixes many faults - no end of times Ive heard the wail "it wasnt working before honest"
I'd +1 tmcd and add
* Prioritisation - This was one of the things we looked for when interviewing for technicians. More often it was being able to reason, sensibly, why you had chosen the priorities you had.
* Communication - What do you tell people, when do you tell people and how do you tell people. We work in a very acronym and convoluted terminology laden area so can we get these ideas across. Work on popular terms so you have some stock answers (what is the cloud? What is AJAX? What is CSS? etc) but also practise breaking down terms and putting them across to people in simple terms.
* Customer Service - I'm going to get grief for this one and it is part of Communication but more and more we are having to placate numbers of people who are upset and irate for a seemingly tiny issue but it is major to them. Being the typical gruff anti-social IT guy doesn't always cut it so think about how to deal with interesting characters, training issues, plain stupidity. Sticking your tongue behind your bottom lip and going NERRRRRRGGGGHHHHH, may often seem the correct answer but often not well received. I was asked in the interview for my current job how I think the IT department should work in a school & I responded with like ninjas. Some confused looks on their faces until I explained that we woudl hope to fix things before they became a major issue and resolve issues around staff so they hadn't noticed we were there. In and out without any realising except things work better. They loved it. I'm really annoyed as I forgot the soundbite style snippet I said that one of the interviewers laughed at and wanted to make into an IT slogan for his door.
Also add to the problem solving point my new mantra I picked up from talesfromtechsupport, "a problem isn't solved until it is fully tested".
Add to the basic networking some older terms that may not necessarily be in use or popular but may be a hang over from an older interview or be there to see how broad your knowledge is. Things like CSMA/CA, tokens etc. Don't have to know them intimately but be able to give a meaning or usage.
Ouch, it took my brain a full 30sec to remember what CSMA/CA stood for. Why would someone be that cruel at interview?Add to the basic networking some older terms that may not necessarily be in use or popular but may be a hang over from an older interview or be there to see how broad your knowledge is. Things like CSMA/CA, tokens etc.
To get a list for this which could be updated as new things appear and old techs die out would be a really good idea. Not only for applying for new jobs, but to ensure that we can keep up to date in the role we are doing now. I say this as I have been wondering recently what areas I'm falling behind in as I do less of some things and more of others.
Anyway, to add I would say Imaging & Software deployment.
Personally speaking, as someone who's done the requisite five years and interviewed for technicians a couple of times now: I don't give a monkey's about theoretical checklists, like being able to name the FSMO roles and list the seven layers of the OSI model. When I interview, I'm chiefly looking for: methodical approach to problem solving (check the cables, check another computer with that user, check another user on the problem computer); prioritisation (ignore the Head complaining about his printer if there's a class that can't teach); and communication (spelling and grammar errors in your CV means you probably don't get to interview).
All of which is to make the point that while things like the seven layer model are useful to have on the list -as a tech, you should be familiar with it - the list shouldn't be something to learn by rote. I can't recite the 7 layers, but I know when I need to look them up.
Practically speaking, I reckon the list wants things like:
* Getting to Event Viewer and looking through it (took me an embarassingly long time to find this)
* Running ipconfig /all
* What a default gateway is, what a subnet mask is
* What DNS is and some quick troubleshooting to pin it down as the cause of a problem
* What DHCP is and some quick troubleshooting to pin it down as the cause of a problem
* How permissions work
* How share permissions work, and differ from NTFS permissions
* Running chkdsk
* Clearing a profile in Win7+
* Finding a file from temporary internet files when someone has opened (not saved) a file from their webmail then worked on it
* Setting up a local user for someone going offsite
* Using .\ at the logon screen to quickly see the name of a computer (as shorthand for computername\username)
and general little details like that. They show a familiarity with an OS and, if you don't know them, would lead you down a garden path of discovery.
1. Fully document everything. You will probably never need it, but if you do, it will be a god-send. This simple approach has saved my bacon many times.
2. Formalise every procedure and always follow the process.
3. Always test something before you put it live or better yet, get somebody else to test it. When it has gone live, test it again.
The list is good:
I would add;
* Gpresult /r in cmd for checking if gpos have applied.
* Gpupdate /force for forcing policies to update.
* How to robo copy using .bat files.
* Common errors like "Secure channel", "Trust relationship", and how to fix / diagnose them.
* how to pull & push images using MDT or equivalent.
* Understanding TPM chips and bitlocker. And the difference between hardware encryption & software encryption.
* Common hardware faults, like, why is the machine beeping at be at boot?
Just a few ideas...
ctrl + alt + up
left shift + alt + print scren
Last edited by AlexB; 21st May 2014 at 12:08 PM.
There are currently 1 users browsing this thread. (0 members and 1 guests)