loading...

What's your ideal interview process?

sophia_wyl profile image Sophia Li ・1 min read

In my experience and observations, software engineering interviews typically look something like this:

  • Introductory call - discuss background and role (15-30 min)
  • Tech interview - live coding or take home coding challenge (1-2 hours)
  • Onsite - cultural and tech interviews (4-5 hours)

This of course varies with each company and role.

As a candidate, what's your ideal interview process? One where you'll have a good candidate experience and also display your technical ability.

Discussion

markdown guide
 

Just the way I interview candidates. I feel most companies only know how to interview college graduates and so their interview style is very much like a "test". Many times I've walked out in the middle of the process or have not gone in just because I can tell a lot about a company from the way they interview and I wouldn't want to work there.

After the introductions and other pleasantries and I've made sure they're comfortable (food drink etc.). I tell them how this interview will go (I mainly interview senior engineers and architects, sometimes mids):

Just imagine we're two geeks, geeking out at a coffee shop forget that I'm interviewing you. We're just going to have fun. You're going to start by tell me about one of most interesting projects. I don't want to get into the weeds of the business so keep it more technical than business. As you're speaking I'll stop to ask you some questions on what you just said. If you don't want me to asking you a question on a certain topic, don't mention it (anything you say, can and will be used against you, jokingly). If you're able to answer, I'll dig deeper and deeper, till we either hit rock bottom or I feel you've reach your limit. Not knowing it not a crime. I'm not keeping score. Continue with story.

If you don't know, I prefer you tell me right away. If you don't know but would like to give it a shot anyway, let me know and go for it. We don't have much time, and I'd rather we spend time discovering what you do know rather than what you don't. I want to see you succeed. My aim is to get a sense of your breadth of knowledge and experience while also the depth of you knowledge on each topic, technology etc.

I may interrupt you while you're answering, either because I feel you don't know, or I know you know and I'll asking something about something else you touched upon. For every question I ask you, I'll give you the answer with explanations and variations (how, why, when).

This style of interview gives me soooo much information about the candidate.

  1. Communication skills and the ability to clearly/succinctly explain problems and solutions.
  2. Their personality. How do they take criticism and direction. Do they feel comfortable saying "I don't know" are they argumentative. Are they passionate about they job choice and the work they do
  3. Get a really good sense of their breadth and depth of experience.

I give them an opportunity to talk about anything else we didn't hit upon that that'd like to talk about, with the same caveat (anything you say, can and will be used against you :)).

If the interview ends soon, ether you, me or the both of us didn't care much for it. If we're having a blast, someone is going to walk in and say we need the room!

By the end of this session, I can see the candidate is still all present, drained to some extent but they're so excited that they've learnt so much. Most times they feel comfortable enough to say one of two things:

  1. I know, I've not made the bar, but I've learnt so much, what would you suggest I work on/study, gain more experience in. How to I become a senior etc.
  2. If I make it, will I be working with you or some other team?

Where I work, candidates are asked by HR to provide feedback on the interviewer (there is a multiple choice questionnaire). I've got only 2 bad reviews so far after hundreds of interviews.

 

Thanks for your thoughtful response!

I have a couple questions:

  • When you say you, "I feel most companies only know how to interview college graduates and so their interview style is very much like a "test"." , are you suggesting that the approach for interviewing college graduates is a good approach?
  • When you're talking about projects, are they personal projects, work projects, or really anything they want to choose?
  • It's so interesting that the outcome of the conversation can lead to the candidate knowing they've not made the bar and feel like they can ask for constructive feedback in an interview setting. What do you think you do/say/ask to indicate to candidates that they have not met the bar, but in a way where they still feel comfortable asking for feedback?

Also, I really like that your company's HR team asks for feedback on the interviewer. It's a great way to improve the interview experience for both sides. And congrats on the good feedback from interviewees. Sounds like you're a great interviewer!

 

To answer your first question:
For the most part I don't believe that style is getting you much. I mean there are sites that provide all kinds of practice questions and problems and apparently if you spend your time there you'll ace the FANG coding challanges. So it's become like school. You practice, and the ace the exam. Maybe it's a good way to interview candidates who have very little experience. I'm not qualified to interview candidates at this level so I can't speak from experience.

Work or personal projects?
Typically work projects, but I'd be interested in personal projects too. Just so I get a sense of what the candidate does on their own time, how much effort they put beyond work towards their craft. I spend a lot of time on personal (but real world) projects myself.

On my very first job interview, I took a laptop with me with all of the personal projects (I had also done a couple of contract based software projects where I was paid for the work), and I think that helped or maybe the fact that I did a lot of (real world) work on my own helped.

Outcome and asking for feedback:
I think through the whole process the candidate feels at home, we're really having fun. They're quite aware of the questions they've not been able to answer or didn't provide a full/more in depth answer. Most times they assume they didn't make it and I'll let them know otherwise. I don't expect any candidate to be able to answer every question because the more you know, the deeper I'll go.

In some cases their expectation are way higher than their skill/experience. I call it the big fish in a small pond syndrome (As against a small fish in a big pond). That is, if you stick around in one company for too long you get comfortable, you've earned a certain status, you probably don't hire folks that know more than you and so you're the top person in that company. But when you come out in the real world you get a rude awakening. Some candidates have said as much. That self realization is very encouraging to me and we'll make an offer at a lower level than they are asking for. Some will take the offer while others don't.

I ask them if they have any questions for me about the work, projects, company or anything else. So that's when the conversation take a different direction.

I got the HR folks to start that process because I honestly wanted ot know if I was being too hard on the candidates or whatever else. I felt I was flying blind and I don't think it is appropriate to put the candidate (given the situation at the time) on the spot and ask them how I'm doing. When I'm training or talking at conferences I do ask the audience how I'm doing. They even fill our a questionnaire after every session, so I get that feedback so I missed knowing where I'm at for interviews.

Thanks for providing more insight! I'm a junior starting out my career so I'm curious what a good standard for interviews is (and of course understanding there is no perfect process). Your answer helps a lot in understanding what different types of interviews exist, and what types of processes provide a better candidate experience while also providing a better assessment.

 

That's something interesting! Unfortunately, it is for senior or architect positions. What I like in your process is that you give feedback rather than just letting the candidate go and send them an "unfortunately we could not advance with you" email.

I wish I learned more about how you decide which candidate you take or give offer after having all info you need, especially as you don't give score.

No story for entry or junior positions?

 

@Abel, I can't really pin down a process or method. You get the overall feel after a talk with someone. Ok, so they don't know, but can they learn? Can they be taught? Would they gel with the others on the team?
If they do know, will they spend time teaching others, bringing them up to their level? etc.

As senior, you are expected to know a minimum level and to a certain depth rather than just surface level. Need good "quality" experience rather than just years of experience.

 

Abel, the companies I've worked for over the last 12 years have only hired seniors and architects and I'm not qualified to interview juniors and mids, so I can't speak from experience. Well, I had a couple of experiences where I was asked to interview a mid level and a junior and it was a disaster (for me) and a waste of time for the candidates. I fear that interviews for junior positions take the route of FANG companies. But honestly I don't know.

 

Excellent approach. What strikes me is that for most of the people here on dev.to this is the ideal interview, still, in real life, it's almost impossible to find some one who does it (at least in Germany/Spain/Romania, where most of my interviews were)

 

I know, think companies conduct interviews en-mass so they need one process to conduct all interviews. What they don't realize is that everyone is different, and if you truly want to extract the strength of an individual you've got to personalize it on the fly for the individual. You've got to work at it. Also both parties have got to leave their egos, at the door.

Interviewing (And being interviewed) is an art form that we as an industry do not understand. I remind friends and co-workers who are going out to be interviewed that they are the ones in fact who are interviewing the interviewer (After all they are the ones moving from one relationship to the next) and not to forget that.

Also find another job while your current one is secure. Don't wait till you don't have a job and are desperate. Beggars can't be choosers as they say.

 

This is almost exactly the same process I follow as well. My interviews are entirely conversation-driven. Any technical challenges are driven by the topics that come up. It's worked very well for me over the years.

 

If only there would be more interviewers like you. Way to go! Thank you for doing what you do best.

 

Love this process, Shiv. You learn so much more by letting the candidate relax.

 

My answer is very much in line with that which @matlus gave; I'd like to warn, however, that this is unfortunately seldom the reality of dev hiring practices.

When I am in charge of the process, I've found that putting the candidate at ease is going to tell me far more about them than some goofy terminology quiz, some contrived, on-the-spot, timed coding challenge, or whiteboarding exercises. I also know my team, and I'm not going to put this candidate through a whole day running the gauntlet with them, or make them feel like they're in a Zoom fishbowl in front of so many sets of eyes. In fact, I don't need you on camera at all.

  1. Always start with a casual, conversational interview (phone). The more senior a dev is, the more it's about "trading war stories." Regards of level, it's giving the candidate a chance to ask questions or make comments back and forth with me. Whatever your experience, I want you to speak to it in the way you're comfortable and let your passion and curiosity (and where you might fit in, as envisioned by each of us) shine through. I don't impose my hours on others, so I'm going to do my best to allow for this to run over (as long as you have time for it). I'm also not going to waste your time if it isn't a fit - but I'm not going to dismiss without checking for my own understanding first.
  2. Take home challenge. The task will only take a few hours, but you'll get a full week to complete it. You shouldn't have to cram it into your weekend (let alone a few working days), but you should have time to knock it out over a weekend if that's your choice, while also getting adequate time to reason about the solution throughout the week. You'll have my email, so you can email at any time with questions, and I'll check in a few times throughout the week to reiterate that I'm available. I have to earn your trust as well.
  3. Code review interview. While I may have other devs present, I'll be the only one asking questions (though some of them may come from the others), to avoid as much of the "presenting to the committee" feeling as possible. Just be prepared to defend your solution. If you got some parts from googling (and I'm secretly hoping you did, shows you can reach out), just make sure you understand how they work (bonus points if you're willing to admit you got them online).
  4. (if I'm hiring for someone else; if it's for me, you've already completed this step) Culture interview.

I mentioned putting the candidate at ease. There are a few reasons for this.

  1. Anybody can screw up under pressure, even if it's something they know like the back of their hand. A lot of good devs fall through the cracks this way.
  2. None of the on-the-spot exercises resemble any sort of environment I'd want to work in. I've worked under immense pressure - it involved finally putting my foot down so we didn't kill astronauts - and I'll never do it again; not like that.
  3. If you're at ease and you're BSing me, eventually you're going to get comfortable and slip, and I'm going to know it.

And to answer your first question to @matlus 's answer, no. The live "test"interview format isn't even good for recent grads (though in my experience, they and job hoppers are better at it than experienced, employed devs who are busy solving real world problems, making it even more pointless).

 

experienced, employed devs solving real world problem
Exactly, I think that's the big disconnect.
In my last interview, (which I did as a lark really, since I wasn't actually looking for a job), they had to do a bunch of timed coding tests where they projects were really toy applications. I finally just told the interviewer that it's a waste of both our times.

They wanted to continue the conversation so I told them the basic issue I had with them was:

  1. They're ignoring my resume. I mean I don't think I can fake 20+ years of experience.
  2. The folks interviewing me probably had 4-5 years of experience
  3. The live coding tests were just toys and I didn't want to spend time thinking about a solution that's also a toy. That is it's not even at the level of a proof of concept.

Anyway, yes there is a big disconnect in the world and I think the culprits are FANG companies who mostly hire recent grads.

 

Thanks for your thoughtful answer! Do you cap a time limit on the take home assignment? For example, something like, please don't spend more than 2 hours on this project.

Also for recent grads, if the "test" interview format is not good (I agree), would you suggest the approach you've outlined above as an alternative?

 

It depends on the role, but typically 2 for a junior and no more than 4-5 max for more senior roles (again, with a week to complete either way).

And yes, I'm saying from a hiring perspective that I learn absolutely nothing useful about any dev, at any level, from any other challenge format (and it blows my mind that this isn't obvious to more devs in a position to hire; again, they should know better).

Perhaps even worse from a management perspective (but then, there are a ton of bad managers out there, tech or otherwise) is the message you're sending devs (whether you intend to or not) if you do put them on the spot like that in the hiring process: That you and/or your company foster a culture of micromanagement; that the dev is "free" to find their own solution, but you'll be watching their every move. I think the biggest, largely still unacknowledged business lesson from COVID (with the sudden shift to remote) is just how many terrible micromanagers there really are out there. I would warn every job candidate to be cognizant of this, because the impression a company gives when hiring is likely the best you're going to get from them.

Thanks for your insight! I'm on the more junior side and am trying to gauge what's an appropriate amount of time to spend on a take home assignment.

Just remember this above all else: Everyone assigns and judges them differently.

Boil it down to how you will meet the requirements first and foremost. There is a temptation to go above and beyond to stand out, but some will count that against you for going out of scope. If you do this, make sure you do it as separate from the stated requirements (separate directory, entry point, branch, whatever, as long as the assigned solution can be run on its own). More important is to ask about edge cases you need to consider, if not provided.

 

I would want it to be efficient, casual, practical, and humane (I'm sad that I have to add that):

  • The interview process is outlined at the start. The company lets candidates prepare based on that. Every company is different and blindsiding candidates leads to a bad outcome for the candidate and the company.
  • Combine the recruiter screen with a technical screen. Talk about the recruiter stuff: the company, what they are looking for, what the candidate is looking for, etc. Then some casual open-ended technical questions about what they have done to get a feel for the candidate's technical ability and personality. It also confirms that their resume is an accurate representation of the person. That saves a step and gives the company and candidate more to go on as to if they want to move on.
  • A technical interview should be a few easy, close to real-world scenarios in the programming language they are interviewing for. Walk the interviewers through your thoughts on solving it or how you would go about confirming your guesses. Keep the discussion a little higher level, being right isn't that important, being able to troubleshoot and explain to others is all that is needed for most jobs. Interviewers should chat with the candidate by providing the right hint or a positive response if they liked the answer, not sit there in silence waiting for the candidate to solve it. Candidates are preparing for multiple interviews and it is stressful, they can't (and shouldn't) know everything. Closed-ended questions that you don't know or were not expecting with silent interviewers is a horrible experience.
  • Have kind people that can show empathy as your interviewers. A positive introduction and prepared interviewer will put the candidate at ease and help them perform better, which is good for the company.
  • Give the candidate time to ask questions at each stage of the interview process. Have the interviewers describe their experiences at the company. The candidate needs to know if they want to work there too.
  • Both sides should seek to answer some basic questions: can I work with this person, do they know how to solve problems? Companies tend to fixate on perfection or "the best candidate" far too much. A decent human-being that is intelligent, prepared, and is flexible with opinions/tradeoffs is a great candidate in my book. They can pick up particular skills or bits of knowledge on the job.
  • The interview process should reveal the company's values. I've been through some fairly rigorous interview processes but at the end of it, I wasn't sure what they were even looking for or trying to measure. Their job posting didn't line up with the recruiter or the interviewers. It seemed like a one-sided bombardment or an endurance test rather than an effective hiring process.
 

Thanks for your thoughtful response! I'd love to hear more about what you mean by combining the recruiter screen with a technical screen.

Would the first call be maybe 30-45 mins? First starting off with 15-20 min of the company background, then the candidate background? And if it's a good fit on both ends, then they immediately move on to the technical screen for the rest of the time?

And would it be the same person interviewing (either the recruiter or swe)? Or switch from recruiter first, then swe? What kind of casual open-ended technical questions would be asked?

I could see this process speeding up hiring / decision making for both parties!

 

I think it would be an engineering manager that does the full screening and probably would last around 30 minutes. I think the open-ended questions could be things pulled directly from the candidate's resume such as "I see you have JavaScript listed here, how long have you been using it and what types of things have you worked on with it?" or "In your position as a tech lead, it says that you led a migration to React, tell me more about that. Maybe why you chose it, what were some challenges in transitioning, or anything else you learned." Hopefully, it would be more of a conversation with the manager talking about similar tools being used or similar problems being solved at the company to make it more of a two-way interview.

Ah that makes sense. I like that approach and the open ended questions!

 

Just by having a conversation and talk about what you have done and show off some personal projects. I just had a FAANG interview scheduled and it was really intense. First a phone interview and then the onsite which was 5 back to back 45 min interviews. You will probably feel very drained at the end of the day.

 

Yeah, I really like the idea of showing off personal projects. What kind of questions would you want an interviewer to ask you about the project?

 

Above all. why? What did you hope to achieve with each, and did you succeed? But I'd really like that to be a starting point and for the interviewer to be engaged. To listen to the answers and react to them, probing deeper in those areas where the interviewee shows enthusiasm for what they did, or plan to do next, rather than stick to a rigid set of questions.

Asking open ending questions, especially for personal projects, does seem to be a good starting point to go off of. Thanks for sharing your thoughts on your ideal interview process!

 

Basically ask for reasons why I chose for technology X and not Y? They will be able to see how you communicate and if you actually know what you are talking about. Also, probably some questions from the business side of the project you are presenting.

Yes, understanding and being able to communicate trade offs is important. Thanks for sharing!

 

Not quite an answer to your question, since I haven't interviewed for a software engineering role myself in some time, but I figured I'd respond with a view from the other side of the table. I have a team of 20ish, and after interviewing several hundred candidates to, our process has grown into something new that's along the lines of your observations.

There are people on my team with over a decade of experience, all the way to college freshmen working at their first job, and the process to hire them all is more or less the same. Some with PhDs and some with no degrees, and while they often disagree on things, this has been the most functional (and honestly, the most pleasant) team I have been a part of.

The introductory call is pretty straight forward, but I spend more time than most candidates are used to discussing what their ideal work environment is, and communicating that this process would be a two-way street--it isn't just us interviewing them but also them interviewing us.

For the technical test, I give them a program that compiles and runs, and unit tests that fail till you write out a missing function. A document that explains what it needs to do, and there are quite literally thousands of different ways to solve it. If they do it right, the included tests pass, they send it to us and we run some more tests with different inputs. We're primarily a .Net shop, but the program is written in a way where someone not familiar with C# can still do it. We're more interested in their ability to solve problems than to recite encyclopedic knowledge of a framework, so hey are allowed to use the Internet, help from a friend--even reach out to our team for guidance, since these are resources they will have when they work here as well. We also provide them with assistance in setting up a development environment--or give them remote access to one that's already set up.

In Houston, and especially in the energy industry, a typical developer lasts at a company less than 2 years before moving on, and this is almost always because of the terrible culture, or the absolute lack of growth opportunities. My goal is to keep them here for 5. So if I have to spend a month or two training them on the tech stack we use, it's really not that big of a deal. Also, as an organization, we are far more open to new technologies and approaches, since what we're doing is innovating, and we'd rather take a risk and fail than be left behind. It's also much easier for someone who understands the concept of a chair to learn how to say it in another language, than to teach someone who has never seen a chair what it is.

We recruit from all over the country, and at this state if there is still some doubt on our end about abilities, or on their end about the kind of work we do, we pick a (relatively straightforward) task from our backlog and set up a stand alone project that would take one of our developers under a day to work on, and pay the candidate $500 to work on it--whether or not they finish it. A lot of thought is put into the task to make it somewhat similar to the kind of work they could do while they're here. This ends up being a win either way--if they wrote something useful, we could use it in our codebase, since they were compensated for it. If it doesn't, well, it's much better that we know now than after having them fly in to our office. I have had several candidates say, no thanks, this isn't my thing, in which case, no one's time was wasted!

Once someone gets through this part, the rest is all about culture. We fly them in, get them a rental car (or Uber credit), and put them up in a nice hotel. If they haven't been in this area before we also offer to let them stay a few days to look around and get a feel for our city. We bring them in the office and meet with a few of the developers they'd work closely with and have them sit in one of our team meetings to get an idea of the kind of people we are (lots of joking around, gentle ribbing of each other, and likely some unrelated tangents about something dumb). More often than not we end up going out to lunch with some people from other parts of the business so they can meet non-coders as well. The whole thing is pretty laid back, and at no time during the process will someone ask them to write code on a white board, or quiz them on their technical knowledge, since they've already shown us they can solve a problem with a narrow guideline, and also build something with a pretty broad outline.

After the pleasantries are done and we've sent them on their way comes the most important part of the interview--I gather everyone that's had a chance to spend time with the candidate and get their feedback. If it's not an enthusiastic "yes", it's a no. If there's hesitation, we discuss it, but usually it means a no. I still make the final decision, but I usually go for a unanimous "yes" verdict. (The only time things didn't work out for us was the only time I had gone against someone's concerns!)

I have been told by so many people how much they appreciated this approach, especially the few folks that decided not to move forward because of it (not a lot of good surfing spots in Houston, for example). People in my team and the business are going to spend tens of hours every week working with this person--far more than I am. Bring in people that work better together is all win for me.

We have had incredibly good luck with this process. Sure, it takes far more effort and cost than other approaches, but we end up spending far less money in the long run, and we have so many instances where 1+1=3 because of this.

 

Wow, that's such a thoughtful process, especially the focus on culture. Thanks for sharing!

Do you cap a time limit on the take home assignment? For example, something like, please don't spend more than 2 hours on this project. Typically, I've noticed 2-3 hours is a standard, but for unpaid take home projects.

 

We usually check with the candidate on how long they think they will need, and set aside some date that's far enough out for them to do it. I ask them to let us know if they need more than a week, and have had some folks ask for more time than that. That usually doesn't work out, but seeing as we're accepting that their lack of experience in our tech stack isn't a deal breaker, if they're willing to put in more time we're happy to give it to them.

 

I never interviewed with Ardan Labs.

But I do like the way Bill Kennedy approaches the whole process through a simple policy:

Hire fast and fire fast

To me this makes a lot of sense... because you’ll never really know how someone will be “on the job” until they’re “on the job”. Also you never know if you’re interviewing a hidden💎.

Perfect example... John Resig and Yahoo back in the day

 

If anybody is interested, I wrote a post with a quick survey. I've got a short article here: dev.to/spirodonfl/state-of-technic...

This is meant to help the developer community so we can get a better interview process down using some metrics.

 

The interview process has no business assessing anything beyond "can they learn to do the job?" and "are they utterly unpleasant even in controlled environments?" Anything else is just an excuse to let the hiring process come down to the biases of the hiring committee, and I don't think that has to be inherent.

For one, under the current system, we might implement sortition to create a pool of candidates and filter out only the most obviously unqualified. After that, we could do informal, non-technical (or minorly technical) interviews similar to what we have.

IMO, a better solution would be to take the hiring power out of the hands of businesses entirely. Companies discriminate because we allow them to discriminate, we empower them to choose. We might do something else, like establish one of a few national software developer organizations that distribute the supply of developers. This could obviously get more complicated than this comment has time for, but I don't think it's a ridiculous option. If we did that, we could even do things like mandate employee cycling (e.g., an assignment lasts 2 years and then developers go to new ones) to prevent any one company from developing the exclusionary culture we see at major software companies today. It would make discrimination against contract workers a thing of the past.

I anticipate the first comment to be "but how does this interview process find the best candidate?" There is no "best" candidate. The meritocracy is a lie we tell people to launder biases. And even if it wasn't a lie, why does any business deserve to hold out for a "best" candidate? People are starving on the streets for lack of work. All workplaces have hired people who most agree "shouldn't" be there, for one reason or another, and companies survive. The logic even shifts to protect those "lackluster" employees because getting rid of them is more trouble than keeping them. If the current process kicks hundreds/thousands of capable people to the curb, in search of "the best," then the process is meaningless and should not be respected.

 
Sloan, the sloth mascot Comment marked as low quality/non-constructive by the community View code of conduct

Please Visit My Blog Of Programming and Web Development Hi, Guys I am Arpan. A Programmer, Full stack developer and Ethical Hacker. I had Created a Blog Related To Programming & Website development Please Visit. Click Here To Visit