Ask HN: Have anxiety, need help with live coding interviews (funny hat dance)

I've handled several high stress situations on the job. E.g. servers are down, customers are pinging support. Everyone doesn't know what to do.

I've solved problems several times in that environment. I have the battle scars and I'm used to doing that.

I am much more comfortable in a giant legacy codebase that I've never used before, trying to fix a critical bug that is losing the company thousands of dollars per minute than I am during these live coding sessions.

I realize tons of it has to do with practice so I plan to do that.

It's just confusing to have an entire decade of high performance (with references to prove it) to be judged on how well I can dance with a funny hat on.

I'm not whining, I'll do the work. I just don't have time right at this moment, if that makes sense.

I would purchase leetcode premium and start working your way through the top 100 most common easy and mediums. If you are trying to land some FANG job offers, then I would also spend sometime working through the top 25 Hard problems too. But start with easy.

Having been on both sides of the interview process I've tried to think through possible solutions and in doing so I've identified two factors at play.

1. Organizations have to pull busy employees from their work and into interviews which adds even more overhead to the talent acquisition process. Once hired the onboarding and training represents further overhead costs- it's probably not uncommon for a new hire to not be able to render even 80% of their value until ~3-6 months into their new position. In short, even in the best case scenario hiring and onboarding has a lot of costs and represents a sizable investment.

2. In an ideal world a good engineer could just be given the proper time and real-world work to display their value. Due to factor #1 an org can't always take this risk and even if they did could they scale that process? Then if you try to imagine ways to change the coding interviews to more accurately reflect real-world work you might find a better balance but given all the arbitrary constraints which produce all the imperfect simulacrum exercises you're inevitably left with much of the same problems.

Clearly this is an area ripe for innovation (yc alone seems to always have a handful of recruiting/talent related startups in each batch) but those two factors seem to hinder the odds of real disruption.

I think there are also likely more dimensions to this problem. There's a lot of momentum behind these standard practices and it makes me wonder if there are latent motivations held by all various stakeholders to maintain the status-quo.

- The Human Resource actors have their education/training and want to optimize behaviors for their KPI's. Could both their training and KPI's be oversimplified legacy solutions in a "thorny-problem" space that no one has incentives to challenge?

- The Engineering Management actors are often dealing with the chicken-and-egg problem of "I don't have the proper time to try and improve this interview process because both my team and myself are overworked and until I hire more people I won't have more time"- by the nature of growth in tech orgs won't this chicken-and-egg always be occurring?

- The Recruiting Agency actors thrive on looking at the whole process as a numbers game- casting a wide net and pushing candidates through as fast as possible. If they bother to take too much time on higher-touch areas like actually making sure a candidate is a best fit based on many dimensions they sacrifice making the numbers their ambitious counterparts are making next door.

- The Innovative Talent Startup actors need to promise product-market fit, to-market strategy, a large TAM and an outsized ROI which likely means rather than challenging the momentum of this dysfunctional process (and all it's nuanced factors) they're more likely to succeed as a venture by leveraging the momentum and tapping into one part of the process or another.

- The Engineer/Candidate actor enters the process with a sort of unspoken precept that they are in a position of little-to-no leverage and are "unworthy" until proven otherwise (never mind your years of experience). Could this whole shared perception be a vestige of a time when a single employee could not represent enormous, outsized ROI to an organization? Is this just a cultural artifact reinforced by the thin veil of meritocracy that we want to share? Could something like a re-imagined LinkedIn invert this? Could our network of past and present coworkers, managers, etc. vouch for us in a verifiable way using a reputation system to reinforce the integrity of your "score"? Once a system like this proves effective couldn't it supplant most of the hiring/recruiting/talent industry and make everything massively more efficient? (This is mostly a mental exercise just to expose how arbitrary and invisible are the factors that dictate the whole process. I know some wouldn't like the idea of past coworkers dictating your "score".)

In the meantime, and on a more pragmatic level, if I were you and if you're not already, I'd try to start being more up-front with the org from the beginning around the interview process. In the past I've said from the start "I'm very busy at my current job so I don't have time to practice algorithmic puzzles so I hope the coding challenges reflect real-world problems cause if they are the standard algorithmic puzzles I likely won't do well.". I also will reiterate this at the start of the coding interview if I realize it really is just a puzzle from "Cracking the Coding Interview".

Lastly before going into these interviews try and meditate for a moment on how arbitrary the whole process is, how you're just as "victimized" by the process as the people interviewing you and that your value is in no way reflected by such a messy process. Because there's this unspoken agreement that this is a numbers game perhaps you too must, for now, play the numbers game and as such detach yourself from the outcome of any one interview.

They were available to ask questions, but mostly I was there figuring it out by myself.

In this case, I had never used golang before, but by the end of the half day, I had a solution I was happy with.

Sure they took a risk giving me access to the entire codebase... But as a tool to assess my ability it was top notch.

Later, when I was working there, that same ticket got prioritized and it ended up taking 3 or 4 days to solve by other team mates (my solution wasn't quite right).