4

In the past I interviewed and hired fresh graduates, and people with up to 5 years of experience. Now we have a project that calls for an experienced engineer who can design and develop the whole thing from scratch, so now I'm looking at candidates who have 10+ years of experience in web development, some even served as project leaders. It seems to me that the kinds of questions that are appropriate for such a candidate should be different than the ones that are appropriate for one with less experience.

For example, one of the questions I liked to start with when conducting the SQL portion of an interview was: given a table with an id column, write a query that returns the largest id without using the function max(). This question pretty much told me if there was any point in asking further questions or not, because if someone had trouble with that question, they typically had trouble with all other SQL questions I had for them. So, great question for someone with up to 3 years of experience, but seems kinda silly asking it for someone who has 10+ years of SQL experience.

So my question is, how should I approach the technical portion when testing these candidates as opposed to less experiences engineers? Do I just ask more difficult programmatical questions? Do I focus on design? Is it still useful to ask them basic questions?

1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Kilisi
    Commented May 20, 2021 at 11:29

3 Answers 3

12

With that much experience the candidate should have a lot on their resume which can be analysed.

Don't skip the technical portion though, there is no guarantee that they're up to date and competent. I have seen engineers who look impressive on paper and over a decade experience who were sub par at best. I know experienced engineers right now that I wouldn't hire to sweep a floor unsupervised.

Look for things like keeping updated, hands on experience in decent projects that align with what you need. Burn out, lack of motivation, prone to delegate etc,. are all flags to check. Ask for details of how they solved problems if you see an interesting project on their resume. This gives you an idea of how they will work on yours.

Is it still useful to ask them basic questions?

Yes, it gives you an immediate feel if they have been doing admin for long enough to forget the basics. Don't show undue emphasis on it, but it's a necessary basic gauge.

A decades experience in making powerpoint presentations and delegating everything else is not worth as much as a hands on engineer. Extreme example but I've met more than one who seems to have gone that route.

1
  • 1
    This is the correct answer. It's probably going to be downvoted into oblivion, but nevertheless, it is absolutely the correct answer. Commented May 19, 2021 at 16:14
3

So my question is, how should I approach the technical portion when testing these candidates as opposed to less experiences engineers?

Have them design a toy system in front of you. Allocate an hour for such an interview (half an hour isn't enough). Give them a problem description along the lines of "Suppose we need a system for doing X. It also needs to Y and Z. Come up with a design for this and communicate it to us. You don't need to code it, of course, but please do sketch out what the main modules would be, and what sort of code they would contain."

Do I just ask more difficult programmatical questions?

Is the system you are hiring them to design and build going to involve more difficult programmatical work? If so, then yes. If not, then no. If you don't know, then no.

Do I focus on design?

Yes, absolutely. Isn't that what you are hiring them for?

Is it still useful to ask them basic questions?

Basic questions are of limited use in a world where developers regularly google for answers to anything they don't know. They're best for filtering out unqualified candidates, so should be used early in the process, such as during phone screens. Once you have an experienced developer in an interview, it's better to get them to demonstrate that they know how to solve problems.

This demonstration should not be in the form of merely asking them questions. I've seen too many developers who are good at answering questions but bad at actually applying any of that knowledge. Have them work through a problem instead. Ideally, choose problems that are slightly open-ended, so that they ask the interviewer for clarification or more information. You want to see how they think and act as a developer, not test their knowledge.

2

This question pretty much told me if there was any point in asking further questions or not, because if someone had trouble with that question, they typically had trouble with all other SQL questions I had for them.

Your original strategy is undershooting with the question. You ask the simplest question first, and when they fail to answer that, you know that there's no point in asking any harder questions. If they do answer it, you follow up with additional questions to further refine your read on their skill level.

So my question is, how should I approach the technical portion when testing these candidates as opposed to less experiences engineers?

However, in this case, you are already under the assumption that the applicant is on the high end of the spectrum and that starting from the easiest question is going to take a long and uninteresting amount of time.

So do the opposite. Overshoot. Ask your hardest question first. If they manage to answer that to your satisfaction, you know that there's no point to spend time asking any simpler questions. If, however, they don't fully answer it, that's your cue to start asking additional (simpler) questions to further refine your read on their skill level.

The principle is the same as before, you're just starting from the other end.


Secondly, I suggest just listening to their own confidence when talking about work experience. This is not an ironclad tactic (confident idiots do exist), but more often than not you're able to identify if someone is experienced based on how comfortable they are explaining a complex story.

Ask them to talk about their favorite project, or the hardest bug they've ever had to deal with, or anything that gets them to talk you through a work process they went through.

Even if you are not as experienced as them, you'll most likely notice whether they are experienced or not. To paraphrase Steve Hofstetter:

I've never flown a helicopter. But if I saw one in a tree, I'd still say "That pilot f***ed up". He's not supposed to be up there. That is pilot error.

Try to make sure the topic is about something they're very familiar with, rather than something you're familiar with, because this will negatively impact your reading of their confidence if they're talking on a subject that is not as familiar to them.

I just want to stress here that this by itself is not sufficient, as you could stumble onto a confident idiot who sounds very reassured but in reality misses the mark completely.
This is why you can't just skip the technical questions entirely. But it is reasonable to skip the easy questions for an (alleged) experienced applicant, and simply rely on their ability to answer the difficult questions.


Do I just ask more difficult programmatical questions? Do I focus on design?

That wholly depends on the specific role, but that shouldn't come as a suprise. Any questions you ask of any applicant should be relevant to the role you're interviewing for.

Is it still useful to ask them basic questions?

There's a difference between outright asking a basic question, or noticing that while talking about something else, the applicant made a basic error or lacks basic knowledge.

The former is arguably pointless with experienced candidates, but you should still be on the lookout for the latter, and when encountered, drill into it, even if that means asking a simple question.

That being said, it's not impossible for you to ask all of your questions, both simple and complex, of any applicant. It may not be as time efficient, and it may stifle the conversation, but if that is what your company deems necessary to vet an applicant, then that's how your company has chosen to run its interviews.

2
  • 1
    Not only do confident idiots exist, the cost of hiring one can be astronomically high. Tread carefully.
    – B. Ithica
    Commented May 20, 2021 at 9:26
  • @B.Ithica: Completely agree. This is why you need multiple interview vectors. Each vector alone (technical questions, technical talk, resume achievements, references) has a chance of being defeated (rote learning, overconfidence, false or misrepresented resume, hired goons), but managing to bypass them all is considerably less likely.
    – Flater
    Commented May 20, 2021 at 9:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .