What Software Engineering Areas should be stressed upon while Interviewing Candidate for Fulltime Software Engineering Position ?

Question

Hi,

This question is somewhat related to other posts which I found on Stackoverflow but not exactly and so am prompted to ask about it.

I know we must ask for Data-Structures and Algorithms but what specific data-structures or Algorithms or other CS Concepts should be asked while interviewing Sr. Software Engineering Fulltime Position as compared with Software Engineering Position.

Thanks.

Answer 1

Depends on area of his work.

Focus on kind of problems that candidate will have to solve most of the time.

Answer 2

I'm not sure if this is what you mean by "other CS concepts", but I think one of the things that separates a Senior Software Engineer from lower levels is a thorough understanding of the kinds of software process that make or break a project. A senior dev should be able to help guide a team through course correcting when he/she sees an improvement that could be made or a common pitfall that the team is heading towards. The project manager typically handles these things, but the senior devs on the team should be giving input as well.

Asking questions about software process philosophy will give you a good idea if the developer will fit into the team. This is a good area to "just let them talk" during the interview. If they have little to say, they probably aren't interested in process or have little experience with guiding it.

Answer 3

If you're looking for the distinguishing characteristics of a "Senior" vs. "non-Senior" engineer, I'd focus on what I'd expect from such a person. Here are some example questions that I might ask. Note that they assume that the person is already a "senior": I like to drive the conversation in a positive way and assume the best (until I smell blood in the water...).

1. A senior engineer is a leader. What technical leadership are you showing in your current position? How is that going? What are the challenges there? What would you have done differently?
2. A senior engineer is a teacher and mentor. Who are you currently mentoring? How could you improve your mentoring abilities? Is that a fun part of your job?
3. A senior engineer is expected to be an expert. Where are you currently working to improve your expertise? Tell me about something that you have done that you thought was an impressive accomplishment. Hey, it sounds like you could have done [X] differently, why did you make that choice? Are you sure about that rationale? What if you had to scale large / scale small / deal with heat problems / work underwater / etc.?

My point with the third set is that the technical questions tend to be person-specific. It's very hard to line up useful questions ahead of time (unless you have a very specific set of technical capabilities).

EDIT: To clarify for the purposes of the comment, here are two extremes of specific technical questions that apply to my current work that would be best suited to a certain class of person but are likely mutually exclusive for a junior developer. I wouldn't know which would be a better talking point until I meet the person in question:

1. How would you ensure that the wireless network connection to our remote sensor X is still alive? I might ask someone with experience with real-time control of wireless cameras on their resume this question.
2. How would you persist several gigabytes of sparse but similar data collected at our facility over a period of years for the purposes of post-analysis? An E-commerce person, DBA or similar person might be appropriate for this question.

That said, I would expect a senior-level person to be able to ask the right questions to start a discussion even if they didn't have prior experience in either of these fields.

In the end, the people-parts of the questions are much more interesting to me: I want to know about how this person would work with the rest of us. Most importantly, why should I hire them when I could use that money to buy new monitors for the whole team.

In the big scheme of things, I care less if they can type code really fast. How are they going to make the team better so we can (a) get our work done well and on time and (b) go the hell home and be ready to do it again tomorrow!

Answer 4

I'd be inclined to ask about what design mistakes they made in the past and what they learned from them and how they would do things differently with their current knowledge.

I'd also ask about design problems they encountered in existing systems and how they fixed them.

Answer 5

Here are a handful of related questions that may have useful answers:

• What does “Senior Software Developer” mean?
• junior to senior programmer
• What are the properties of a senior developer?
• What is your definition of a Entry Level/Junior/Mid/Senior Developer?
• http://stackoverflow.com/questions/586245/differences-between-an-intermediate-and-senior-developer-closed

For my own answer to the question, the key is to determine what changes has the experience of being the field for a number of years done to the person's skills:

• Are they able to design things quicker?
• Ask more questions when given vague requirements?
• Have coding standards and practices they use?
• How have they handled difficult requests or deadlines set by others?