Hacker News Reader

Hi. I went through the same problem. After passing a hard online test on Codility I had a live coding interview with a much simpler problem I just froze and could not solve on time. I found this article here on HN and it helped me understand what happened. https://news.ncsu.edu/2020/07/tech-job-interviews-anxiety/

Thanks for sharing - and that article is really interesting.

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.

What's a good method of (technical) hiring in your view?

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?

Growth Mindset might be a bit of a wooly term but that tends to be what I look for. I want people who continually get better. There are lots of resources on specific things you can discuss for this. For me, I think simply asking "what was a recent new thing you had to learn" opens up a good conversation.

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.

> I think simply asking "what was a recent new thing you had to learn" opens up a good conversation.

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!

I am fairly competent, am CTO of my nth start-up, have had fairly well paid finance IT work in finance in London with multinational banks, etc, etc, and I have still drawn a complete blank sometimes, and other times have bowled the interviewers (and myself) over!

It 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.

Thank you. Sleeping on it, and writing this post, has definitely bought things back into perspective: we can all have off days.

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.

Don't worry. Even if you're a shitty developer (which I doubt), I'll always be shittier.

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.

Ooof, that sounds awful.

Don't worry, there's no way you're a shittier developer than me. Maybe we should form a club.

I don't think so. Pretty sure it's only a matter of time before I get fired. I'm very demoralized by the past treatment the company has given me. I moved to a new team but they just bounce me from technology to technology with no training (Splunk, Tableau, Python, AWS). This will not allow me to become an expert in anything. They aren't happy with my output. Because my prior experience was FileNet and Neoxam, I don't have any career options.

Sorry friend. I don't have any advice, other than it sounds like it's time for a new job. There are places that will treat you better out there. Maybe put together a side project to learn a new technology that will make you more employable?

Will it really be better at other places? The company I work for consistently makes the top 10 in ComputerWorld's best places to work in IT list.

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.

Best places to work surveys are garbage. Your experience isn't matching what others might feel at the company. It's probably just a bad fit, which is okay.

Keep building experience, but start studying and applying for other jobs.

I suffered a brain freeze at an interview once. My brain freeze was not caused by anxiety, but rather the Office Dog wandering into the interview room, sitting down on my feet and shoving its snout firmly between my legs.

I once forgot how to write a simple join in SQL during an interview. Full blank. It is like forgetting how to tie your shoes. The second I walked out of the building, I instantly recalled the insanely simple task.

That is a perfect analogy!

I recently had an interview where I was supposed to record the screen while I am solving the problem and share it with the interviewer. I couldn't do it. I am one of those people who's mind goes blank when someone is standing behind me and watching over the shoulders. The thought of recording my screen induced the same feelings.

Thanks for posting. We've all been there.

This is something I'm working on solving:

https://www.srchparty.com/

Interview Nightmares