this post was submitted on 21 Feb 2025
56 points (93.8% liked)
Technology
63082 readers
3566 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Yeah, that's the first problem here, don't do that.
We do live coding and have them explain their thought process. Working code is nice, but we're really testing communication and reasoning. Coding ability in a given language isn't super important, that can be learned, provided you're good at reasoning.
We blast comp sci questions as well, but we rephrase if they obviously don't have a comp sci background. The point isn't pass/fail though, but more to assess breadth of knowledge.
I don't really care if you know what the L is in SOLID or the term for an iterative alternative to recursion, but I do want to know if you can come up with the search terms for a problem you have.
We ask everyone these questions, and only dig deeper if they give good answers. We're looking to see what role you should have, which might not be the one you applied for. For example, we hired a frontend intern candidate as a full time jr backend due to how the interview process worked out. We also hired someone as mid tier that applied for senior.
If you use AI to answer questions in an interview, you're immediately disqualified. It's pretty easy to tell if they're reading from a script or actually answering honestly, and if it's not, it's easy to fire them in the first few weeks once they prove their incompetence.
If you can fool us during the interview process and produce good code afterward, then I guess good job? I don't really care how you do it, as long as you do the job.
We do in-person interviews when practical, but online works too. You just need to be on your guard more for remote interviews.
Yup, this is what I've always done for interviews.
Technical questions are purely to see what background someone has and how they explain or reason their way to some sort of answer. Its also nice to see if someone will say they don't know something but offer their best guess, which is always a good indicator. I'll usually provide the answer right away after they've answered, both to boost confidence for correct answers and because a quick explanation has a tendency to ease tension, especially if they then relate it to some other knowledge they have or suddenly recall the info with a little help.
The other thing I do is ask questions about disagreements with previous coworkers or managers. If someone starts explaining themselves into being superior to others, it's a red flag. Its nice to get an idea for how someone resolves conflict or what kinds of complications they've run into, but I mostly just want to see how they view themselves compared to others.
I know my approach is sometimes strange to others doing hiring with me, but it's all pulled from my time as an education major (I switched out after 3 years to another degree) and real world teaching experience. Good teachers ask questions to understand how a student learns and what they know broadly, not to get an exact percentage of points. (State/district testing requirements aside)
A new thing I've been trying instead of live coding is having people map out a loose architecture for some sort of API data process or frontend data process, then walking us through it. Its more or less a pseudo coding excercise, but it takes the stress of actual language knowledge away. I'm not sure if it'll stick long run, but it's been an interesting experience.
I like these kinds of questions as well, but I keep it to technical disagreements (i.e. best idea wins) since we have another round where we cover soft skills specifically.
I think this is pretty easy to BS through though.
We usually cover this as a follow up to a live coding exercise, where we ask them, without any code, how they'd adjust the project if the requirements change. How can they optimize for storage size? Lookup performance? As it gets more complex, what can we do to keep it maintainable? If we add feature X, is it better to put that on the FE or BE? Why?
For sure. So far I've only used it for one batch of interviews so I'm not 100% set on it, but we used it as our last round to narrow down between a few finalists and we were already confident they were not people who would BS the excercise.