[long] Performing interviews and being interviewed–some of my experience

I am an enterprise-level architect who was asked to share some of my experience on how to perform an interview. Since I don't blog, and rather than reply to the message in my inbox, I thought I'd write up a blurb here in case it is worth something to anyone else.

I have been a software engineer for 17 years. I've been at the receiving end of horrible interviews and amazing ones. I have been in a position where I've performed hundreds of interviews over the last few years, as well as given lectures at a few universities in Latin America to up-and-coming engineers.

Whether you are looking to change jobs or have been assigned to perform an interview, here are some things I do that, in my opinion, are far better than simply grilling someone on the finer points of fizz-buzz.

For the Interviewer

First and foremost, I want the candidate to be as comfortable as possible. I want the interview to feel like a conversation between two friends. Only then will I get a better idea about this person's abilities and if they'd be a good fit.

Phone Screening

The purpose of the phone screen is to simply weed out initial candidates. I have followed this format (one given to me by a colleague who is amazing in every way) for years and it works in quickly determining:

  • What level (junior, mid, senior, beyond) the candidate is
  • If they would be a potential good fit

For this format, in general, a junior level developer will take 45-minutes to complete the interview. A mid-level engineer will take 30 minutes, and a senior/principle will take 20 minutes or shorter. Mind you, some of this subject material may not be applicable to the position. This is the format I use for a full-stack engineer position and will tailor it as needed.

  1. Start the call by explaining your company. Give them the real version of what it is like (beyond what the website tells you): What methodologies do you practice? What is the team make-up? How are developers rewarded? How do the teams celebrate a win? What expectations are in place for each developer? What is the general architecture of your platform? What team would they be on if they got the job? What would their day-to-day duties look like?

  2. I'll give them a chance to ask a few questions here. Once those are done, I'll explain that I am going to ask some general technical questions to gauge their knowledge.

  3. SQL: I'll start really simple. Give me a SQL statement to select everything from a table. Then, I'll build on it. If I have two tables (Authors, books) and the Books table contains an AuthorID, what is a statement that will give me all books and their authors? Then I go a little deeper: What if I have an author who hasn't yet published a book. What is a statement that will give me all the authors that don't have a book in the book table? If they answer this correctly, I'll ask if they can do the same thing a few different ways. (LEFT OUTER JOIN, embedded SELECT, etc.) Again, I am not so concerned about getting the right answer. Listening for how they think and how they go about it is more important to me. A senior/principle will blaze through this. A junior will struggle. I'll help them out if they cannot get it, and it is not a show-stopper.

  4. C#. I'll ask about SOLID. I'll ask them to tell me as many design patterns that they can think of. If they know several, I'll ask if they've had an opportunity to implement any of them. Note: I am careful not to ask them which ones they've implemented, as that is not a good indicator of their ability. I've worked at places that simply didn't follow any patterns at all. I was not a bad developer, I just didn't have a chance to do anything really cool. I'll also ask simple OO questions: inheritance, interfaces, scope, etc.

Side-note: It is a poor decision (IMHO) to gauge your interview with a skill-set checklist approach. Example: "Do you have experience with MongoDB? Check. Do you have experience with AngularJS? Check." This is a horrible approach. A good developer can pick up and learn any of these technologies so long as they understand the theory behind how they work. I cringe when an interviewer gets an excited look in their eye and asks something like: "Do you have experience with [some obscure weird framework] by chance?" No, but I understand the concepts and patterns they followed to build that platform, and their specific implementation is just that: an implementation. Give me an hour with it, and I'll know it inside and out.

  1. Now that I have gauged their general ability, it is time to let them talk. I ask them this question: "I want you to think of a project you've worked on (anytime during your career) where you had influence as a decision maker. I am not so interested on which frameworks you chose, etc., but I'd like you to think of a technical problem you came up against and what your approach was to resolving it." Sometimes people will get bogged down on how hard it was to work with some process/policy (no hardware, grumpy person, etc.). I'll carefully reign them back in as those are not technical problems. I want to know about the time they decided to use a document store and it came back to bite them because an object-relational model was the correct choice. Or the time that their solution worked initially, but failed to scale and how they mitigated that in production. This gives them a chance to share who they really are as a developer and where they kicked some ass.

  2. This is where I wrap up. Before I end the call, I finish with a final question: "Is there anything about yourself that you would like me to know? Something you didn't feel you were able to communicate to me?" This has saved interviews. Sometimes, my questions simply miss the mark and do not paint a good picture of the candidate's abilities. This gives them a chance to share that really cool thing about them, or that really cool thing they did that I would have missed otherwise.

  3. Feedback. I let them know right then my decision. None of that "we'll be in touch" bullshit. I'll tell them where I thought they were weak in their answers and where they were strong. What impressed me about them as a candidate and if I think they'd be a good fit. If I want to bring them in for a face-to-face, I'll tell them so and get that ball rolling. Usually, when I don't move someone along, it is because they are applying for the wrong position. A junior applying for an architect role, or a seasoned architect applying for what is really a mid-level position. If a junior/mid developer is posing as a senior/architect, I'll call them out on it. A pet-peeve of mine is I see more and more candidates come through who list themselves as a senior developer, but have something like 2 years experience under their belt. It doesn't necessarily work that way. It is years of experience that make the developer. A general rule of thumb: a junior will be 0-3 years of experience. A mid-level 3-6 years. A senior 5-10 years, and a principle/architect 10+ years. Yes, there are exceptions to the rule. I've met some genuine geniuses who started off as a senior-level. But I've seen what happens when someone is promoted to a senior/architect level who wasn't ready for it.

I have to run to SCRUM now. I'll post later in the comments a section for face-to-face interviews as well as something for those who are interviewing for a new position.

by ex-mo-fo-sho via /r/csharp

Leave a Reply