What are you folks doing to actively combat this? Do any of you factor “cultural fit” into your hiring process? If you do, how do you quantify that and attempt to account for your social biases? Everyone has such biases. I only bring up cultural fit when discussing candidates if I think they may have attitude issues. Even that’s fraught with potential bias.
I think cultural fit is very commonly used as an acceptable euphemized bigotry. What do you think?
I’ve found that bringing in at least 1 interviewer from the same group as the candidate makes the candidate feel more comfortable during the interview. Also, the candidate is more likely to seriously consider working for the company if they feel like their identity group is represented. This, of course, implies that the company has enough diversity to make this possible, and someone from any of the underrepresented groups had to be first.
I think this is a good idea, but as you point out can be a bit difficult to bootstrap!
Easy first step is when you’re hiring: note to your manager that team diversity increases performance (1,2) and ask that HR bring in a diverse set of candidates. Then hire the best.
Then hire the best.
The problem is that our monkey brains are extremely good at identifying the person that looks a lot like ourselves as “the best candidate”, even if that’s not really true. That’s the nature of unconscious bias.
I heard an interesting approach from a friend that went through an interview: the very first phone screen was set up in such a way that the engineering team never heard his introduction (“Hi, I’m ‘foo’, I’ve worked on software for x years”, etc) and only came in during the technical portion of the call to listen and discuss technical questions.
At the most all they knew was that he was a man - didn’t know age, race, etc. He talked to them about it during a later part of his interview and while they admitted it wasn’t a perfect setup, they did find they were bringing more diverse candidates through to later rounds of the interview process.
I’m not sure we can ever get a double-blind interview set up, but I’d be really interested to see what candidates that go through that process would look like.
Yeah there are a lot of unintentional biases we have. Techniques like that and hiding the person’s name on the resume would help. You have to start somewhere though and not everyone is going to have the weight to change the entire interview process at their company.
…It’s better to dynamically sway and constantly rethink your idea of what is right and wrong given each situation as it arises.
That sounds like a lot of work, and I don’t know why he came to this conclusion. I liked most of what he said, and I expected him to conclude with, “Best practices are incredibly useful, but keep your mind open to situations in which you need to sway from them. For a lot of software, readability is more important that robustness.”
Stopped watching as soon as he called plain vi old tech and vim state of the art. Disrespecting and wrong on so many levels given how much you can accomplish with core vi alone, if you learn it properly. Take a peek under the hood of vim, if you dare, versus clean vi implementations.
Nowadays, I am using mg, just to keep it interesting. How much of editing power do you really need? More important is what you write (both code and prose, and no tool will help you there).
That statement was targeted at people who hate vi. Hell, the whole first half of the talk was targeted at people who have never used modal text editors.
If you’re just going to give the talk 2 minutes, you should skip to 24:30. At that point he starts talking about how vim is useful.
I’m not sure why I don’t use bitbucket. I have to imagine it’s either a) because it’s made by Atlassian or b) because everyone else seems to use github. More the latter, I imagine.
There is a discussion on “why do you use github” on the discussion page for Leaving Github
I love bitbucket, but then again I use hg
agreed, it’s the latter. Github even says it on their homepage, “GitHub is the best way to collaborate with others.”
bitbucket says, “Unlimited DVCS Code Hosting, Free.”
Free isn’t an advantage. There’s no shortage of free git hosting: Assembla, Codeplex, and I’m sure many others. So I keep my private stuff on Assembla and public on Github.
This talk repeatedly put me on the defensive in spite of me wanting to learn from it. He’s against layering sugar on top of a core, but I see that as a big part of what software and computing is. At the core level we’re just shuffling around 1s and 0s. There’s already a huge pile of sugar on top of that.
I didn’t gather that he was against layering sugar on top of a core, but that he believes we’re limited (not necessarily in possibility, but in how much time and effort we have to spend dealing with it) by the crappiness of the core.
I never thought it needed to be easier than it already is. I tried the plugin anyway and it does add some spit and polish to the buffer list.
I prefer :ls to :buffers. =)
So assuming you are looking for a language that scales codebase size easier, why would you choose TypeScript over Dart? Dart has been baking longer, has a more holistic view of the problem, and solves a bunch of other WTFs in the language. I don’t think the subset of people doing JS that want this are big enough to support fracturing, and Dart is so obviously a better solution then this, it is very hard to see it getting anywhere
TypeScript supports more editors, and key editors at that. http://blogs.msdn.com/b/interoperability/archive/2012/10/01/sublime-text-vi-emacs-typescript-enabled.aspx
Dart supports the Dart editor and the jetbrains editors.
Both languages are fully open source. Typescript uses Git. Dart uses Subversion.
I haven’t used either, but I personally am more inclined to try TypeScript due to the editor support and because I’m assuming it will have a smaller learning curve than Dart.
From what I understand, both are optionally typed (meaning you don’t have to use type annotations, but if you do they will be checked at compile time and ignored at runtime)
The reason typescript has more editor support is because it doesn’t go as far, which is basically what I was trying to say — If you are going to make the jump to a pre-processor, that why not use the thing that is more fleshed out? If all you want is type annotations, why not use the google closure compiler which gives you that without having to go to a pre-processor?
I had never used the google closure compiler so i played with it a little after reading your comment. The compression is great but I found it to be pretty opinionated. It also requires annotations for type checking which TypeScript does automatically.
It’d be interesting to see a side by side comparison of the various options. I’m going to put that on my list of “good ideas for a blog post” (which is already filled with lots of out-dated never completed ideas.)