Hire characters, not skill sets. My most important questions in interviews(voss.world)
voss.world
Hire characters, not skill sets. My most important questions in interviews
http://voss.world/hire-characters-not-skill-sets-my-most-important-questions-in-interviews/
116 comments
> 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.
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.
That's the problem, management is bad at their jobs. Management is so bad in the U.S. that everybody imagines they can hire their way out of situations rather than manage their way out of them.
For instance, when you tell people that you went to a Burger King and it took them 30 minutes to serve you a cup of coffee, the conventional answer is "it's hard to find good help these days."
That's a loser attitude on the part of management. Management hires employees, fires employees, trains employees, supervises employees, etc. If management does not take responsibility for your experience as a customer it is definitely the fault of management that you have a bad experience.
The problem has many facets but one of them is that few people are cut out to manage other people and our illusions about "meritocracy" contribute to an American culture that creates excellent foot soldiers but mediocre to terrible officers.
For instance, when you tell people that you went to a Burger King and it took them 30 minutes to serve you a cup of coffee, the conventional answer is "it's hard to find good help these days."
That's a loser attitude on the part of management. Management hires employees, fires employees, trains employees, supervises employees, etc. If management does not take responsibility for your experience as a customer it is definitely the fault of management that you have a bad experience.
The problem has many facets but one of them is that few people are cut out to manage other people and our illusions about "meritocracy" contribute to an American culture that creates excellent foot soldiers but mediocre to terrible officers.
This is the reason why I find "tipping" food servers for "good service" so perverse. the quality of the service you get is almost always a function of how well the place is managed.
Was your hard working server set up for failure by someone making 4 times her wage? A good manager can take a terrible team and make them a great team.
Was your hard working server set up for failure by someone making 4 times her wage? A good manager can take a terrible team and make them a great team.
I usually tip well and complain to management when I get bad service for this reason. Unless business is slow and the server is obviously goofing off in the back or something.
Management is very bad across the board in the US. Very short-sighted and hierarchal culture.
Great leadership is humility and service to those being led. In America the ego worship and adoration for the Type A nutjob stands in the way.
Great leadership is humility and service to those being led. In America the ego worship and adoration for the Type A nutjob stands in the way.
This is my experience. It's a codependent relationship between management who is unable to determine the feasibility of what it's asking for (or, just as often, what it is asking for) on the one hand, and an eager-to-please yes-man of an engineer on the other.
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?
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?
I love that tweet. Although it happens on the management side too. Manager comes in runs a team into ground(that the previous manager spent years building), pushes all kinds of work on other teams as well, takes credit for all of it and keeps getting promoted.
Let's be honest. management probably pushed the guy to ship NOW
Pass on the blame, keep the credit. That's the way to the top in many companies unfortunately.
https://en.wikipedia.org/wiki/Plausible_deniability
https://en.wikipedia.org/wiki/Plausible_deniability
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 done, instead of them telling me (or telling me something I'd disagree with).
> Misplaced trust, in this case.
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.
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.
Yes, but it seems that they didn't extend the same trust to the rest of the team. There surely would have been other people on the team who could have told them that the product was not headed in a good direction if they had just been asked how they felt it was going.
I think the bigger lesson is probably something along the lines of:
First, make sure they can do the job technically, within some sort of parameters of what they can currently do and what can be learned on the job. That's your baseline.
Then, try and suss out if they'd be good to work with. That will come naturally through the way they interact with you in the interview and how they answer questions (whether they are the questions in the article or completely different ones).
If you reckon they tick the boxes for those two major attributes, it's then just a matter of weighing up how much of each attribute they bring to the table and if the balance is right.
First, make sure they can do the job technically, within some sort of parameters of what they can currently do and what can be learned on the job. That's your baseline.
Then, try and suss out if they'd be good to work with. That will come naturally through the way they interact with you in the interview and how they answer questions (whether they are the questions in the article or completely different ones).
If you reckon they tick the boxes for those two major attributes, it's then just a matter of weighing up how much of each attribute they bring to the table and if the balance is right.
Other scenarios are also possible.
I have seen very prepared people from flagship universities that shine in interviews but have zero intention of learning and complying with industry standards and good practices and do not care about details.
Those people also feel entitled to be promoted as quickly as possible, even if they're still too green to understand how software works. This is how bad engineering managers are born.
I have seen very prepared people from flagship universities that shine in interviews but have zero intention of learning and complying with industry standards and good practices and do not care about details.
Those people also feel entitled to be promoted as quickly as possible, even if they're still too green to understand how software works. This is how bad engineering managers are born.
"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'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
This may sound paranoid, but I have seen it happen: make sure the person you are having problems with isn't sucking up to your managers and also making you look bad to them.
[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.]
[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.]
Valuable advice, said individual has indeed already tried this approach with my immediate managers and my peers. Luckily I've been here long enough to have a reputation that can't easily be besmirched
Frankly, if that works and you get fired, you didn't lose much to start with. Sorry, but keeping your job is a different skill set than doing your job.
I've had to opposite experience twice - I got drop-shipped into projects where somebody had gone rogue and I cleaned it up, and then they were let go. It's most unpleasant, and had they been more perceptive they'd have known that's what was going on. In both cases, I believe they were ready to go ( and I lost any trust in the management that used this gambit and left myself shortly).
I've had to opposite experience twice - I got drop-shipped into projects where somebody had gone rogue and I cleaned it up, and then they were let go. It's most unpleasant, and had they been more perceptive they'd have known that's what was going on. In both cases, I believe they were ready to go ( and I lost any trust in the management that used this gambit and left myself shortly).
So this guy was working by himself, with no help, no review, and no one to discuss the implications of anything with. Sounds like a hero for managing it as long as he did.
Except that, if you are not doing well, you need to raise your hand and ask for help in the form of scope negotiation or more resources.
good point.
I got hired on at a job to replace a guy like that. He "got so much done" and "worked so hard" (was at the office late) until he up and left.
Step 1 when I got hired on was to automate away half of what he was doing. I turned processes that were previously three hour projects into five minutes and a shell script. Not many late nights or 16 hour days for me.
Step 2 was to finish all the work he'd left behind. It wasn't unusual to get a bug report coming in "Oh, in screen X when you try and do Y it doesn't work right." only to find that while he'd built an interface, there was no code behind any of it.
Step 1 when I got hired on was to automate away half of what he was doing. I turned processes that were previously three hour projects into five minutes and a shell script. Not many late nights or 16 hour days for me.
Step 2 was to finish all the work he'd left behind. It wasn't unusual to get a bug report coming in "Oh, in screen X when you try and do Y it doesn't work right." only to find that while he'd built an interface, there was no code behind any of it.
Short of more details, this sounds like organizational failure as a whole versus the failure of one developer. Was this one developer the founder or something? It doesn't make sense they got away with so much and no push back from the team?
Should it be one developers job to do more than 20% of the job when it comes to shipping an entire companies products/services?
It feels like you're poo-pooing the idea of a Lone Ranger coder, while being annoyed the person didn't do 100% of the work? If it's supposed to be a team effort, why should they do more than 20% of the job. The rest of the team should be contributing the other 80%.
Sounds like they were there and fired before you even started. So I'm going to have to /dev/null this post as hearsay.
Having a hard time understanding how this isn't downvoted to oblivion. With all the rhetoric here about quality content and posting only that which moves conversations in a constructive way, this ends up being full of holes and after the fact blame gaming. Rarely useful.
Should it be one developers job to do more than 20% of the job when it comes to shipping an entire companies products/services?
It feels like you're poo-pooing the idea of a Lone Ranger coder, while being annoyed the person didn't do 100% of the work? If it's supposed to be a team effort, why should they do more than 20% of the job. The rest of the team should be contributing the other 80%.
Sounds like they were there and fired before you even started. So I'm going to have to /dev/null this post as hearsay.
Having a hard time understanding how this isn't downvoted to oblivion. With all the rhetoric here about quality content and posting only that which moves conversations in a constructive way, this ends up being full of holes and after the fact blame gaming. Rarely useful.
20% of the work meaning implementing only functional requirements and neglecting non-functional requirements. Error handling, monitoring, security, configuration, maintainability, unit testing, performance, scalability, etc.
I think that is a personal responsibility to some extent. Even if you are doing agile or your team is small. If you don't plan to engage those requirements immediately, they need to be communicated to your stakeholders (e.g: in the form of a task in your backlog, though many of these might require refactoring/rework). Stakeholders should be aware of their completion status to make informed decisions around priorities and risk management.
In an analogy, a non-functional requirement is not "adding a room to a house", it is "the construction material and construction standard to build a room". It is not something that can be added later on without rework.
If they mindfully decide to accept the risks of neglecting functional requirements, it's fine, but that's their decision to make. It should not be a surprise later on that those requirements are not implemented.
Then, yes, it was an organizational failure. The person was one of the first hires. But I am talking from the perspective of the article being discussed. Management put the character of the individual over skills in their hierarchy of relevance at the moment of hiring, with the results I mentioned.
Then, it's not "hearsay". Evidence left: tickets, code, etc. Reading code that reflects someone not understanding CS fundamentals is not hearsay.
I think that is a personal responsibility to some extent. Even if you are doing agile or your team is small. If you don't plan to engage those requirements immediately, they need to be communicated to your stakeholders (e.g: in the form of a task in your backlog, though many of these might require refactoring/rework). Stakeholders should be aware of their completion status to make informed decisions around priorities and risk management.
In an analogy, a non-functional requirement is not "adding a room to a house", it is "the construction material and construction standard to build a room". It is not something that can be added later on without rework.
If they mindfully decide to accept the risks of neglecting functional requirements, it's fine, but that's their decision to make. It should not be a surprise later on that those requirements are not implemented.
Then, yes, it was an organizational failure. The person was one of the first hires. But I am talking from the perspective of the article being discussed. Management put the character of the individual over skills in their hierarchy of relevance at the moment of hiring, with the results I mentioned.
Then, it's not "hearsay". Evidence left: tickets, code, etc. Reading code that reflects someone not understanding CS fundamentals is not hearsay.
Badly organized code can also be the result of demanding deadlines coupled with an inexperienced tech lead to back up the engineer's estimates. Sometimes the whole culture of a place (engineers included) is in "just get this shit done" mode until they realize they essentially need to redo everything to fox minor bugs
This like the last couple of applications I have inherited. Layers and layers of complexity built into the application, which could be done in a couple of database calls. It means understanding the code takes way longer than it should, and difficult to redactor, as all the extra layers add complexity and little more.
> So, I am going to say NO to this article. Skills are important.
In your anecdote though, I'm reading that the er, rockstar developer had enough skills to get things done, but not the personality to do things The Right Way. That is a personality thing, I think, with personality traits like attention to detail and quality and such. Those are not linked to skill level or technology; maybe with experience (i.e. being on the receiving end of those bugs and issues), but even that is not necessary IMO, because there's plenty of smart people out there to tell people to do, for example, unit testing, and why.
The wrong personality scoffs at that stuff and goes cowboy coding like the person in your anecdote.
In your anecdote though, I'm reading that the er, rockstar developer had enough skills to get things done, but not the personality to do things The Right Way. That is a personality thing, I think, with personality traits like attention to detail and quality and such. Those are not linked to skill level or technology; maybe with experience (i.e. being on the receiving end of those bugs and issues), but even that is not necessary IMO, because there's plenty of smart people out there to tell people to do, for example, unit testing, and why.
The wrong personality scoffs at that stuff and goes cowboy coding like the person in your anecdote.
Not really a personality thing. The person wasn't an engineer. But was given a chance because of his passion. Very much like what the article encourages.
There is nothing organically wrong with cowboy coding, especially if you're trying to find your footing with a new thing. But it's not sufficient, and probably not necessary.
I have never in my life understood the word smart. Everyone is smart. No one is smart. It's a useless word, and seems overused to me (at least in American English).
You can't get people to stop sorting each other no matter what you do.
It's always the last guy's fault. :)
excuse me while I humble brag and talk about myself for a second
> 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.
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.
In some countries (e.g. Germany), asking such questions violates labor law.
In the US, the questions are not per se a violation of the law, but you are treading on very thin ice because using the answers to such questions in a way that has a disparate impact on anyone because of their gender, age, family status, religion, etc is a violation of the law, even if you did not intend to discriminate against people on that basis.
Just out of curiosity, does it matter what the questions are actually about? Even in the US if you ask a woman if she plans on getting pregnant you're going to have issues. But I would imagine if a woman was answering a general "tell me about yourself" type question and mentioned her kids, the interviewer might ask a follow up, particularly if they have a similar interest or something (obviously staying away from "so are you going to have more?" or whatever).
I'm a guy so I've never been asked about kids until after being hired, and even then just conversationally at lunch.
I'm a guy so I've never been asked about kids until after being hired, and even then just conversationally at lunch.
Agree. If the question is answered 'wrong' by most candidates, then maybe the question isn't so good after all?
This is largely a regional/cultural thing..
In Europe people tend to care more about these things because they're interested in creating a good healthy workplace. If you only wrote about your professional achievements, it would be a sign that your lack of a personality could cause problems within the workplace.
Everyone is different and there is no one-size-fits-all thing here that works for every country / job opportunity.
In Europe people tend to care more about these things because they're interested in creating a good healthy workplace. If you only wrote about your professional achievements, it would be a sign that your lack of a personality could cause problems within the workplace.
Everyone is different and there is no one-size-fits-all thing here that works for every country / job opportunity.
I'm from Europe :) Poland to be exact. And I care about healthy workspcae, but I don't think anything said on interview can be an accurate indicator. It's inherently misleading situation, like a first date almost.
I was only asked similar question once on an interview for a foreign (Lithuanian FWIW) company ("do you have wife, children?"). It was jarring to me, I assumed they wanted to know if I'll be OK with crunch time. Maybe it's the way they asked (like another thing from a checklist).
I was only asked similar question once on an interview for a foreign (Lithuanian FWIW) company ("do you have wife, children?"). It was jarring to me, I assumed they wanted to know if I'll be OK with crunch time. Maybe it's the way they asked (like another thing from a checklist).
And it's also much harder in Europe to fire a problem employee.
This sounds like a cool idea, but I've seen where hiring for personality often leads towards hiring discrimination. I think it's more likely to reinforce the lack of diversity in tech than to combat it as people unlike the interviewer tend to be viewed less favorably and would be less likely to be viewed as a person who could pick up the specific knowledge he/she doesn't already know.
> I think it's more likely to reinforce the lack of diversity in tech than to combat it...
I have mixed feelings about this. I have a hard time valuing diversity for its own sake, especially since there are so many qualities to have diversity in, and especially since the ones that actually affect the organization (like diversity of perspective) are so hard to measure and quantify.
That being said, it's hard for me to sit in an interview and think, "Hmmmm... this is a diversity candidate, so I should ___________." I'm not even sure what to put in that blank. And I feel like I'm already discriminating since I'm already treating this person like a demographic.
So what's the answer? Don't get to know any personalities? Treat everyone like a demographic? I'm not sure that's an improvement.
I have mixed feelings about this. I have a hard time valuing diversity for its own sake, especially since there are so many qualities to have diversity in, and especially since the ones that actually affect the organization (like diversity of perspective) are so hard to measure and quantify.
That being said, it's hard for me to sit in an interview and think, "Hmmmm... this is a diversity candidate, so I should ___________." I'm not even sure what to put in that blank. And I feel like I'm already discriminating since I'm already treating this person like a demographic.
So what's the answer? Don't get to know any personalities? Treat everyone like a demographic? I'm not sure that's an improvement.
The problem the parent post is pointing at is that personalities differ among different groups of people. So that guy who may seem a bit taciturn and therefore, "not a good cultural fit" may actually be a great employee, it's just that in his cultural group it's not normal to be super bubbly and talkative when you first meet someone.
It's not about quotas or diversity for diversity's sake. It's about recognizing that we all bring our own cultural lens to a situation and not being aware of how that influences your perception can lead to judging great people more negatively because they're not like you.
The challenge is that one has to be self-aware enough to recognize their own biases and still make some value judgments on personality.
It's not about quotas or diversity for diversity's sake. It's about recognizing that we all bring our own cultural lens to a situation and not being aware of how that influences your perception can lead to judging great people more negatively because they're not like you.
The challenge is that one has to be self-aware enough to recognize their own biases and still make some value judgments on personality.
Not discriminating against people not like you has absolutely nothing to do with "diversity for its own sake."
Honestly, if when I go in to interview with you, you're already having a mental narrative and discussion with yourself about "diversity candidates", I'd prefer you didn't get to know me. Just ask me technical questions, please; I'm begging for a whiteboard to get out of that. Or a different face to wear when I go to job interviews.
Honestly, if when I go in to interview with you, you're already having a mental narrative and discussion with yourself about "diversity candidates", I'd prefer you didn't get to know me. Just ask me technical questions, please; I'm begging for a whiteboard to get out of that. Or a different face to wear when I go to job interviews.
> I'd prefer you didn't get to know me
I'd prefer not think about it and just get to know people as well. That's what I was trying to get at.
It's disappointing that my attempt to express the catch-22 from my end turns you off to the point of ending the conversation. This is part of the problem with 'diversity' qua 'diversity' IMO.
Culture blew past tolerance and on to something else a long time ago. I'm not sure we want real diversity so much.
I'd prefer not think about it and just get to know people as well. That's what I was trying to get at.
It's disappointing that my attempt to express the catch-22 from my end turns you off to the point of ending the conversation. This is part of the problem with 'diversity' qua 'diversity' IMO.
Culture blew past tolerance and on to something else a long time ago. I'm not sure we want real diversity so much.
> Treat everyone like a demographic? I'm not sure that's an improvement.
That's basically it. We've reduced everyone down to race and gender because diversity. This is the reason for criticizing "culture fit".
That's basically it. We've reduced everyone down to race and gender because diversity. This is the reason for criticizing "culture fit".
Having read through it, I think he's trying to hire for fit with himself and his team. An inbuilt assumption is that the candidates are capable of doing the role - he mentions going through their CV, or perhaps he's already covered off skills. I don't think he's saying that skills to do the role aren't required: so he's not hiring graduates and then giving them the skills for the job, for example.
It's a tough one, if you don't look at whether a candidate could fit within the team (in this case they care about 'passion') then you're storing up problems on the team dynamic front. On the other hand, as you point out, it's difficult to hire on personality without subconsciously hiring people you like which is often people like you: which means less diversity.
It's a tough one, if you don't look at whether a candidate could fit within the team (in this case they care about 'passion') then you're storing up problems on the team dynamic front. On the other hand, as you point out, it's difficult to hire on personality without subconsciously hiring people you like which is often people like you: which means less diversity.
I feel like it's telling that he refers to the candidates as guys throughout
If you mean the article, then I disagree, for I read him as using this person, candidate, and even the gender neutral "them" in the singular.
As for "guy," the word is like nation and nationalist: it must be read in context: nation can mean Kurds and Quebec, or Iraq and Canada. Yes, if you want Quebec to separate then you are a nationalist, and if you want Canada to stay whole then you are a nationalist.
In talking to two women I can mention a gorgeous guy in my classroom and then ask, "Are you guys going to the concert?"
As for "guy," the word is like nation and nationalist: it must be read in context: nation can mean Kurds and Quebec, or Iraq and Canada. Yes, if you want Quebec to separate then you are a nationalist, and if you want Canada to stay whole then you are a nationalist.
In talking to two women I can mention a gorgeous guy in my classroom and then ask, "Are you guys going to the concert?"
Maybe, but my mantra is a mix. I use standard technical questions ect. to weed out candidates that cannot do the job - I try to stay general such that I see problem solving, rather than certification. Then I'm left with a pool of people that are real potential hires. After that I'm looking for a learner with the right mindset, and THEN I'm looking for a fit - preferably someone who will complement the team, rather than reinforce what is already working.
Hiring is not an exact science, and what works for me, is probably not working for others.
Hiring is not an exact science, and what works for me, is probably not working for others.
> This sounds like a cool idea, but I've seen where hiring for personality often leads towards hiring discrimination.
You also discriminate against applicants who don't seem to be very capable in programming or seem to have really toxic personality traits (which is a good idea). How do you come to the idea that discrimination that "hiring for personality" is biased to leads to worse outcome?
You also discriminate against applicants who don't seem to be very capable in programming or seem to have really toxic personality traits (which is a good idea). How do you come to the idea that discrimination that "hiring for personality" is biased to leads to worse outcome?
Discrimination in employment law only refers to specific classes of people based on race, religion, gender, military service, etc. Passing up on someone who isn't qualified for a job isn't discrimination.
"Hiring for personally" can result in "hiring potential drinking buddies" which means your hiring may skew towards people who share your race, gender, creed, and religion because humans usually pick people like ourselves for friends. This can become a positive feedback loop.
If your hiring practices are discriminatory that is illegal.
"Hiring for personally" can result in "hiring potential drinking buddies" which means your hiring may skew towards people who share your race, gender, creed, and religion because humans usually pick people like ourselves for friends. This can become a positive feedback loop.
If your hiring practices are discriminatory that is illegal.
> Discrimination in employment law only refers to specific classes of people based on race, religion, gender, military service, etc. Passing up on someone who isn't qualified for a job isn't discrimination.
A central idea of empirical science is Occam's razor. (Nearly) all religions violate this principle since they introduce assumptions that are not necessary. With this argumentation one can easily argue why a religious person could not be qualified for a job in empirical science.
A central idea of empirical science is Occam's razor. (Nearly) all religions violate this principle since they introduce assumptions that are not necessary. With this argumentation one can easily argue why a religious person could not be qualified for a job in empirical science.
I 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.
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.
There is a difference between maintaining a cordial working relationship, and being friends. I certainly don't go out of my way to be rude to my colleagues. But I don't pretend to be their friends. To illustrate the difference, my friends and I often have rather vehement political discussions. But I would never try to have such a discussion with my colleagues. It would just get in the way of getting on with the work at hand, and would potentially lead to hard feelings that would lead to difficulties at work later on.
In some ways, I find it's more enjoyable to not be friends with my colleagues; to keep my personal life and work life as widely separated as is feasible.
In some ways, I find it's more enjoyable to not be friends with my colleagues; to keep my personal life and work life as widely separated as is feasible.
It's not really about that. I have many friends from wor. Though I tend to become better friends[1] with people once I've stopped working with them... Too many work orgs expect you to be a certain way politically/philosophically and even asking questions can be seen as a sign of you're-not-one-of us, so in a way work relationships are always tainted.
But really this is just more a case of I wouldn't be comfortable talking about my deepest desires with a random person. Sure, once I get to know someone a bit, I'm fine to do that...but a random interviewer? Eugh.
[1] That said, my Russian partner would not consider them friends. Friends in her world are people you can count on for anything and how many of us can say that about our colleagues?
But really this is just more a case of I wouldn't be comfortable talking about my deepest desires with a random person. Sure, once I get to know someone a bit, I'm fine to do that...but a random interviewer? Eugh.
[1] That said, my Russian partner would not consider them friends. Friends in her world are people you can count on for anything and how many of us can say that about our colleagues?
Being friends with colleagues can lead to less enjoyable work situations, not to mention less focused work.
Being friendly should suffice, not all of us want to get too personal with the same people we might need to have professional arguments with.
We're all different.
Being friendly should suffice, not all of us want to get too personal with the same people we might need to have professional arguments with.
We're all different.
I'll share a bit of wisdom my son shared when he was 4 or 5. In kindergarden they talked about what a friend is, and he said after some thinking: "A friend is a person you can disagree and fight with, and still play with later".
A professional is someone you can disagree and fight with, an still work with later.
Getting that close to all my coworkers would be too daunting a task.
Edit: Not to belittle your son's wisdom, of course. I totally agree.
Edit: Not to belittle your son's wisdom, of course. I totally agree.
It was merely that "it's okay to befriend a coworker, and if it doesn't work out, was it really a friend anyway?" kinda thing.
I think he mostly got it from my wife and I sitting down with our children after having a fight and telling them that we're still mom and dad, we've put it behind us, and it's okay not to get along all the time.
I think he mostly got it from my wife and I sitting down with our children after having a fight and telling them that we're still mom and dad, we've put it behind us, and it's okay not to get along all the time.
your son is smart. he will a go way.
I try not to be friends with my colleagues. Friendly? Absolutely. Friends? No.
"Gladiator, make no friends of gladiators" - roughly from "Spartacus".
Of course, intra-office competition at that level is highly destructive but that's what people are acculturated to.
Of course, intra-office competition at that level is highly destructive but that's what people are acculturated to.
there are some mega weirdos out there and sometimes it's best to just not ask.
"hey, what'd you do this weekend?"
"well, my friends and I run a historical re-enactment society where we all go to this remote retreat in the mountains, dress up as Nazis, and pretend that they won World War 2."
and you know what, if it was possible to just hold your finger down on the "rewind time" button for 15 seconds to just never ask this kind of friendly question, life would be so much easier. how do you reply to this? just stay out of other peoples business if you have to work with them.
"hey, what'd you do this weekend?"
"well, my friends and I run a historical re-enactment society where we all go to this remote retreat in the mountains, dress up as Nazis, and pretend that they won World War 2."
and you know what, if it was possible to just hold your finger down on the "rewind time" button for 15 seconds to just never ask this kind of friendly question, life would be so much easier. how do you reply to this? just stay out of other peoples business if you have to work with them.
You just need to get use to the admittedly unfashionable idea that it is possible to like people for some reasons and dislike them for other reasons.
while true, now I need to put up with hearing about what's new in the world of Hitler re-enactment until I quit the company. if I hadn't tried to be friends with this person, that wouldn't be a problem because we'd just be talking about PHP.
Who do you eat lunch with? After 7 years I became pretty good friends with a lot of my co-workers. We went to hockey games and other activities.
You can't be friends with your colleagues. There's too much to lose if you say something politically incorrect and they react negatively.
It's not about being friends in a strict sense.
I think the significant concept is that in the long term, there are very strong similarities between the mechanics of being a coworker, and those of being a friend.
So definitely it makes a lot of sense to "investigate" that way.
I think the significant concept is that in the long term, there are very strong similarities between the mechanics of being a coworker, and those of being a friend.
So definitely it makes a lot of sense to "investigate" that way.
> You just want to know if I can do the job
This holds two things constant: You and the job.
On-the-job training is inevitable. The question is what you'll primarily be trained in: Office politics, or some other skillset which will actually go on your resume.
Similarly, the job will inevitably change if you're around long enough, and that's the nub of the meat of this: It's an old adage that you should never marry someone to try and change them, because people don't change, they just become like they are, only moreso. Both ends of the equation change, but they change around a solid core which was formed decades ago and will not be modified except through some serious event.
So personality matters quite a bit if you're looking for a marriage. If you're looking for a hookup, it only matters on the extreme ends of the bell curve.
This holds two things constant: You and the job.
On-the-job training is inevitable. The question is what you'll primarily be trained in: Office politics, or some other skillset which will actually go on your resume.
Similarly, the job will inevitably change if you're around long enough, and that's the nub of the meat of this: It's an old adage that you should never marry someone to try and change them, because people don't change, they just become like they are, only moreso. Both ends of the equation change, but they change around a solid core which was formed decades ago and will not be modified except through some serious event.
So personality matters quite a bit if you're looking for a marriage. If you're looking for a hookup, it only matters on the extreme ends of the bell curve.
A few people in bad marriages around here...
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 hiring other engineers without a lot of training or carefully focused self-improvement.
Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. But if you change the parts, you get a different team that does different stuff, or maybe doesn't even work at all. One of the big factors here is that if you think you can replace one person with just another person you're often wrong. Best case scenario you end up with something else (maybe better), worst case scenario is you can't replace the unique factors that made the previous person successful in that role (and realistically you need a team with a different breakdown of skills, different mechanisms of interconnectedness, etc. in order to have something functional).
The band analogy really helps here a lot. Realistically when you change members of a team you don't end up with something like Steve Perry stepping into the lead singer role of Journey. What you end up with is something more like Fleetwood Mac being transformed by merging with Buckingham Nicks or Genesis changing after Peter Gabriel left. You end up with a very different thing doing very different stuff. And the higher caliber the people the bigger the difference is.
What knowledge workers actually do day to day and what it says on their job description they do are often very different things, and you ignore that at your peril. Hiring based on the idea that knowledge workers are automatons with certain functionality modules installed is one of the easiest and most common ways to completely sabotage productivity and execution.
Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff. But if you change the parts, you get a different team that does different stuff, or maybe doesn't even work at all. One of the big factors here is that if you think you can replace one person with just another person you're often wrong. Best case scenario you end up with something else (maybe better), worst case scenario is you can't replace the unique factors that made the previous person successful in that role (and realistically you need a team with a different breakdown of skills, different mechanisms of interconnectedness, etc. in order to have something functional).
The band analogy really helps here a lot. Realistically when you change members of a team you don't end up with something like Steve Perry stepping into the lead singer role of Journey. What you end up with is something more like Fleetwood Mac being transformed by merging with Buckingham Nicks or Genesis changing after Peter Gabriel left. You end up with a very different thing doing very different stuff. And the higher caliber the people the bigger the difference is.
What knowledge workers actually do day to day and what it says on their job description they do are often very different things, and you ignore that at your peril. Hiring based on the idea that knowledge workers are automatons with certain functionality modules installed is one of the easiest and most common ways to completely sabotage productivity and execution.
Knowledge work is typically creative, the right model is an art studio, a
movie set, or a band.
Knowledge workers aren't cogs, they're part of a team.
And that's exactly what those "silly" whiteboard puzzle problems are. They're an audition. Just like actors who have to say silly phrases with emotional inflection, just like bands that require new members to play some random short pieces, and just like football players who have to post their times on 40-yard sprints. Now you can argue that the auditioning process should be improved; that right now the skills exercised with the audition aren't the same ones used by a working programmer and I'd agree with you. I do feel like the process of auditioning for a software development role can be improved. But the way to do that is not to abandon the process entirely and just go with some kind of ill-considered gut feeling about "how much do I like this person?" The way to do it is to make it such that the interview more closely resembles the job the person will be asked to perform.
> "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 Berry? Jennifer Garner? Jessica Alba? Did they suddenly forget how to audition?
Considering all the TV shows where the actors are cast by the 8x10 glossies, it might even be the default to undervalue auditions.
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 Berry? Jennifer Garner? Jessica Alba? Did they suddenly forget how to audition?
Considering all the TV shows where the actors are cast by the 8x10 glossies, it might even be the default to undervalue auditions.
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.
> 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.
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.
> 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 instruments; compose and/or improvise music; manage their own careers; negotiate their own contracts; edit their own recordings; package their own work for distribution; distribute their own work; and even perform their own focus group studies. Sometimes there's no time to figure out all those things out so you have to pick up one of the instruments of your predecessors and play something useful immediately.
I can perform the same exercise for film production, sports teams, and surgical centers. One of the big problems with software development is that we don't have distinct roles. Everyone is a developer/coder/engineer. It would be as if the entire music industry were executives and music developers. Or the entire film industry were producers, directors, and film engineers.
Anyway, I actually agree with you underlying point that the health of a team trumps the skills of a team every time. And since the structure of a software team is so fluid, cohesiveness and cooperation is actually more important than it is in 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 instruments; compose and/or improvise music; manage their own careers; negotiate their own contracts; edit their own recordings; package their own work for distribution; distribute their own work; and even perform their own focus group studies. Sometimes there's no time to figure out all those things out so you have to pick up one of the instruments of your predecessors and play something useful immediately.
I can perform the same exercise for film production, sports teams, and surgical centers. One of the big problems with software development is that we don't have distinct roles. Everyone is a developer/coder/engineer. It would be as if the entire music industry were executives and music developers. Or the entire film industry were producers, directors, and film engineers.
Anyway, I actually agree with you underlying point that the health of a team trumps the skills of a team every time. And since the structure of a software team is so fluid, cohesiveness and cooperation is actually more important than it is in a band.
We do have specializations. Backend, frontend, platform x, video software, games, dsp, network protocols, etc
1. We don't introduce ourselves at parties as DSP developers.
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?"
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?"
> Knowledge workers aren't cogs, they're part of a team. You shouldn't expect that you can easily find replacement people with exactly the same skillset and propensity as someone else to make up the gap that an absence makes in a team. Nor should you expect that the proper way to grow a team is by cloning the skills of some other existing member of the team. A team works cooperatively, and their skills, talents, experience play off one another to gel together into some sort of mechanism that is capable of doing stuff.
Great comment, I totally agree that taking a wholly mechanistic view of how individuals and teams work is an error. You can't account for all the 'magic' that make some teams function in ways that are more than the individual parts.
Of course, you're striking at an underlying fear for managers. Our jobs are to make things work immaterial of the individuals: positively a managers job is to make the system of people/process/systems work, and negatively to make sure that no individual should be so indispensable for the project/department/organisation. This mechanistic view generally works because most roles are 90% perspiration and 10% inspiration, as the saying goes.
Perhaps a good mix is that when a hole is created in the team, to look at the situation holistically. As the short-list of candidates is drawn-up consider how they could fit into the mix, and how they would be additive - not the same as previously, but a new opportunity - like a new ingredient, rather than a replacement cog. It reinforces the idea of having more peers from the group involved in the hiring as this could open up a range of opinions on how the mix could change.
Great comment, I totally agree that taking a wholly mechanistic view of how individuals and teams work is an error. You can't account for all the 'magic' that make some teams function in ways that are more than the individual parts.
Of course, you're striking at an underlying fear for managers. Our jobs are to make things work immaterial of the individuals: positively a managers job is to make the system of people/process/systems work, and negatively to make sure that no individual should be so indispensable for the project/department/organisation. This mechanistic view generally works because most roles are 90% perspiration and 10% inspiration, as the saying goes.
Perhaps a good mix is that when a hole is created in the team, to look at the situation holistically. As the short-list of candidates is drawn-up consider how they could fit into the mix, and how they would be additive - not the same as previously, but a new opportunity - like a new ingredient, rather than a replacement cog. It reinforces the idea of having more peers from the group involved in the hiring as this could open up a range of opinions on how the mix could change.
There is always a good debate on HN about hiring, but it feels like we really are comparing apples to oranges here.
Hiring tactics depend heavily on the size of the organisation. They have to: for a 3-people startup you want someone who will break walls and get stuff done, for a thousand-people-heavy dev team you need people who can do one job very precisely. Those tasks require very different personalities, so naturally, very different hiring questions.
Hiring tactics depend heavily on the size of the organisation. They have to: for a 3-people startup you want someone who will break walls and get stuff done, for a thousand-people-heavy dev team you need people who can do one job very precisely. Those tasks require very different personalities, so naturally, very different hiring questions.
This applies to almost everything. The really hard problem is recognising when the heuristics that worked in the past are now broken.
So candidates where preparing for "what's your biggest weakness" and now they have to prepare for a twist of the also common "tell me about yourself"? again this question filters for people who practiced the question and are enthusiastic (or fake it).
I'm not sure what your complaint is. You will have a better time passing interviews if you are comfortable talking about yourself - strengths, weaknesses, experiences, goals, etc.
Enthusiasm is good. Faking enthusiasm is still better than crossing your arms and demanding you be judged on your GitHub profile alone and not have to answer questions about yourself.
Enthusiasm is good. Faking enthusiasm is still better than crossing your arms and demanding you be judged on your GitHub profile alone and not have to answer questions about yourself.
Not complaining, only stating that common questions can be trained and faked, diluting their value. Of course letting you explain yourself about what you are good at etc is better than narrow tricky questions, at the end there's only so much you can learn from a person you just met in one hour. Asking a candidate about themselves is good, is just no silver bullet.
Agree 100%. Too much focus on happening to have encountered the particular skills you ask about in the technical grilling. Rather, hire smart people you'd like to work with (and who have demonstrated a capacity for learning).
The problem with that strategy is that all too often, "smart people you'd like to work with" equates to male, white, upper-middle-class, with a fondness for beer.
Or "plays golf/football, comes from a similar background to us", where gender doesn't play a role, not even in the much-reported IT industry where there is a paucity of women .
As a Brit in central Europe I have come up against this, not to the same extent as someone who isn't white, or comes from a markedly different culture, but the differences in culture even between some European nations can be enough that employers do not perceive me as "one of them".
What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings?
A lot of IT people are so similar in personality, skills, hobbies etc that they all fail in the same areas, not just succeed in those areas. My own work place could be better, and produce a better product, if everyone wasn't so like-minded, imo.
As a Brit in central Europe I have come up against this, not to the same extent as someone who isn't white, or comes from a markedly different culture, but the differences in culture even between some European nations can be enough that employers do not perceive me as "one of them".
What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings?
A lot of IT people are so similar in personality, skills, hobbies etc that they all fail in the same areas, not just succeed in those areas. My own work place could be better, and produce a better product, if everyone wasn't so like-minded, imo.
> What happened to hiring people who are not like us, because that's where the challenge lies and life is better when we are forced to evaluate our own misgivings?
I think for many situations that comes down to three things:
a. People who don't agree that hiring for diversity is good.
While every manager knows that diversity is important (as demonstrated by their responses to HR and while on a training course) I don't believe it's as internalised as people say. Most people subconsciously have strong beliefs of how "people like us" will work together.
b. Risk aversion amongst hiring managers
Commonly teams have more work to be done than people available: ever known a hiring manager not in a hurry to get a new person in? Taking a perceived risk to hire someone different - whatever that difference is from skillset, gender or background - may not be rewarded when higher management want specific objectives achieved. While in principle it might be nice, pragmatism often dictates that managers go with what they know.
c. Inability to measure hiring outcomes
How do you measure whether more diverse teams, or occasions when you took a risk worked out? If an individual is successful is that down to good hiring, or is it just random as that particular team happens to be doing well at that moment. It's very difficult to be evidence based in hiring. Consequently, everyone has heuristics for what they think is useful, but there's not much backing it up except gut feel. For example, what evidence is there that people having a "passion" outside work and doing side-projects is inherently better ... none that I know of ... but something that lots of developers and technical managers ask about and a key reason candidates build-up profiles on Github.
I think for many situations that comes down to three things:
a. People who don't agree that hiring for diversity is good.
While every manager knows that diversity is important (as demonstrated by their responses to HR and while on a training course) I don't believe it's as internalised as people say. Most people subconsciously have strong beliefs of how "people like us" will work together.
b. Risk aversion amongst hiring managers
Commonly teams have more work to be done than people available: ever known a hiring manager not in a hurry to get a new person in? Taking a perceived risk to hire someone different - whatever that difference is from skillset, gender or background - may not be rewarded when higher management want specific objectives achieved. While in principle it might be nice, pragmatism often dictates that managers go with what they know.
c. Inability to measure hiring outcomes
How do you measure whether more diverse teams, or occasions when you took a risk worked out? If an individual is successful is that down to good hiring, or is it just random as that particular team happens to be doing well at that moment. It's very difficult to be evidence based in hiring. Consequently, everyone has heuristics for what they think is useful, but there's not much backing it up except gut feel. For example, what evidence is there that people having a "passion" outside work and doing side-projects is inherently better ... none that I know of ... but something that lots of developers and technical managers ask about and a key reason candidates build-up profiles on Github.
> While every manager knows that diversity is important I don't believe it's as internalised as people say.
I don't think demographic diversity is a value (1), and I don't think many people treat it as a value to itself. The fact that people have to explain why it's valuable is telling. I think most of what you wrote supports the sentiment that diversity is a (purported) means to an end and not an end to itself.
For example, in many cultures, integration of diverse types of people (vaguely defined) is not valued at all. Are we interested in making sure we have proportional leadership positions for these sorts of people? Seems like we're being ethnocentric even by valuing diversity.
1) There is a lot of explanation I could go through there that would detract from my point. Please assume I'm not a bigot to save me the typing and you the reading. Though I could write it all out if people care that much.
I don't think demographic diversity is a value (1), and I don't think many people treat it as a value to itself. The fact that people have to explain why it's valuable is telling. I think most of what you wrote supports the sentiment that diversity is a (purported) means to an end and not an end to itself.
For example, in many cultures, integration of diverse types of people (vaguely defined) is not valued at all. Are we interested in making sure we have proportional leadership positions for these sorts of people? Seems like we're being ethnocentric even by valuing diversity.
1) There is a lot of explanation I could go through there that would detract from my point. Please assume I'm not a bigot to save me the typing and you the reading. Though I could write it all out if people care that much.
I totally agree that the lack of diversity and geek monoculture are a problem. It's not easy to feel at home when people huddle around a rather limit set of topics, humour, music and whatnot, and you find yourself outside of that little sphere. It's the main reason I'm hoping/planning for an exit from the IT world in n years from now, even though I am a white male – even like beer – and so should fit many a stereotype.
Having worked in different countries and companies, I'm not so sure nationality or gender make that big a difference (at least in western/northern Europe). Other industries also have mono-culture problems, but I guess geek culture is highly specific – almost a world on its own – and IT has a lot of people who are not very interested in or are bad at social interaction.
A lot of managers hire with a very specific task in mind, because it's probably easier to logically match a person to a concrete function or problem. In the long run, it would be a much better idea to hire people who can actually come up with new ideas, solutions and products... But it's much riskier to predict creative output and the value of ideas.
Too many people are made manager "by default" because they've worked in the company for a long time or because of their age, and not because they are actually good with people or building diverse teams that can tackle complex problems in an original way.
Having worked in different countries and companies, I'm not so sure nationality or gender make that big a difference (at least in western/northern Europe). Other industries also have mono-culture problems, but I guess geek culture is highly specific – almost a world on its own – and IT has a lot of people who are not very interested in or are bad at social interaction.
A lot of managers hire with a very specific task in mind, because it's probably easier to logically match a person to a concrete function or problem. In the long run, it would be a much better idea to hire people who can actually come up with new ideas, solutions and products... But it's much riskier to predict creative output and the value of ideas.
Too many people are made manager "by default" because they've worked in the company for a long time or because of their age, and not because they are actually good with people or building diverse teams that can tackle complex problems in an original way.
Hi! actually I am the author of the artile ;-) My team looks like this:
4 female one more to come
26 male
among these 30 people i have 15+ nationalities. I am a meat lover and drink beer....I have at least 4 people that absolutely never drink and 3 of them are vegetarians. Just by following my principle "smart people that i like to work with" I created a very diverse team. I think the point is: I like to work with people who are different to me, who challenge me, who make me grow as a personality because I learn something new from them. So the key is hidden in the "that i like to work with" and in the definition of "liking someone" ;-)
Probably depends on the interviewer.
So all interviewers are male, white upper-middle-class with a fondness for beer?
Good to know.
Good to know.
Not all, but the vast majority fit exactly that profile. It's not difficult to find evidence of that, just Google for <insert any of hundreds of studies and internal diversity reports by major Silicon Valley companies here>.
So yes, they point about "hiring for character might bias the outcome" is still valid.
So yes, they point about "hiring for character might bias the outcome" is still valid.
I guess, as a person not in the SV sphere, I don't really agree. Maybe I missed the implied SV context.
This is HN, a community consisting mostly of middle-upper-class white males orbiting around SV.
If you replace "white" with "white, Indian or east Asian" then you are pretty darn close.
Why is that a problem?
> Too much focus on happening to have encountered the particular skills you ask about in the technical grilling.
I agree somewhat, but I've seen many people making mistakes, learning on the job what not to do, and making the entire team learn from their mistakes. So there definitely needs to be some technical experience at the helm of the team to make sure any technical mistakes can be corrected without undue effort.
In other words, knowledge, intelligence, understanding, and wisdom are all different things. I'm very excited to hire smart, humble people, but only if my org has some defenses against well-meaning people that are trying out some new technology for the first time. And if a good chunk of the team is smart, inexperienced people, even diligent code review doesn't really cut it.
I agree somewhat, but I've seen many people making mistakes, learning on the job what not to do, and making the entire team learn from their mistakes. So there definitely needs to be some technical experience at the helm of the team to make sure any technical mistakes can be corrected without undue effort.
In other words, knowledge, intelligence, understanding, and wisdom are all different things. I'm very excited to hire smart, humble people, but only if my org has some defenses against well-meaning people that are trying out some new technology for the first time. And if a good chunk of the team is smart, inexperienced people, even diligent code review doesn't really cut it.
Wow.. I feel super provoked by the question "What's cool about you?". I wonder why..
Probably because being 'cool' is highly subjective and of marginal, perhaps even negative, relevance to doing valuable work.
It is presumptuous and pretentious: 'Are you good enough by my own arbitrary and vague standards to be around me' is the underlying question.
It is presumptuous and pretentious: 'Are you good enough by my own arbitrary and vague standards to be around me' is the underlying question.
big grain of salt with this one.
mr. voss has only ever worked for one company, maxed out as head of IT, team of 35.
so his sample size is rather limited.
mr. voss has only ever worked for one company, maxed out as head of IT, team of 35.
so his sample size is rather limited.
well, you are right. I built up and worked only for one company. Why exactly do I need a bigger sample size in order to write down how I recruit, how and what I learned about interviews and what has worked for me and what has not? I am not stating that I have a solution for every situation or every company on the planet. Take it as what it is meant to be: a possibility to reflect your own interviewing behaviour and perhaps taking one or two new ideas with you :-)
In my experience interviews are not the main place to evaluate technical skills, people get nervous and asking too specific technical questions is not good also, some people can be good at remembering then but can not do anything with then.
I came to the idea that to interview/hire/select a software engineer he/she should show at least three bug fixes on any opensource project and if the fixes are way back the interview/job advert the better. So one can at least have a concrete idea of the candidate skills/interest when confronted with a third party code base and how she/he understood/solved the problem.
This way the interview can be used to access other important aspects of the candidate.
I interviewed several people that seem to have paid someone to write their C.V. very well but when in person was a lost of time.
This way the interview can be used to access other important aspects of the candidate.
I interviewed several people that seem to have paid someone to write their C.V. very well but when in person was a lost of time.
Bug fixes and such don't really tell much either though. We do hiring via an assessment, where people need to implement (parts of) an application similar to a real-life thing; involves things like creating a REST / JSON api, etc. The trick is we don't tell them exactly how to implement it (language, environment, secondary requirements are all left up to the applicant).
This really weeds out the candidates; better than fizzbuzz, better than live coding. Of course there's a chance that someone copies stuff off the internet, but that's what the actual interview(s) are for, just ask some questions about the implementations and the why and such.
We've hired people that did it in python, node, ruby, even J2EE. Language doesn't matter, it's the thought and reasonings behind it that count.
This really weeds out the candidates; better than fizzbuzz, better than live coding. Of course there's a chance that someone copies stuff off the internet, but that's what the actual interview(s) are for, just ask some questions about the implementations and the why and such.
We've hired people that did it in python, node, ruby, even J2EE. Language doesn't matter, it's the thought and reasonings behind it that count.
Whenever I see posts about hiring, the comments here tend to land at the "this is bad advice" end of the spectrum. Does anyone have any resources that give good advice? Or is hiring such an unsolved problem that we don't even have generally applicable guidelines, however vague they may be?
Here's some of the better advice on hiring I've seen after bring on HN for a while.
One of tokenadult's posts on hiring - https://news.ycombinator.com/item?id=8232963
tptacek - http://sockpuppet.org/blog/2015/03/06/the-hiring-post/
One of tokenadult's posts on hiring - https://news.ycombinator.com/item?id=8232963
tptacek - http://sockpuppet.org/blog/2015/03/06/the-hiring-post/
Successful stories about good hiring usually involves most of/the whole team being part of the hiring process and less delegated to HR people.
Aptitude over skill set. Interview for that.
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 reports started coming in, later on the customer complaints started coming in, and incidents were declared. The guy failed to fix the incidents and got fired.
Later on, I got hired. By auditing the code base I identified multiple issues that suggested the person did not understand what he was doing.
So the eloquent, passionate, cool, outgoing guy turned to be productive because he was only doing 20% of the job. All non-functional requirements were neglected. Non-functional requirements are often implicit and taken for granted. Nobody tells you "I want to not be hacked" or "I want our system to not slow down and go over capacity". Those are implicit requirements that you as an engineer need to identify, specify and implement.
The non-technical leadership realized this only 2 years down the road when a huge damage was already done.
So, I am going to say NO to this article. Skills are important.