We hired this guy who wrote a book on the thing the team he was hired for managed. He was a nightmare. He was just insufferable. People would ask questions and he would suggest they read his book. He would mention his book in every meeting. He would tell people they couldn't do things they'd already done and then back-peddle that it wasn't possible when he'd written his book. It was just a huge drag. He managed to also be terrible in other ways and has since been canned. I pity any future applicants that come into an interview with the managers that had to deal with that guy planning to lean on their book during the interview. There's a good 50 people in the company with a real bad taste in their mouths from him.
Similar experience here. We interviewed a guy who kept referring to his book on the subject, experience he gained during writing the book, and so on. We took the bait.
> He would tell people they couldn't do things they'd already done and then back-peddle that it wasn't possible when he'd written his book
This was the core problem: Modern technologies and frameworks move fast. His book was about the state of the art five years ago, but it was woefully out of date for what we were doing. That didn't stop him from trying to exert superiority over the more knowledgeable team members.
Some of us read his book. It wasn't even a great resource on the topic. Re-reading the Amazon reviews, I have to believe most of the positive reviews were bought or fabricated.
Since then, I'm cautious about hiring anyone who tries to portray themselves as an expert in the field. And if you're hiring an author, at least read part of their book during the interview phase.
A former co-worker of mine recounted an experience with a person hired by his previous company who had written a book on software development methodology, Scrum or something. Evidently the way the author's employment worked is the company got the reputation benefit from having a famous expert on staff. In exchange he gave talks but didn't have to do any actual work for the company, and the company didn't have to follow his methodological orthodoxies.
And that's how you end up with speakers saying ridiculous things that don't work in practice. Because they come up with some idea (or more likely, a very minor tweak to an existing idea) but because nobody has to actually do it, and all their time is spent speaking, nobody uncovers the critical flaws.
At my last employer there was a similar story. The candidate mentioned he had written a book on Flask. So the dev in the interview took that as an invitation to skip the warm ups and go on a deep dive into Flask internals. The author got extremely flustered and couldn’t answer.
I don't think this matters. If he strongly claims he is an expert on Flask, and I knew Flask, then I would test the depth of that knowledge. You can't validate every detail on their resume, but if you find they misled about this one fact, odds are they mislead on other facts you are not capable of validating.
Okay, well I guess that’s a bad experience. I don’t think it invalidates the fact the usually book authors should be somewhat knowledgable - of course it doesn’t automatically
mean that all of them is good to work with.
Yes, but... unless you are hiring an absolute EXPERT on that topic and that was the purpose of hiring the person.. I bet that could turn out very poorly.
I mean it's in general like if you hire a PhD into a role that needs to cover a lot of areas, can't be super detailed in anything, and needs to get stuff done as opposed to pure research.. that can turn out poorly.
Super side note - I'm rereading Harry Potter and the Chamber of Secrets (2nd one in series) for fun right now, and this guys sounds exactly like Gilderoy Lockhart.
