Tell me about yourself in an IT interview: structure, examples and behavioural answers

What the interviewer is listening for

"Tell me about yourself" is three questions at once: why IT, why this job, and can you explain yourself clearly to a stranger. The third matters more in IT than in most fields. The Bureau of Labor Statistics lists communication, customer service, listening and problem-solving as important qualities for computer support specialists, and says they must describe solutions in a way nontechnical users can understand. Your answer is the first sample of that skill the interviewer hears.

For a career changer, the interviewer is also checking a risk. Someone who left retail, the military or logistics might leave IT just as quickly, or might have taken a certification because a video said it was easy money. A good answer removes that doubt by showing a planned move with evidence behind it: what you did, what you built or fixed, and why this role is the logical next step.

The good news is that BLS lists "none" as the related work experience typically needed for computer support specialists, and says candidates may qualify with a high school diploma plus relevant IT certifications.

Present, past, future, in about a minute

The University of Wisconsin-Madison Career Center recommends a Present, Past, Future model for this question: where you are now, where you have been, and where you are going. It fits IT interviews well, with one adjustment for career changers: the present should include the IT work you are doing now, even if it is unpaid.

• Present: your current job in one sentence, then the IT work you have done recently. Certification, home lab, volunteer support, the tech problems you became the go-to person for at work.
• Past: the part of your previous work that this job uses. Customer conversations, troubleshooting under pressure, following procedures, documenting what happened.
• Future: why this role, at this company, is the next step. Name something specific about the team or the work.

On length, there is no proven ideal. The Muse notes that coaches recommend anything from 30 seconds to two minutes, and a career counsellor quoted by the University of Arizona's Eller College caps the answer at two minutes. Aim for 60 to 90 seconds, roughly 150 to 220 spoken words. That is long enough for three parts and short enough that the interviewer can pick a thread to follow up on, which is what you want.

Write it out, then say it aloud with a timer, then stop reading it. A memorised answer sounds memorised. Know the three parts and the key sentence in each, and let the wording vary.

Where the certification goes in the answer

Do not open with it. "I am CompTIA A+ certified" as a first sentence tells the interviewer something they already read on your resume, and it implies the certificate is your main qualification, which invites the question of what else you have.

Put it in the present part, as evidence that the move is planned, and attach it to something you did with it:

• Weak: "I have my A+ and Network+."
• Better: "Over the last year I earned A+ and Network+, and I set up a small Active Directory lab at home to practise the account and permission problems help desks see every day."

The second version answers the follow-up before it is asked. A lab you built is also easier to talk about well than an exam you passed.

Leave out exam domains and scores. And if you are still studying, say so plainly with a date: "I sit Security+ in November". Interviewers check, and a vague claim costs more than a clear "not yet". The resume side of this is covered in how to list certifications on a resume.

Three example answers

These are illustrations written for this guide, not transcripts from real candidates. Use the shape, not the words.

"Right now I am a shift supervisor at an electronics store, and for the last couple of years I have been the person staff come to when the point-of-sale terminals or the handheld scanners stop working. That pushed me to study properly, and this year I passed CompTIA A+ and set up a home lab where I practise password resets, mapped drives and printer issues in a Windows domain. Before supervising I spent three years on the sales floor, which mostly meant calming people down and working out what they actually needed, often from a vague description. That is a lot of what a help desk call is. I am applying here because your service desk supports clinics, and I like the idea of work where getting someone back online quickly actually matters to patients. I would like to start on the phones, learn your ticketing system well, and grow into desktop support."

"I graduated in May with a business information systems degree, and since then I have focused on cloud. I passed AWS Certified Solutions Architect - Associate in August, and to make it real I built a small serverless app that tracks my student society's equipment loans, using Lambda, DynamoDB and API Gateway, with the whole thing documented on GitHub. At university the most useful job I had was in the campus IT lab, where I reset accounts and imaged lab machines, which taught me that most problems are permissions or something someone changed yesterday. I am interested in this cloud support role because your team supports customers moving workloads into AWS, which is the work I enjoyed most in my project, and I would rather learn it handling real customer issues than in a sandbox."

"I am finishing eight years in the Army as a signal support specialist, keeping radios and network equipment running for a battalion. I earned CompTIA Security+ last year because my role required it, and the part I found myself enjoying was the security side: monitoring, access control, working out what changed when something broke. Since then I have built a home lab with a SIEM and practised triaging alerts from simulated phishing campaigns. The military taught me to follow procedures exactly, document every step, and stay calm when something fails at a bad time, which is what a SOC shift looks like. I am applying for this Tier 1 analyst role because you support defence contractors, so the security frameworks I already know apply here, and I want to build my detection skills on a team that does it every day."

Behavioural questions IT interviewers ask, answered with STAR

After the opening, most IT interviews move to behavioural questions: "Tell me about a time...". UW-Madison's career centre recommends the STAR method to keep these answers focused: Situation (the context), Task (what you needed to do), Action (what you did), Result (the outcome and what you learned). Spend most of the time on Action, say "I" rather than "we", and end with a result you can name. Career changers can and should use stories from non-IT jobs; the skill is what is being tested.

The interviewer is testing honesty and method. A help desk technician who bluffs causes more damage than one who escalates. Describe a specific problem you could not solve, how you said so to the person, what you did to find the answer (documentation, a colleague, a knowledge base), and how you followed up. Close with what you now do differently, such as writing the fix into a note for next time.

This tests patience and the BLS's customer-service quality directly. Pick a case where the person was upset for a reason. Show that you listened first, restated the problem, set a realistic expectation, and kept them informed. The result should include how the person ended the conversation, as well as whether the issue was fixed.

Choose a real mistake with a real consequence, not a disguised strength. In IT terms, a change you made without checking, or a step you skipped. Show that you reported it quickly, helped fix it, and changed your process. Interviewers hiring for support and security roles care most about the reporting, because hidden mistakes are the expensive ones.

New hires spend their first months learning the employer's tools. Use a story with a deadline: a new system at work, a certification domain you found hard, a project that needed a skill you lacked. Name the resources you used and how you checked you had learned it. Your certification study can fit here if you describe the method, not the pass.

This is part behavioural, part process. A strong answer weighs impact (how many people are affected) against urgency (how soon it hurts the business). A server down for a whole office outranks one user's slow laptop, even if the laptop ticket arrived first. Then give a real example of making that call, and mention how you told the waiting user when they would hear back.

The interviewer wants to know whether you stay methodical when something is on fire. Pick a moment with a clock: an outage, a rush period, a deadline. Describe how you broke the problem into steps, what you communicated and to whom, and what you did afterwards to stop it recurring.

This tests whether you can disagree without damage. Describe a disagreement about how to do something, not a personality clash. Show that you made your case with evidence, listened to theirs, and accepted the decision or found a compromise. If you turned out to be wrong, say so; it makes the story believable.

This is the BLS communication quality in question form. Pick an example where you had to change your explanation because the first version did not land: a relative setting up a router, a coworker learning a new system. Show how you checked understanding, for example by asking them to try the steps while you watched.

Career changers will hear this, sometimes inside the opening question. Answer with a pull, not a push: what drew you to the work, the evidence that you have already been doing some of it, and the steps you took. Never criticise your old field or employer. "I found I enjoyed fixing the systems more than selling around them" is a better answer than any complaint.

Build a story bank before the interview

You do not need a different story for every question. Six to eight well-prepared stories cover most behavioural interviews, because each story can answer several questions depending on which part you emphasise. A night when the store's card terminals failed can be a pressure story, a difficult-customer story or a prioritisation story.

Write each story as four short lines, one per STAR letter, with a number or a concrete result in the last line where you have one. Then map them against the questions above and look for gaps. Most career changers find they are short of a mistake story and a disagreement story, because those are the ones people avoid thinking about.

Practise aloud with someone who will interrupt you. Real interviewers cut in with "what did you do next?", and an answer that only works uninterrupted falls apart.

Questions to ask at the end

UW-Madison's career centre notes that the final 10 to 15 minutes of an interview are usually for your questions, and recommends preparing at least five. For IT roles, good questions show you are already picturing the work:

• What does a typical day or shift look like for someone in this role in their first three months?
• How are tickets escalated, and what does Tier 1 own end to end?
• Which tools does the team use for ticketing, remote support and documentation?
• How do you measure whether someone in this role is doing well?
• What have people in this role moved on to inside the company?
• Is there a training budget or support for certifications?

The same career centre advises leaving salary for after an offer, and generic benefits questions for later too. When the offer does arrive, negotiating an entry-level salary covers what to say.