Interview Questions by Job Title

Pick the job you're interviewing for and get 12 likely questions: the behavioral ones everyone asks plus role-specific technical ones. Each has what the interviewer is looking for and an outline for your answer. Below them are 10 good questions to ask the employer. Free, no sign-up.

12 likely software engineer interview questions

The first five are behavioral questions almost every interviewer asks. Open a question to see what they're looking for and how to build your answer.

1.Tell me about yourself.

What they're looking for: A clear 60-second story that links your background to this job, not a recital of your resume.

Answer outline: Present: who you are now (your degree, current role or main projects). Past: one or two experiences that built the skills this software engineer job needs. Future: why this role and company are your next step. Stay under one minute.

2.Why do you want to work here, and why this software engineer role?

What they're looking for: That you researched the company and chose it on purpose, not that you will take any job.

Answer outline: Name one specific thing about the company from its website or the posting: a product, a project, a value. Connect it to a skill you have. Finish with what you want to learn or contribute.

3.Tell me about a time you worked on a team and disagreed with someone.

What they're looking for: Whether you handle conflict calmly, listen, and reach a result without blaming anyone.

Answer outline: Situation: a group project or work task where you and a teammate wanted different approaches. Task: the goal you both shared. Action: you listened first, compared the options against the goal, and agreed on a way forward. Result: the outcome, and what you learned about working with people.

4.Tell me about a time you made a mistake or failed.

What they're looking for: Honesty, ownership and learning. They want a real, small-to-medium mistake and what you changed afterward.

Answer outline: Situation: a real mistake, such as a missed deadline, a wrong number or a bad assumption. Task: what you were responsible for. Action: you told the right person, fixed it, and put a check in place. Result: the fix, and one habit you now follow.

5.Tell me about a time you had several deadlines at once.

What they're looking for: How you prioritize, communicate and stay organized under pressure.

Answer outline: Situation: exams, a project and a job all due in the same week. Task: deliver all of them. Action: you listed everything, ranked it by deadline and impact, asked early for flexibility on one item, and blocked your time. Result: what was done on time, and what you would repeat.

6.Walk me through a project you built. What was your part, and what would you change?

What they're looking for: Whether you really built it, can explain your technical choices, and can reflect on tradeoffs.

Answer outline: The problem it solved, the stack and why you chose it, your specific part, one hard bug or decision, and what you would improve. Be ready for follow-up questions about any part of the code.

7.How would you find and fix a bug in code you didn't write?

What they're looking for: A calm, methodical debugging process.

Answer outline: Reproduce it, read the error or logs, narrow it down with a debugger or print statements, form and test a guess, fix it, and add a test so it doesn't return. Share a real example.

8.Explain the difference between an array and a linked list, and when you'd use each.

What they're looking for: Data structure fundamentals and tradeoffs, which most new grad coding rounds test.

Answer outline: Array: contiguous memory, constant-time access by index, slow inserts in the middle. Linked list: nodes with pointers, fast inserts and deletes when you hold the node, slow lookup. Use arrays for lookups and iteration, and lists when inserts and deletes are frequent.

9.How do you approach a coding problem you haven't seen before?

What they're looking for: Communication under uncertainty: do you think out loud, clarify and test?

Answer outline: Restate the problem, ask about inputs and edge cases, give a simple solution first and then improve it, say the time and space cost, and test with an example out loud.

10.What does a good code review look like to you?

What they're looking for: Teamwork and quality habits.

Answer outline: Small changes with a clear description. Check correctness, readability and tests. Give kind, specific comments, and accept feedback without arguing. Add an example where a review caught a bug.

11.Tell me about a technology you taught yourself and how you did it.

What they're looking for: Self-directed learning, the main skill of a new grad engineer.

Answer outline: What you wanted to build, how you learned (docs, a course, a small project), where you got stuck, and the working result.

12.How would you design a simple URL shortener?

What they're looking for: Structured thinking at a basic level, not perfect architecture.

Answer outline: Clarify the needs. Generate a short unique key for each URL, store the mapping in a database, redirect on lookup, and mention caching and what happens if two people submit the same URL.

Questions to ask the employer

Pick three or four for each interview. Asking good questions shows you're serious about the job.

  1. What does a typical day or week look like in this role?
  2. What would success look like in the first 90 days?
  3. How does the team onboard and train new hires?
  4. Who would I work with most, and how does the team collaborate?
  5. What are the biggest challenges the team is facing right now?
  6. How is performance measured, and how often do people get feedback?
  7. What are the next steps in the process, and when can I expect to hear back?
  8. What does the code review and testing process look like?
  9. What technologies does the team use, and how are they chosen?
  10. How do junior engineers learn from senior ones (mentoring, pairing)?

How to use it

  1. Choose your job title from the list.
  2. Open each question and read what they're looking for. Write your own answer using the outline and a real example.
  3. Say your answers out loud, or practice one with the free AI mock interview.
  4. Choose three or four questions to ask the employer at the end.

How to answer behavioral questions with the STAR method

Behavioral questions start with “Tell me about a time…”. Answer them in four steps. Situation: the context, in one or two sentences. Task: what you were responsible for. Action: what you did, step by step. This is the longest part, and it should say “I”, not “we”. Result: what happened, with a number if you have one, and what you learned. Prepare four or five real stories from classes, projects, jobs, volunteering or clubs. Most behavioral questions can be answered with one of them.

Questions to ask the employer

Almost every interview ends with “Do you have any questions for us?”, and “No” is the weakest answer. Ask about the work, the team and how you'll be trained, not about pay or perks in a first interview. Good questions show you thought about the job. Avoid anything you could find on the company's website in a minute.

Frequently asked questions

What are the most common entry-level interview questions?

“Tell me about yourself”, “Why do you want this job?”, a time you worked on a team, a time you made a mistake, and how you handle deadlines. Then a few questions about the skills for the job itself.

How do I answer “Tell me about yourself”?

Use present, past, future in under a minute: who you are now, one or two experiences that built the skills for this job, and why this role is your next step.

How many questions should I ask the interviewer?

Prepare five to ten and ask three or four, depending on time. Choose ones that haven't already been answered in the interview.

What if I don't have work experience to use in examples?

Use class projects, internships, volunteering, clubs, sports and part-time jobs. Interviewers know you are early in your career. They want to see how you think and act.

Are the sample answers word-for-word scripts?

No. They are outlines, so you can put in your own real examples. Reading memorized answers sounds stiff, and interviewers will ask follow-up questions that need real details.

More free tools