Hacker News Reader

Comment by hyperhello | Hacker News Reader

Anyone in charge of hiring should be required to successfully obtain a position somewhere once a year so they know what hell they create.

View on HN

Twice in my career I have applied for jobs that ghosted me, only for a recruiter to bring me in with the same resume for more money.

I don't know many other positions where someone can so easily throw away $25k of the companies money because they just couldn't be bothered to do their job.

Government. Military. Boss doesn't get around to signing the order until the Friday before the exercise. Logistics people are now booking flights/hotels using last-minute rates. 25k is nothing when you are trying to get 100+ people into hotel rooms at the last minute.

Anyone in charge of hiring should be fired if they go more than X days/weeks without actually hiring someone. I've seen people complain that their biggest impediment to growth is getting hires through their own HR departments.

> Anyone in charge of hiring should be fired if they go more than X days/weeks without actually hiring someone.

This kind of attitude is fine at large companies, but it's a good way to absolutely sink your small business.

Small companies don’t have people whose only job is to hire other people. So yes, this is a large company problem. When you’re small, generally everyone is already involved in the hiring process and has a reason for making sure the roles are filled.

I wish it was this simple but you need to fix a lot of things about interviewing culturally before you take a sledgehammer to it all by instituting week by week quotas. “Well they might suck but we need to hire them as the week is almost out!” Seems like a recipe for disaster.

Those in charge of writing interview problems should also be required to interview at other companies once a year.

Those even just asking interview problems should be able to answer those problems in the same time that interviewees are expected to upon seeing them for the first time. I don’t think most can.

You need to ask questions that you can solve in something like a quarter of the time you're allocating for the interviewee, not just the same time. Even if you're interviewing someone with your exact skill set and domain knowledge (and you aren't) there's just a bunch of inherent overhead in presenting someone else with a problem to solve.

This is so obvious but so overlooked. Every time I added an interview question I gave it to engineers at the company whose abilities I knew will and administered it like an interview. If they didn't crush it with plenty of time it didn't make the cut.

I don't know why this isn't more common - why even HAVE interview questions if they aren't trying to learn something in particular and how can you do that without both intent and calibration? I had a lot of strong opinions about the interview process but that usually put me at odds with the people above.

Interviewing sucks. Everyone would benefit from taking a moment and remembering how much it sucks for the humans involved. Bring as much empathy to the table as possible!

I’ve said before that the director of engineering should solve at least one ticket a month. Minor, but still one. Then they wouldn’t spout bullshit like “the documentation should be complete” and “how hard could it be?”

As opposed to saying "how hard could it be" because they actually know.

I don't know you, but when I know exactly (or even approximately) how difficult something is I say "It's [really] not that hard".

Someone saying "how hard can it be" is kind of a flag that they have zero idea of how hard it is or isn't.

Isn't some foodchain is doing that? Developers are expected to deliver food once in a while?

At one start-up developers were expected to a do a shift in the warehouse and delivery.

What is the worst is the director that hasn't touched code in 15-20 years, remembering with rose-tinted glasses and never experienced the organization he is leading.

Reply on news.ycombinator.com