Interview Answers for Software Engineers

Writing computer programs isn’t easy. So to assess a software engineer’s mastery of a language, Catherine Powell asks them to write a small application. Getting the technical assessment out of the way lets her focus her interview on the candidate’s adaptability, environmental fit and engineering approach.

Interview QsSee more of our interview questions

“Anyone can search the Internet and memorize answers to technical questions,” says Powell, the Dice Software Engineering Talent Community guide. “I want to know if they can anticipate and adapt to changing technology and work on a team. Because to me, those are the traits that make a software engineer a good employee.”

We asked Powell to share some of the questions she asks software engineers, and the answers she’s looking for.

What was the most difficult thing to master about the last program you learned?

  • What Most People Say: “I learned Ruby on Rails 4.0 or .NET and didn’t find anything hard.”
  • What You Should Say: “The hardest thing about learning Ruby on Rails was understanding how the language expected files, classes and methods to be named so it would find them ‘magically.’” Or, “I had a hard time with memory management in C.” Or, “I had a hard time learning the class libraries in .NET.”
  • Why You Should Say It: Everyone has difficulty with some aspect of a program. The engineer who isn’t forthcoming about their weaknesses probably won’t ask for help when they encounter problems during a project. It shows confidence and self-awareness to admit that something was hard to learn.

“About 60 to 70 percent of candidates try to gloss over their weaknesses,” Powell says. “I’ll ask a few follow-up questions to see if the engineer is afraid to step forward when something is difficult or simply lacks self-awareness. If they continue to give me superficial answers, I’ll end the interview.”

If you had to start over during a project, what, if anything, would you do differently the next time around?

  • What Most People Say: “I wouldn’t make any changes. I’d do everything the same.”
  • What You Should Say: “I wouldn’t make any changes, but here’s why.” Or, “I would make the following changes and here’s why.”
  • Why You Should Say It: “Your explanation tells me how you learn and adapt to changing circumstances,” says Powell. “Do you get stuck in one way of thinking or do you analyze mistakes and learn from them?”

How will technology change in the next three years?

  • What Most People Say: “We’ll all be flying around in rocket cars.”
  • What You Should Say: “I understand that tech has cycles. Here’s what I expect to see in the next five to 10 years.”
  • Why You Should Say It: “Software engineers need to make prudent decisions by anticipating and adapting to change,” Powell believes. Your answer should demonstrate your appreciation for technology’s cycles, while exposing your logic, decision-making process and ability to think long-term.

Powell says she doesn’t want to hire someone “who blindly follows the latest technology trends without considering the consequences.”

How would you teach someone a new piece of technology?

  • What Most People Say: “I’d point out the tutorials.”
  • What You Should Say: “I’d use a variety of techniques that meet the needs of adult learners. For example, I’d incorporate self-study with hands-on coaching and I’d give them small problems to solve. I’d also use pair programming and encourage them to seek feedback from their peers by posting their code online.”
  • Why You Should Say It: Your answer should showcase your understanding of adult learning techniques. In the process, you’ll be demonstrating your nuanced understanding of your own learning patterns and your ability to transition from learner to teacher.

“Once you’ve established that you’re technically proficient, managers want to see if you have the right temperament and mindset to thrive in a dynamic environment like software engineering,” Powell explains. “It takes more than great technical skills to be a great software engineer, as well as a good employee.”

Comments

  1. BY RobS says:

    While these things are nice to know about, how many employers actually think the same way. If I started telling an employer that I have fault after fault, that would likely turn them off from hiring me. Of course, I can turn that around by explaining how the faults will not impact them or how those faults will actually help motivate me, but if I’m technical, I’m probably not a salesperson and would have a hard time convincing someone how my faults can help them. Conversely, as said, you don’t want to come across as arrogant and flawless because you’re not (or you most likely wouldn’t be job-hunting!)

    • BY Leslie Stevens-Huffman says:

      Dear BY ROBS,

      While I agree that you shouldn’t “volunteer” a long list of faults during an interview, you need to master the art of responding to tough or “negative” questions that probe for shortcomings, weaknesses and flaws. Otherwise, it will seem like you lack self-awareness and confidence as Powell suggests. Offer two positives for every negative you offer-up and always end your response on a positive note. And avoid deal-breakers by coming up with a short list of errors and miscues before the interview. After all, nobody’s perfect.

      Leslie

      Good luck.

  2. BY Tula says:

    There seems to be a trend toward “whiteboarding” or coding on demand in interviews lately. I’ve been working as a contractor since 1992 and have done loads of interviews and it’s only in the last couple of years that I’ve started seeing this. I, personally, hate this, because I’m an engineer, not a performer. It may just be a personal quirk of mine, but trying to code while someone is watching over my shoulder tends to make me lose all focus and look like a bumbling fool, even though I usually work very well under pressure. It’s probably the same reason I dislike those new open collaborative workspaces. Trying to work with eyeballs on you all the time is nerve-wracking for those of us who aren’t comfortable with an audience.

    I wish people would understand that people are all different and that some are more comfortable with certain environments than others. It doesn’t make me a bad engineer simply because I don’t perform as well when being observed like a bug under a microscope. I’m also not antisocial or a 100% heads-down developer, either, but interacting with people on a regular basis is different than being put on the spot like that. I suppose I’ll have to wait for this latest fad to pass….

    • BY jinjin says:

      I’ve seen the same trend toward white-boarding and also don’t perform well with the task, even with over 20 years of coding / IT experience and masters degree in computer science. I was even asked to write code on the interviewer’s laptop, troubleshoot and get it running while the rest of their team watched on an overhead projector screen!

      In my opinion, this practice does not reveal anything about the “way I work” or whether I ask for help often enough, as many interviewers tell me. This is software development, not a singing or talent competition! One interviewer even said it was ok for me to search the Internet for code snippets…yeah, right, like I’m going to lift code from the Internet for an interview test, I don’t even do that for code I write at home! I’m really tired of this interview tactic and hope employers move to a more practical evaluation technique. It would be better if they ask questions like the ones used in this blog, but I have yet to encounter those types of questions.

      • BY TAEaton says:

        I have both been the person asking someone to whiteboard code and been the developer holding the marker. The reason we have used it, is when we get those people who don’t have great interview skills, didn’t learn to code at collage and thus don’t know the big words, or are just having a bad day, but know the code and know how to take A and return B. It is also a good way to wash out those that are really good talking their way through an interview and use all the big words at the right time, but can’t code themselves through a logic statement. Another tactic I have used and been subject to is talking my way through printed out code to demonstrate that I understand what is going on, can identify where the code can be improved, or identify why the code won’t work.

        As far as lifting code from the internet, that is actually not a bad thing. It shows that while you aren’t the end all be all of code, you know how to quickly identify solutions and apply them. I have more than once made an interviewer smile by responding with, “I don’t know, but I can google it for you if you would like.” It also helps to have a running list of sites you turn to for assistance when you do get stuck. If your interviewing someone and they and don’t know what stackoverflow is, there is a problem there.

  3. BY screenedOutIdealCandidate says:

    I am so frustrated by the pathetic ineffectiveness and hideous waste of my time so many of these “clever interviews” you write about have become. More often than not the right candidates either refuse to take part or will be screened-out i favor of a ‘study-the-test’ less able candidate.

    I have decided that I will ask the interviewer a random whiteboard question in return for ever one they throw at me – if they fail and of MY test questions I will ask them to quit their job and let me have it. These interviews smack of being designed and run my bumbling idiots (probably with MBAs) that are clueless about engineering.

  4. BY Debby says:

    Holy cow.. so glad I’m not the only one who is having trouble with these white board interviews! I also end up looking like a bumbling idiot and can’t even think.

    I tell people point blank I do not work well like that and ask if I can find another way to show them what I have to offer that is more suited to the way I work. Nobody has offered alternatives.

    I can also talk in a general abstract way about a problem but I can’t write algorithms on the fly.. sue me. I’m also often interviewed by back end engineers who really don’t understand front end engineers and can’t interview someone like me properly.

    What I’ve been doing is trying to do a lot of leading in the interviews by either talking a lot about experiences I’ve had and projects I’ve worked on and I bring demos to show. Sometimes they just force me to whiteboard anyway.. sigh.

    I have 20 years of experience in the field for nothing but brand name corporations. Really frustrating. I want to throw the pen at the white board. Ha.

    Any other ideas on how folks recommend dealing with the dreaded whiteboard questions would be awesome!

    • BY RobS says:

      What I’ve started exploring for “whiteboarding” is to take more of a teaching approach. Think about how you would solve the problem and start diagramming it then replace parts of the diagram with code.
      E.g. “We’ll need a function, let’s call it XYZ, to handle that task. Then we loop through a collection of things calling that loop passing in the value.” Then you write the function with the proper syntax then expand the loop, etc.
      I think this may help jump-start you in the right direction because once you start coding, you’re probably going to do better than when you first stand up in front of observing eyes.

      • BY Debby says:

        That sounds great but I can barely think about the problem that way. Accessing my personable creative side which is a sales pitch to interviewers I can’t do at the same time as writing code.

        I just can’t do it very well with an audience. I need quiet and time to think about it and I do better with written instructions. It just doesn’t suit my strengths. I prefer coding tests with access to references at least for syntax.

        Or showing work that I have done. I’m going to have to get some ideas on whiteboard interview strategies and I’m glad to know I’m not the only one especially really talented people.

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>