Interview Nightmares
Now, I’m not a huge fan of these and don’t use them in my own hiring. But as a dev of ~15y experience, still very much hands on, I should be able to handle it.
I found myself drawing an absolute blank. The exercise was nothing too complicated really, but the brain would simply not engage. Nothing was working.
As interviews go it was the worst experience I’ve ever had - I spent maybe twenty minutes in this blocked state but it felt like forever.
So I’m now feeling pretty depressed about job prospects, coding ability, my capability as a human being etc. Sharing or talking about a problem always helps to process it, so I thought 1. Why not do that with anonymous internet strangers, and 2. Why not provide a place for people to do the same. So it would be great if people felt able to share their stories too.
And for those of you also unexpectedly back in the job market: best of luck, you will get there.
19 comments
[ 4.9 ms ] story [ 56.1 ms ] threadIt happens. It's the equivalent of writer's block and the fear of the blank page. Please just don't read too much into individual events.
It had been a while since I'd had this sort of negative experience, and what I would say is it's re-reminded me to make sure my hiring in the future caters for this sort of thing. Particularly for less experienced devs.
Being "good at hiring" -- and hence having better people -- is such an advantage for an organisation, it always surprises me that too often we fall back on seemingly default hiring processes, and we don't look at the sorts of optimisations we could do to help surface the best candidates for a role.
For some context on my question:
I'm part of a startup-ish group of people who, frankly, don't have a tech hiring group. We have ~25 engineers (i'm losing track these days lol), but no real manager-engineer bridge. Which translates to, we have a bunch of people who code but none who know how to hire. Unfortunately, i am one of those responsible for hiring, and i've got no clue what to do.
We've gone through various attempts over the years. I've been part of ~15 hires for the company - most of our current tech side, to one degree or another. We heavily value hiring the "person" - so we try to suss out people values and cultural fit, but i think we really suffer from being able to evaluate the technical ability of the candidate.
We're not worried about hiring the top talent of SF - we probably couldn't afford that anyway. But we do want bright people who can grow in the problems we're solving. This is where i'm struggling to improve on, as a person hiring.
Thoughts?
For ascertaining whether someone meets a technical bar -- the gold standard has to be facilitating some way where they can do some actual work with you. That might be v difficult depending on nature of stack, tech debt, etc. But the closer you can make that sort of process to what would really be happening, the better. Coding exercises really only prove someone is good at coding exercises -- that may or may not have any relevancy to what you do I think.
Really appreciate the reply, that's a great question.
> the gold standard has to be facilitating some way where they can do some actual work with you.
We've actually done this, recently. It worked okay. We identified a few problems with that iteration for us though:
1. We chose real projects, but we felt limited by finding a project where the scope could be small enough for the developer to create it to a meaningful extent and not be bogged down in planning. Projects without meaningful planning however felt so simple that i didn't feel it would challenge anyone. 2. I really hated giving interviews "real" work. Which is to say, it was work we as a company needed - but that felt too easy to be seen as exploiting the applicant - for good reason. 3. I felt disconnected from the applicants mindset. I want to understand how they think on a problem - what things they're skipping for time, what pain points in the application need testing, what things they think need to be abstracted, etc.
I did like how it gave them time to solve the problem themselves. As someone who struggles with.. stage fright (for lack of a better term), interviews are hell for me. I want to hire people even if they're terrified and draw a blank.
My next set of interviews coming up i'm thinking i'll try a combination of a take-home project, but also something pair programmed. Perhaps a take-home, and then we review in a pair program after? I want them to be able to not be under pressure, but i also need some insight on their mind.
Unfortunately i have no idea offhand how to design a take-home that is both simple but not brain dead. I don't want it to take long, i don't want to riddle it with complex algorithm based requirements either. My initial gut is to mock up some requirements - after implementing them myself - that have real world value. How do they choose to abstract database access for unit testing? What do they choose to cache with? Did they consider cache invalidation? Something like this.. i guess.
My final concern is that we'll be hiring for specific languages, but i'd like to be able to hire someone wanting to learn and use those languages. Partially because it promotes growth, but also because it opens the job market. Namely, we're a Rust shop and i don't want to hire only people who know Rust - but i also don't want to hire evaluate someone based on a take-home in another language.
I'm debating offering a pair programming option for the take-home if they're not comfortable with Rust. I would expect their take-home to be far worse, as so many concepts would be new.. so i'm unsure if this would be valuable.
Thanks for the reply, and if you have any more thoughts i'd love to hear them :)
Best of luck on the market!
This is something I'm working on solving:
https://www.srchparty.com/
I once had an interview that was so bad that I asked the manager at the end why he even gave me an interview. He wanted a UI expert. His posting didn't mention that requirement and my resume didn't list that type of experience. It was a huge waste of our time.
Don't worry, there's no way you're a shittier developer than me. Maybe we should form a club.
I did some very basic Android apps before. If I stick with the current job long enough then I should get better at Python and AWS.
Keep building experience, but start studying and applying for other jobs.