Career Changer? Prove Problem Solving in a Tech Interview

James Walker

James Walker writes about career transitions. London-based career enthusiast.

Visual representation of the voice · not a photographic portrait

Quick answer: Think out loud on live problems, ask clarifying questions before answering, and tell two or three short stories from your past job where you found a cause, tried a fix, and checked the result. Interviewers grade how you break a problem down, not your job title.↗ Share on X

You show problem solving skills in a tech interview by thinking out loud on a real problem, asking clarifying questions before you start, and telling two or three short stories from your past job where you found a cause, tried a fix, and checked the result. You do not need tech experience for this. Interviewers are not grading your job title. They are watching how you break a messy problem into small steps. A teacher who fixed a broken grading process, a nurse who cut handoff errors, or a warehouse lead who sped up picking already has the raw material. The trick is to translate it into the language a tech interviewer listens for.

What are interviewers actually looking for?

READ ALSO11 Resume Tips That Get You Past the First Screening →11 Resume Tips That Actually Get You Interview Calls →5 Resume Fixes That Make a Hiring Manager Keep Reading →

When a hiring manager says "problem solving," they usually mean five habits. You can show every one of them without a single line of code on your resume.

Notice that none of these require a computer science degree. They require that you talk while you think. Most candidates go quiet, solve the problem in their head, and then announce an answer. The interviewer saw nothing. A career changer who narrates every step often beats an experienced candidate who stays silent.

How do you turn a non-tech job into a problem solving story?

Use a four-part story. Many people know it as STAR (Situation, Task, Action, Result). For career changers, a small twist works better: put most of your time on the Action part and describe it as a series of tests.

Here is the shape:

1. The problem in one sentence. Keep the setup short. "Our clinic kept losing patient referrals between the front desk and the specialists."

2. How you found the cause. This is where you prove you think like a tech person. "I pulled two weeks of referral slips and sorted them by who handled them. Almost all the lost ones came in on Fridays after 3 p.m."

3. What you tried, including what failed. "First I added a reminder sticky note. That did nothing. Then I set up a shared spreadsheet with a status column, and I checked it every Monday morning."

4. How you knew it worked. "Lost referrals dropped from about four a week to zero or one. The office manager kept the spreadsheet after I left."

Only use numbers you actually remember. If you do not know the exact figure, say "about" or describe the change in plain words: "We stopped getting complaint calls about it." Made-up numbers fall apart when the interviewer asks one follow-up question.

Three story examples you can adapt

Retail to IT support. "Our store's card readers kept freezing during the lunch rush. I noticed it only happened on the two registers near the back wall. I tested by swapping a reader from the front to the back, and it froze too. So it wasn't the reader. It was the spot. The Wi-Fi signal was weak there. I asked the manager to move the router closer, and the freezing stopped."

That is a textbook troubleshooting story: observe a pattern, form a guess, swap one thing at a time, confirm.

Teaching to data analysis. "Half my students were failing the same unit every year. I broke their test scores down question by question and saw they all missed questions that needed fractions, not the new topic itself. I added a 10-minute fraction warm-up for two weeks. The next test, far fewer students failed that unit."

This shows you can dig into data to find the real cause instead of the obvious one.

How do you handle a live problem when you don't know the answer?

READ ALSO5 Resume Fixes That Actually Get You More Interview Calls →5 Signs Your Resume Tips Are Hurting Your Job Search →5 Resume Mistakes That Send Your Application to the No Pile →

Many tech interviews include a question you cannot fully solve. That is on purpose. They want to see what you do when you are stuck. Follow these steps every time:

1. Repeat the problem in your own words. "So you want me to figure out why the website is slow for some users but not others. Is that right?"

2. Ask two or three clarifying questions. Who is affected? Since when? What changed recently? Questions are not a sign of weakness. In tech, asking the right question is half the job.

3. Say your first guess out loud. "My first guess is it's related to location, since only some users see it."

4. Explain how you'd test the guess. "I'd check if the slow users are all in one region. If yes, that points to the server or network. If not, I'd look at device or browser."

5. Admit what you don't know, then show how you'd find out. "I'm not sure how your servers are set up. I'd ask someone on the team or look at the monitoring tool first."

6. Wrap up with a next step. "So my plan would be: check location, then device, then recent changes. Whichever shows a pattern first, I'd dig into that."

Saying "I don't know, but here's how I'd find out" is one of the strongest answers a career changer can give. It shows you won't freeze or bluff on the job.

A sample exchange

Interviewer: "Our app's sign-up rate dropped last week. What would you do?"

Weak answer: "I'd probably redesign the sign-up page."

Strong answer: "A few questions first. Did it drop for everyone, or only on phones or only in one country? And did anything change last week, like a new release or a new ad campaign? If it dropped right after a release, I'd look at what changed in the sign-up flow. If it dropped only on one type of phone, I'd test sign-up on that phone myself. I'd want to find where people quit, which step, before changing anything."

The strong answer never names a fix. It shows the path to the fix. That is what gets scored.

What should you put on your resume before the interview?

Your resume sets up the stories. If it lists only duties ("answered phones," "managed inventory"), the interviewer has nothing to ask about. Rewrite at least three bullet points as small problem solving stories.

• Before: "Responsible for inventory management."
• After: "Found that most stock-outs came from one supplier's late deliveries; set up a weekly check-in that cut stock-outs." (Add your real numbers if you have them, or describe the result in plain words.)

Also add one small project that uses a tech tool, even a simple one. A spreadsheet that tracks something useful, a free online course project, or a short write-up of how you fixed a problem at home or at work. It gives the interviewer a bridge between your old field and the new one.

How should you practice in the next 14 days?

Reading about problem solving does not make you better at showing it. Speaking does. Here is a plan that fits around a full-time job.

Practice prompts for days 7 to 9:

• "Customers say our support emails take too long. How would you figure out why?"
• "A report that used to take 10 minutes now takes an hour. What do you check first?"
• "Two teams keep blaming each other for missed deadlines. How would you find the real cause?"

Do them out loud, even alone.

Which mistakes make career changers look weak?

1. Apologizing for your background. Opening with "I know I don't have tech experience, but…" frames you as a risk. Lead with the story instead. Let the interviewer connect the dots.

2. Telling stories with no ending. If you don't say how you knew the fix worked, the story feels unfinished. Always close with a result, even a simple one.

3. Jumping straight to a solution. On a live problem, the first sentence out of your mouth should usually be a question, not an answer.

4. Hiding failures. Mentioning the fix that did not work (like the sticky note above) makes your story more believable, not less. Real problem solving includes dead ends.

Your next step today

Take 20 minutes tonight and list six problems you solved at any job, one sentence each. Don't judge them yet. Tomorrow, pick the three with the clearest before-and-after and write them in the four-part shape: the problem, how you found the cause, what you tried, and how you knew it worked. Then record yourself telling the first one out loud. That single recording will show you more about what to fix than any article can.

FAQ

Can I use stories from a non-tech job in a tech interview?

Yes. Interviewers care about how you found a cause, tested a fix, and checked the result. A story from retail, teaching, healthcare, or a restaurant works if you describe those steps clearly.

What should I say if I don't know the answer to a technical question?

Say you are not sure, then explain how you would find out: who you would ask, what you would check first, and how you would test your guess. This shows you won't freeze or bluff on the job.

How long should a problem solving story be?

Aim for about two minutes. Keep the setup to one sentence and spend most of the time on how you found the cause and what you tried.

Should I mention a fix that didn't work?

Yes. Mentioning a failed first attempt makes the story more believable and shows you test ideas instead of guessing once.