[ChrisMarshallNY]

I was a hiring manager for 25 years.

I never gave one single test, and I could usually weed out the spammers from a quick glance at their résumé. I often hired folks that didn't "hit all the sweet spots" on their CV, because I found them to be eager, energetic and curious.

Had a couple of bad decisions, but very few.

[jefftk]

For the opposite perspective, I work at one of the FAANGs and I've given about 200 interviews. A mix of initial screening interviews and full evaluative interviews. At the screening stage I've interviewed several people who looked great on their resume and were really good about talking about programming and what they liked, but couldn't code even my warm-up problem on the whiteboard. These weren't people who were too anxious to code well in this setting, [1] these were experts in BS. Because the company is very careful/ slow to with firing people, which I generally think has really positive effects on employee well-being, hiring someone like this would be really bad.

Much less extreme, but I've also seen many people who looked very similar in their resumes but were worlds apart in how the coding interview went. Some of them could quickly flush out specifications, asking good questions, talk about why they want to solve the problem the way they did, and fluently write code, while many others struggled in different areas or sometimes all of the areas. This is also really important for figuring out which of them we want to hire, and how badly we want to hire them.

How the interview is run matters a lot, and also what sorts of problems you choose. I think it's really important to choose problems that aren't essentially spending 45 minutes on one narrow knowledge test (especially of the "have you already seen this before" variety), but instead test as many aspects of the person's skills as possible. I want to see how they handle incomplete requirements, simple design, thinking about how to create an output format that is maximally useful to a consumer on another team, naming things, thinking about the runtime of different approaches, thinking about big-O space usage, thinking about back of the envelope space usage in bytes, coding, thinking about edge cases, etc. If I had more time I would want to check code reading, testing, and debugging as well, since these are so important to being an effective programmer, but they're unfortunately much slower to evaluate.

[1] I've interviewed people like that as well, and within the confines of the interview I've been asked to run the best I can do is note that I don't think we're able to evaluate them well this way.

[ChrisMarshallNY]

Thanks for sharing that. I am most interested in working with folks where I can make a difference; not just be a coding cog.

I'm spoiled. In my open-source work, I've done some fairly significant (but still below-the-radar) stuff, and got used to basic, simple, respect; without people trying to wrestle me into some kind of subservient role. That's not to say that we didn't have disagreements. Quite the opposite, in fact. I've done Service for some of the most disagreeable people that you can imagine, and left them happy and enthused.

So I actually looked at a few startups. I have a fairly unique conflux of skills and experience that could make an enormous difference in small teams. What I found, is that they imagine themselves to be "mini-FAANGs," and treat their prospects pretty badly. I know that startups tend to have rather chaotic, personality-laced workplaces (see "working with difficult people," above), but if they can't keep that crap out of their triage interview, then the place, itself, must be a nightmare.

I'm working for free, for a friend. I stepped in, because I watched him being set up by contract houses that were obviously going to do very bad work, for lots of money (they barely hid it; I guess because he's non-technical, and doesn't know better). Since he's doing an NPO, and looking at grants for funding, he can't afford that kind of object lesson.

Instead, he's getting a platform that would make a lot of "big houses" green with envy. For free. This is something that I have a lot of prior art in. It's already pretty awesome, and I've only been working on it for a month.

There's a lot to be said (and gained) by simply treating people with basic respect, and motivating them. The workplace is not the military. If we treat our employees and co-workers badly, they won't stick around. If we treat them well, they could do some pretty amazing stuff.