4 ms·

As the article notes, software engineering is an interesting discipline in that an engineer's main responsibility is to produce a discrete body of work which ca

As the article notes, software engineering is an interesting discipline in that an engineer's main responsibility is to produce a discrete body of work which can be peer reviewed. I don't want to dismiss culture entirely, but it's a very vague idea that gets used to justify a lot of negative hiring practices. I think it's less important to assess "culture fit" than it is to do a very thorough review of a candidate's prior work. The candidate can be included in this review and even asked to explain/defend particular choices they made while creating that work -- since sometimes external constraints force non-ideal technical decisions and if the candidate understands that it's a sign they're a strong engineer. Why not hire the best engineers you can find and then let them define the culture of the company? People who have a hand in defining the culture of their team/company tend to be more motivated and invested in it.

gaius 11y ago
But their prior work is their cultural fit. Has this person worked for F100s, startups, in academia, as a contractor, etc etc etc. Your test would rule out anyone looking to change direction regardless of the reasons.
yummyfajitas 11y ago
Because culture does matter, even in tech. Consider a company where social inclusion is important. That'd be a terrible culture fit for me. When debating a technical choice, I'll say "do we all agree to run X experiment, outcome Y => choice A, outcome Z => choice B? Then we can all STFU and stop arguing." In the happy/social/fun environment, this is terrible. The promoters of B might feel unhappy, harming team cohesion, and that could be more important than 10% lower latency. On the flip side, consider the confrontational "put up or shut up" environment I tend to prefer (and create). In this environment, "you suck at SQL" is just a factual statement that you can choose to remedy or not. Some folks really don't like being told "experiment failed, your idea is wrong, be smarter next time". Even if they are technically competent, they need a form of social interaction at work that they don't get. There are a variety of cultural dimensions like this that matter. Another is implicit vs explicit - whether you can navigate implicit job responsibilities or they need to be spelled out. Much as we'd like to act like we are just machines taking money as input and code as outputs, this stuff does matter.
- tommorris 11y ago
  How about "the experiment failed, your idea was a good hypothesis, better luck next time"? Instead of "you suck at SQL", how about "you should probably read up on the difference between GIN and GIST indexes in Postgres and maybe try out window functions - they make this problem a lot easier to solve". It seems more productive to give people ways they can improve their skills rather than tearing them to shreds just for entertainment. You can have an environment that is driven by good engineering (testing assumptions, measuring etc.) without people being outright insulting to one another. All it requires is, oh, minimal human empathy and a willingness to spend 10-15 minutes every so often explaining unfamiliar concepts to fellow team members who haven't fully grasped it.
  - yummyfajitas 11y ago
    It seems more productive to give people ways they can improve their skills rather than tearing them to shreds just for entertainment. That's a valid elaboration focused on a single specific instance. It doesn't mean that "you suck at SQL" isn't also a valid critique. For example, while GIN/GIST indexes will help them solve this problem, what that person may need is to actually just learn a lot more about SQL overall (rather than just one specific trick). "You suck at SQL" isn't a thing that's valid (read: correct) to say to someone just because they don't know about a window function. It's a thing that is valid to say when a person repeatedly demonstrates fundamental misunderstandings of SQL on many occasions. It's also useful information. I've been told that I suck at UI, repeatedly. I accept and internalize this fact. As a result, while I do sometimes think about customer experience, I very rarely push hard for a specific UI or worry too much about details. I'll suggest that maybe a UI is confusing and they should hallway test it and then afterwards do nothing but insist that we abide by the test results (whatever they were). Based on the mood affiliation of your comment, it sounds like you dislike this sort of interaction. You prefer something with more "empathy" and less "tearing them to shreds". That's exactly what I'm talking about when I say culture matters. You'd probably hate being on my team and I'd probably hate being on yours, even if we are both highly competent devs.
    - aninhumer 11y ago

gaius 11y ago

But their prior work is their cultural fit. Has this person worked for F100s, startups, in academia, as a contractor, etc etc etc. Your test would rule out anyone looking to change direction regardless of the reasons.

yummyfajitas 11y ago

Because culture does matter, even in tech. Consider a company where social inclusion is important. That'd be a terrible culture fit for me. When debating a technical choice, I'll say "do we all agree to run X experiment, outcome Y => choice A, outcome Z => choice B? Then we can all STFU and stop arguing." In the happy/social/fun environment, this is terrible. The promoters of B might feel unhappy, harming team cohesion, and that could be more important than 10% lower latency. On the flip side, consider the confrontational "put up or shut up" environment I tend to prefer (and create). In this environment, "you suck at SQL" is just a factual statement that you can choose to remedy or not. Some folks really don't like being told "experiment failed, your idea is wrong, be smarter next time". Even if they are technically competent, they need a form of social interaction at work that they don't get. There are a variety of cultural dimensions like this that matter. Another is implicit vs explicit - whether you can navigate implicit job responsibilities or they need to be spelled out. Much as we'd like to act like we are just machines taking money as input and code as outputs, this stuff does matter.

tommorris 11y ago
How about "the experiment failed, your idea was a good hypothesis, better luck next time"? Instead of "you suck at SQL", how about "you should probably read up on the difference between GIN and GIST indexes in Postgres and maybe try out window functions - they make this problem a lot easier to solve". It seems more productive to give people ways they can improve their skills rather than tearing them to shreds just for entertainment. You can have an environment that is driven by good engineering (testing assumptions, measuring etc.) without people being outright insulting to one another. All it requires is, oh, minimal human empathy and a willingness to spend 10-15 minutes every so often explaining unfamiliar concepts to fellow team members who haven't fully grasped it.
- yummyfajitas 11y ago
  It seems more productive to give people ways they can improve their skills rather than tearing them to shreds just for entertainment. That's a valid elaboration focused on a single specific instance. It doesn't mean that "you suck at SQL" isn't also a valid critique. For example, while GIN/GIST indexes will help them solve this problem, what that person may need is to actually just learn a lot more about SQL overall (rather than just one specific trick). "You suck at SQL" isn't a thing that's valid (read: correct) to say to someone just because they don't know about a window function. It's a thing that is valid to say when a person repeatedly demonstrates fundamental misunderstandings of SQL on many occasions. It's also useful information. I've been told that I suck at UI, repeatedly. I accept and internalize this fact. As a result, while I do sometimes think about customer experience, I very rarely push hard for a specific UI or worry too much about details. I'll suggest that maybe a UI is confusing and they should hallway test it and then afterwards do nothing but insist that we abide by the test results (whatever they were). Based on the mood affiliation of your comment, it sounds like you dislike this sort of interaction. You prefer something with more "empathy" and less "tearing them to shreds". That's exactly what I'm talking about when I say culture matters. You'd probably hate being on my team and I'd probably hate being on yours, even if we are both highly competent devs.
  - aninhumer 11y ago