Please help me improve how we interview
Posted by gape_ape@reddit | ExperiencedDevs | View on Reddit | 29 comments
As the title states, I am in a position to improve the way we interview technology talent (all levels and disciplines).
Can you recommend resources that can help me?
What are some things you wish were better about the way interviews are conducted?
What are some good interview experiences you’ve had?
Thank you.
Fearless_Imagination@reddit
Who is doing your interviews and what are you looking for?
I can tell you what we ended up doing when we were hiring for a new dev on my last project after some... regret hires:
We did a live-coding assignment - but not leetcode, but one we made ourselves. It specifically tested the knowledge and skills that we, the sr. devs in the team, were looking for. The live-coding part was also done with only the devs from our team (which the candidate would be joining), no managers or other types of non-technical people in the room (or teams call). And of course the meeting would not just be a technical interview, we'd also talk with the candidate a bit to see if we 'clicked' well.
Of course it was not a perfect system - people get nervous when live coding and while we tried to get them to be comfortable, it's not something we as devs are particularly good at... however, everyone who actually made it through this process and ended up getting hired was an excellent fit, both culturally and on technical skill. We may have missed out on some candidates who would have worked out this way, but as I wrote at the start we introduced this process after hiring someone who didn't work out as well as we'd hoped...
Also, a few who made it past this stage then had an interview with the hiring manager and then he said "no" for what we considered to be completely stupid reasons. Like he asked them "if you were an animal, what kind of animal would you be?" and then he didn't like the answer... eventually we switched the order of interviews (hiring manager first), because preparing and doing this kind of live-coding interview took up quite some time from us as sr. devs, and it was a bit of a waste if the hiring manager was just gonna reject them anyway...
So we had 2 interview rounds. That should be enough, I think. I've read stories about having like, 6? Which seems ridiculous. One is probably not enough - or, well, I'd argue that for a dev role you need at least one conversation with only technical people in the room. I'm not sure the conversation with the hiring manager had any actual value, but there was no way we could rid of that one.
What it boils down to, I think, is that we spent a bit of effort on really tailoring the interview process for the position we wanted to fill. And that worked out really well.
Overall-Screen-752@reddit
Something other people aren’t talking about is the post-interview experience. When the candidate doesn’t quite meet expectations, tell them why in exacting detail. Offend them if necessary (politely of course), but be genuine and honest. Getting a rejection is expected part of the job hunting process but getting a rejection with opportunities to improve is a diamond in the rough. Yes, it takes effort on your part. But if you’re making the candidate go through 6 hour-long interviews you could at least explain why that effort didn’t precipitate in an offer.
Its worth considering that in today’s highly connected and transparency oriented society, word of what’s expected should make its rounds about the talent pool and you should, theoretically, see higher-quality candidates in the future
mr_brobot__@reddit
White board leet code in person to mitigate cheating ;)
rayfrankenstein@reddit
Every resume with a github profile gets moved to the front of the line. Have a script scan for it.
Then the repositories that aren’t half-assed get moved to the front of the line. They have unit tests? They get moved to the front of the line. 5,000 github stars? They get moved to the front of the line.
SolidDeveloper@reddit
But why though? Lots of great engineers don’t have personal projects on GitHub.
And a question: would you make it clear in the job ad that their GH profile is very important in the evaluation process? Because I know lots of engineers who intentionally don’t put their GH profiles in their CV, as they prefer to keep their personal projects separate from their professional life.
rayfrankenstein@reddit
It has drawbacks, bur it is a vastly superior alternative to Leetcode.
Four_Dim_Samosa@reddit
debugging interview
give some code that doesnt work bc the unit tests are failing and see how the candidate debugs
you get the benefits of a practical take home but you also keep the scope well defined
TransCapybara@reddit
I honestly think a one-two hour interview with a lunch is the perfect kind.
littlehero91@reddit
You can use codewars to find exercises to give to the new talent to check their basic programming skills.
bluetrust@reddit
Best interview experience I ever had was when a company told me they liked my resume and asked me for code samples, then the tech interview was me walking through the code samples and explaining why I picked them. It really let me showcase my strengths, and that led to an immediate offer.
It was basically a portfolio review like designers have, but for coding. I get it biases toward candidates who are good at communication, have a lot of prior art to pick from (i.e., open-source or side projects), and have good judgement. I still think it's vastly super to on the spot time pressure challenges or weird toy project takehomes where you're supposed to simultaneously make professional code as if it were a big project while also not overthinking it.
avaxbear@reddit
Works terrible for people that work on closed source code bases
ArchitectAces@reddit
You can pick code samples you did not write
FuckAllRightWingShit@reddit
I was forbidden from taking any of my code with me when leaving my last two jobs, and many companies are now leery of even looking at code from another firm’s code base.
I had a nice SQL example I implemented a decade ago which would save us a lot of performance problems, but I couldn’t recall it. My manager said “Do not even look at it - I am not joking.”🙃
So I spent an extra 30 hours that week cobbling it together from scratch.
hooahest@reddit
I would have 0 code samples for them
blacksmithforlife@reddit
This should be ranked higher. Just like the art world, bring a portfolio and have discussions on them. Alternately, the company brings samples and you pair with the person being interviewed on refactoring it.
nikki969696@reddit
For the love of all things holy, don't ask me to do something in the interview that I won't have to do in real life. In real life, I get an IDE, google, chatgpt, and any other number of resources. Let me use them and ask why the heck I'd trust the output of an AI (e.g: unit tests, understanding the code, looking at documentation).
AManHere@reddit
This is a great way of asking questions, sir or madam! No context provided, we don't know how you do interviews now, we don't know what you think works and what doesn't, we don't know the size, scale, location, industry of your company -- is it so easy to give a useful answer without this critical information.
Answer: Did you try asking Gemini?
chaoism@reddit
No leetcode please
AizenSousuke92@reddit
and more than 1 hour take home test
Idea-Aggressive@reddit
3 stage interview max Quick hire, quick fire Check Open contributions if available on GitHub or similar Live test but ppl get stressed it’s normal
crumpet-lives@reddit
Do architecture whiteboarding with draw.io or a take home project thats just a simple to do app. If you give the project, let them have creative freedom to do it how they want while focusing on code quality. Make sure there's a few actual requirements that are super easy so you can see where the candidates' minds go when coming up with ideas. You would be surprised how many dont even bother with the 2 or 3 feature requirements given or how many submit non compiling code for senior positions. After, do a PR and vibe check to see how they react to constructive criticism or you adding your ideas. You can teach tech, not personality. Hire for personality and the rest will come.
El_Gato_Gigante@reddit
I love to have the problem slowly escalate but with clear. It starts with something basic like creating a function or class stub. Each subsequent step escalates until maybe they hit something they can't do, and that's Ok if they have trouble. I never let them flounder, and I'm always talking through the problem as if I were with a co-worker.
I'm looking for a couple of things:
GrizzRich@reddit
Please explain what you are doing. I don’t know what you are doing and therefore cannot help you improve.
Oreamnos_americanus@reddit
If you do a take home, scope the problem so that the expected time to complete is under 2 hours, to be respectful of your candidate's time.
I think all companies should do a behavioral-style interview for senior+ candidates before bringing them onsite. I'm generally able to pass technical screens prior to onsite loops pretty consistently, but I've interviewed with companies where my past experience was never going to pass their leadership/impact bar (without explicit lying on my part) no matter how good my technical skills were, which is often an auto-fail, and it would be nice to tease that out before wasting everyone's time with an onsite.
considerfi@reddit
I'm going to buck the trend and say easy leetcodes are fine, live. I think it's important to see people code, and talk to them about the code. Maybe an easy leetcode with then some modifications - what if...
Also takehomes with an expectation of 3 hours are fine, with a live review (because of ai)
After that, system design is usually valuable.
And then behaviorals, ask people about past challenges and things they've built.
But for the love of god, train your interviewers. The goal of each interview is not perfection, it is different signal.
- Leetcode - the signal here is just "can you code", not can you come up with the magical trick solution that only some scientist 60 years ago originally invented? You want to see just general comfort and know that the person is not just a good talker and didn't make up their resume.
- Takehomes - the signal here is can you code + make tradeoffs. Are they able to explain choices, tradeoffs, where things were ambiguous. Takehomes tend to be all about, what should I do in this amount of time without being able to get further information?
- Note that candidates might use a framework that they are not perfectly familiar with because it's better for a takehome. For e.g. i might use django/drf even though the last backend I coded was Go, because django has built-in functionality. This is good - shows thinking around tool selection for the job. But it also means the answer might not be perfectly written how a django team might do. Again the signal is just "can you code + make tradeoffs" NOT are you perfect with this stack.
- System design - the signal here is higher level engineering mindset. Can you build using modern day tooling and talk to the pros and cons of your solution. Where do you see bottlenecks and reliability based on expected scaling? And what solutions do you have
- I personally think another signal here is can you be practical about it? What is necessary and how will you know when it's necessary? Scaling immediately to 6 services and 6 databases upfront is a stupid idea - but i might be losing the battle here, from what i can tell.
- The point is not to wait for them to say magic words like "grafana" or "kafka" or whatever the flavor of day tool is, tooling can be learned. Watch just for familiarity with types of components and tooling and the ability to reason about them. Everyone says "oh we want people who can build with constraints" and then fail to understand that every candidate's past job is a constraint on the stack they are familiar with, and even though x is current cool thing, that's not what they used before, and they had to solve within the constraint of the tooling they had.
- Behaviourals - the signal here is ownership, creativity, perseverance, progress through ambiguity. Once you know a person can code and think and build, the rest is whether they will come to your job and apply the above to the job. Honestly I think these things are the most important of all but unfortunately you can never get complete signal on these from an interview. Because some people are just good talkers and can prepare answers. So you do your best and try to see passion shine through these answers to make you believe them. I would eaily pass people with weaker stack match if I see passion shine through on these - because these people will pick up and learn what they need to. Vs. the most perfect stack match in the world won't help if you don't have these.
SamPlinth@reddit
Get them to write something simple while you watch. Then ask them to critique their own code - e.g. "What would you do differently if you had more time?"
I find this weeds out a lot of pretenders.
kevin074@reddit
it's helpful to start with what you guys have currently.
to me, I think most issues with interview, especially when you are "improving" the process, is having consensus what is "good enough".
It's important to have the standard set reasonably and agreed upon with all the interviewer.
for example, people HATE take home assignment, but I think it's actually one of the more reasonable asks lol
the main problem with take homes is how many hours is expected.
if you expect 10 hours of work, what should 10 hours look like in the end?
what key points should the candidate accomplish and if they accomplished these are they good enough for next stage?
what if they don't achieve certain things? For example their app isn't fully responsive or looks barebones, is that fair to penalize against a (10 hour) take home assignment?
what red flags can there be? To what severity are each flag?
more importantly, how do you judge someone who spent 20 hours vs someone who spent 10 hours. Are you gonna penalize against the 10 hours?? Is that fair??
notmyrealfarkhandle@reddit
Stay the hell away from Leetcode. Focus on problems that are actually based on real work the engineer will be doing. Assume the interviewee will have ChatGPT open or something similar and ask questions that require a real depth of understanding, or bite the bullet and bring people onsite.
njculpin@reddit
How big is the business?