Daniel Doubrovkine, an engineering leader formerly CTO at Artsy, writes about hiring, open source practices and moving between management and engineering.
HN commenters cite it for open-source-by-default practices, going from CTO back to individual contributor, and interview and recruiting processes.
First, the state of the art of "taking technical interviews" hasn't changed in the last 10yrs at least. This is, when we as an industry are harbingers of "change".
The bottom line is that the interview process is time consuming, expensive and often not the aspect of your job for which you will be held accountable for (i.e. you get fired if you are unable to recruit).
An interviewer in such a case, has no incentive to carefully think about the process. Usually the interview time during his/her day is not the prime task at hand and he/she has to run to "other meetings".
In such an environment and time constraints, We come down to our rote notions of what "intelligence" means.
If you are interested, I would recommend these two very well written articles:
1)http://code.dblock.org/five-ways-to-torture-candidates-in-a-technical-interview
2)http://code.dblock.org/how-to-reject-engineering-candidates
Lastly, I wish you luck if you are a so called Front End engineer or worse, a female engineer in this industry. Its really rough out there for them in special.
Now, if you'll excuse me, I have to go and practice my bit manipulations.
As Peroni mentioned, Targeted is more effective yet difficult.
A good approach to this is something that I would call "passive targeted recruiting", basically implement policies as "always be recruiting" and having your doors open (office-hours work great for this), take 1 - 2 hours of your week to talk with people interested in knowing more about your company, etc. Also I would say enforce cultural fit over technical, I saw Polyvore's about page and see that you do a really good job selling your culture :).
We release recently an interview with Daniel Doubrovkine about office-hours http://bit.ly/WFhVvo, he also writes a lot in his blog about hiring http://code.dblock.org/help-me-fix-tech-recruiting-become-a-recruiter
Hope it helps! I would be interested in discussing further about the subject if you want (email is in my profile).
I was working at Artsy while the OP was CTO (:wave:) and tried to help out a bunch on fostering a good attitude towards OSS - there's quite a few notes in both artsy/README and the blog
- (the making of artsy/README) https://artsy.github.io/blog/2018/08/21/OSS-by-Default-Docs/
- (OSSing our apps) https://artsy.github.io/blog/2019/04/29/how-did-artsy-become-oss-by-default/
- (OPs writeup on the philosophy) https://code.dblock.org/2015/02/09/becoming-open-source-by-default.html
- (the RFC process) https://artsy.github.io/blog/2019/04/11/on-an-rfcs-process/
Yes, I think all employees involved is a huge win. In our company of 3, we do that. But one thing that's problematic from the customer's point of view, is:
"Who should I contact to solve my problem?"
The ideal experience in my opinion is a single contact point, with the authority and knowledge to solve every issue you have.
That's of course unrealistic, but I want to find a way to approximate that. The closest thing I've heard is Alla Klein:
http://code.dblock.org/alla-klein-a-fake-person-in-charge-of-customer-support
I joined AWS 6 months ago at 43 as a principal engineer, transitioning from a CTO role of a Series D company, and wrote about it.
https://code.dblock.org/2019/11/17/the-pros-and-cons-of-going-from-management-back-to-ic.html
I would recommend it.
Nah, I've got better things to do.
My old boss, however, has good advice on how to make them useful, for those who care to respond: https://code.dblock.org/2015/01/09/how-to-make-recruiter-spam-useful-my-canned-response.html