So many people have these really bizarre and outdated (by not just years but centuries ) notions about how knowledge work gets done. They want to squish it into the model of factory work, but it just doesn't work that way. Knowledge work is typically creative, the right model is an art studio, a movie set, or a band. This makes hiring very difficult, which is exacerbated by the fact that engineers are innately bad at…
> the right model is an art studio, a movie set, or a band > Knowledge workers aren't cogs, they're part of a team. That's a bit ironic because movie sets and bands (almost always) are structured teams with industry standard roles (drummer, audio technician, key grip, gaffer) that make it easy to hire people for the duration of a gig. Developers, analogously, might operate instruments; manufacture their own instrumen…
Hire characters, not skill sets. My most important questions in interviews
61–70 of 117 posts
Re: Hire characters, not skill sets. My most important questions in interviews
#62Earlier quoted context omitted.
> "Do I think this person is a cool person?" No movie director would hire an actor on that basis. Well, considering the amount of work Mel Gibson gets these days (more or less zero), this does factor in a bit. I also gather that studios hire actors for reasons beyond their acting skill quite often. Consider also how many actresses fall off the face of the earth when they hit a certain age. Where's Mira Sorvino? Halle…
Oh give me a break. Those actresses are just taking time off to have children. Nothing wrong with that. There are plenty of successful middle-age actresses.
Mel Gibson took time off? Or he can't find good projects anymore?
Middle age actresses that aren't getting the parts they used to, fairly or not: Elizabeth Shue, Elizabeth Hurley, Catherine Zeta Jones, Nicole Kidman. It's plausible that many just left the business, but they all still act, just in much smaller projects.
There's some of that on the actor side as well. Michael Keaton has had a hard time of it for the most part. I just picked actresses because it's more apparent to me non-acting qualities carry more weight when it comes to actresses.
Re: Hire characters, not skill sets. My most important questions in interviews
#63I sort of like the sentiment but this sort of interview, at least for me, would feel a bit too personal. Look I'm not your friend so let's not pretend that's what this or you just really want to get to know me. No. You just want to know if I can do the job so just get me to do a task which meaningfully reflects what I'd be doing day-to-day then ask me questions about it.
Do you not try to be friends with your colleagues? You spend about a third of your life at work, it seems to me that you should try to make it as enjoyable as possible.
Re: Hire characters, not skill sets. My most important questions in interviews
#64The problem is how to determine how someone is smart. In my company we had this very eloquent, outgoing person who implemented many features very fast. To the eyes of management he was a champ, the king of "shipping". But a little bit later things started to seem weird. Noone was productive except for this person. Only he could understand the code organization because the system wasn't well structured. Then bug repor…
Re: Hire characters, not skill sets. My most important questions in interviews
#65Earlier quoted context omitted.
> the right model is an art studio, a movie set, or a band > Knowledge workers aren't cogs, they're part of a team. That's a bit ironic because movie sets and bands (almost always) are structured teams with industry standard roles (drummer, audio technician, key grip, gaffer) that make it easy to hire people for the duration of a gig. Developers, analogously, might operate instruments; manufacture their own instrumen…
We do have specializations. Backend, frontend, platform x, video software, games, dsp, network protocols, etc
2. There isn't a category on glassdoor.com for network protocol developers. You don't see BLS data breaking salaries out based on the specializations you list.
3. If someone puts out a job listing for 'backend developer', you still don't know what your day-to-day will look like at you new job. Contrast this to 'pediatric nurse practitioner'.
4. We don't say to our bosses, "My specialization is X, but you want me to do Y work. We need to hire a Y person or you need to promote me to 'X engineer' and give me a raise."
5. Managers don't think much of sticking a rookie frontend developer on some backend tasks with no training or mentoring. "You'll review the code before it goes in, right? What's the problem?"
Re: Hire characters, not skill sets. My most important questions in interviews
#66The problem is how to determine how someone is smart. In my company we had this very eloquent, outgoing person who implemented many features very fast. To the eyes of management he was a champ, the king of "shipping". But a little bit later things started to seem weird. Noone was productive except for this person. Only he could understand the code organization because the system wasn't well structured. Then bug repor…
> To the eyes of management he was a champ, the king of "shipping". So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping. But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.
Management loves how fast things are delivered, and boyscout loves the pats on the head. The rest of us hate the countdown until the house of cards comes tumbling down.
I saw a great tweet some time ago that defined a 10xer as an engineer who accumulates technical debt so fast, it takes 10 engineers to fix their mess. That about sums it up, doesn't it?
Re: Hire characters, not skill sets. My most important questions in interviews
#67> It surprised me that people define theirselves via their CV: “Who are you?” -> “Here is what I have done in my professional life!”. Anything weird about that? I wouldn't expect my potential employer to be interested in my family, hobbies or beliefs. So I would respond with job-related stuff as well.
Well, indeed. Traditionally those have been used to discriminate against people. To the point that any competent HR department will ban you from asking women interviewees about children.
Re: Hire characters, not skill sets. My most important questions in interviews
#68Re: Hire characters, not skill sets. My most important questions in interviews
#69Earlier quoted context omitted.
> To the eyes of management he was a champ, the king of "shipping". So management also was bad at their jobs. They probably didn't get canned, though they deserved it as much as the King of Shipping. But, congratulations, you know the "What's Bad About Working Here". Maybe there's a way to train management what their implicit job responsibilities are. I've never seen it happen in the wild, but maybe it's possible.
Management trusted the developer knew what he was doing, and didn't micromanage. I would go as far as say that management should be setting requirements in terms of security, maintainability, documentation etc, but I guess in this case (because apparently it was just one dev), they gave the developer full freedom. Misplaced trust, in this case. In a lot of cases though, I'd rather management ask me what should be don…
You trust teams, not individuals. The smallest possible team (1) to give some responsibility to is three people for this reason. Someone can quit or take a leave of absence and you still have technical accountability, code reviews, meaningful discussions, etc.
The fact that management made a mistake here is understandable. Management needs room to make mistakes, too. The fact that the developer was blamed and fired but the management wasn't held to a similar standard of accountability is the problem.
The code is the product. The management owns the code just as much as that developer did. So does everyone up the chain and anyone in parallel organizations (the business experts, the people that make the budgets, the QA department, etc.).
It's likely, at least implicitly, that the org structure sees some people owning 'the product' and other people owning 'the revenue' and other people owning 'the budget' and the developers owning 'the code'. As if we can separate those things.
If you work for a car manufacturer, everyone needs to know about cars, care about cars, drive cars, learn about cars, and expect good cars to be produced for a nice profit. I think shops that sell software, whether shrinkwrapped or through services, need to have the same attitude about software. If you are in the business of software, you are in the business of code, even if you can't write any yourself.
1) Team loosely defined here. It could be three people from different parts of the company, as long as they all understand the aspects of the system well enough to have a meaningful discussions about it.
Re: Hire characters, not skill sets. My most important questions in interviews
#70Earlier quoted context omitted.
"But a little bit later things started to seem weird." I've met a lot of people who change jobs before anyone realises this - to anyone who works on the same projects they are a nightmare, to everyone else they look like a hotshot.
I have one of these on my team right now, and he has caused me more sleepless nights than anyone I have ever met. Finding it very difficult to get mgmt to understand that most of his code needs to be re-written
[99% of the people I have worked with have never played those kind of political games but I have seen the utter chaos that can happen if a politically savvy operator is let loose in a trusting and politically naive environment.]