What do interviewers look for when interviewing software engineering candidates?

What do interviewers look for when interviewing software engineering candidates?

An interviewer is usually evaluating you for three things:

  1. Do you have the skills (like CS fundamentals, Coding, Scalable Systems, Soft Skills, etc.)?
  2. Are you a problem solver?
  3. Are you someone I/my team can work with?

A single round of a?tech interview can take between 45 minutes to an hour. Over an hour is generally a good sign.

One of the first things that will be noted is your demeanor, and the interviewer will pick on any hints they get - are you shy, timid, confident, involved, apathetic, etc. Unless the interviewer wants to jump in straight away (this happens often and can throw you off), there will be some small talk that may involve a couple of tricky questions like:

  • I haven't had a chance to look at your resume. Can you fill me in on the highlights?
  • How do you think your other interviews have gone? (If you've had other interviews with the team before this one.)

The first question has several variations ("Tell me something about yourself.”) and you're likely to have been asked a few (100?) times if you've given many interviews. It's important to make sure that your answer is crisp and short. Don't ramble on about where you went to school and other obvious details from your resume. Instead, make it a story that talks more about what lies between the lines on your resume - what your experience has taught you, an example of a tough problem you've solved, what you could bring to the table, or even the team you are interviewing with.

The second question is trickier. Your perception of how things went might be completely different from feedback the interviewer may have already received before walking into the room. The easiest way to tackle this is to be honest without being either emphatic or vague. You may want to avoid a response like, "They went great" or "I think I killed it". But neither should you take the other extreme, with an "I did terrible in <insert round/problem>". Keep it neutral, like this: "I think I solved the first question on finding the longest subsequence well but stumbled a little bit on the design problem. I think I could have done better with a little more time."

These questions offer the interviewer useful insights about you, and convey the impression that you are secure and comfortable with the good and the bad, and more importantly, that you are the sort of person they'd like to work with.


On to the main course - the technical questions (Coding and System Design).

Technical interviewers generally bring two questions to the table.

  • The first: A coding problem to test your knowledge of fundamental data structures and algorithms, something they expect you to solve reasonably quickly (say in 20 mins).
  • The second: A more abstract question that tests your ability to break down a problem and identify a way to solve the problem. This could be a system design question (Design YouTube) or a more focused question (Design data models for a video streaming service that should be able to stream to multiple devices and support up to a billion users a month).

Your interview is usually over if you struggle with the first question. We may not be exposed to core Data structures and Algorithms in our day job but top companies use that as a minimum benchmark to move you ahead in the interview process. These problems usually test your knowledge of time and space complexity (think Big "O"), your ability to quickly assess what is efficient (and inefficient), and most importantly to write clean code on the whiteboard/coding platform being used.

Your evaluation of the second question (System Design) is mostly based on

  • How quickly do you break a problem down and figure out what pieces need more clarification?
  • What follow-up questions do you ask the interviewer to get more information?
  • How well can you articulate your thought process?
  • Your ability to make tradeoffs and justify them.
  • Your ability to offer ballpark estimates for memory, disk space, network load, buffer sizes, etc.

The deeper you get into the second question, the better your interview is going because you are challenging the interviewer to throw more at you.


On both technical questions, you are being evaluated for all of these:

  • Articulating your thoughts (GOOD)
  • Rambling contradictory thoughts (BAD)
  • Follow up questions and tell the interviewer the direction you are going (GOOD)
  • Long unexplained silence (BAD)
  • Organized whiteboard showing assumptions, and estimates and linking them to how you are solving the problem (GOOD)
  • Interviewer throwing newer and more challenges at you than hints (GOOD)

The key to all of these interviews is to be prepared. Companies, at least the coveted tech companies, expect you to prepare before their interviews. It is important to give yourself enough time to practice hard and solve as many different types of questions, know your resume in detail and hone your personal narrative well enough to give yourself the best chance.

If you are looking for a structured way to prepare for interviews, take a look at?Interview Kickstart

It's taken from this Quora answer.

Shashi Bhushan Kumar

Group Product Manager ★ Instructor / Coach ?? Ex- Head of Curriculum at GeeksforGeeks ?? Ex- SDE 2 at Adobe, Paytm ★ EdTech ???? NIT Allahabad

2 年

https://in.interviewkickstart.com/ - the best interview prep course for Software Engineers (for all levels and domains), check this out.

回复
Suresh Srivastava

Founder CourseGalaxy.com | Author of C In Depth, Data Structures Through C In Depth 250,000+ copies | Hard Core Techie | Loves doing Software Architecture, Design & Coding

2 年

Earlier we were having interview discussion for past behavior and how it fits with our current requirement, team and organization.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了