...and finding Quality Assurance people with Python experience (especially advanced Test Engineering skills) is even harder. The white oak guys at pycon talked about how they used python experience as a measure of skill/intent. Personally, having spent the better half of the last five years looking for people with good Python skill sets, and now looking to build out a serious team - I'm almost always in the position of hiring on people who know "just enough" and teaching them Python.
Teaching python is easy - but not always what you want to end up doing when you're going fast in a startup (although, I've lost track of how many times I've done this).
Excuse me while I go grumble - either you teach QA people automation/test engineering, or you try to find a programmer who wants to learn/do test engineering and teaching them python. No - I don't want programmers to "do QA" - I want them to write code which proves the product.
It's a hard sell to both parties. You also don't want QA people who view QA as subservient to Development, and Developers who don't see QA as subservient to the same. I technically view QA as one discipline, Development as another, but Test Engineering as the Hybrid of the two - and you need a strong background in both. You are writing complex code to test and prove the product - code which can sometimes be as complex as the product itself.
I'm willing to teach anyone anything I know to help them - doing so helps me in the long term build a strong team. Just finding the right people is not-so-easy.
I said in an interview recently - when asked if I wanted to be a Software Engineer or a Software Test Engineer - that if I am writing code in either one of the roles, I don't see the difference. You're writing tools/code and trying to develop new/interesting things in both roles. If you are writing product code: you still have to write test code. If you write tools for testing: you're writing "product code" (that needs testing code). The same pattern of write-test-write-test applies no matter what code you're writing.
There's nothing "less" about writing code that tests a product, just as there is nothing "unique" about writing the product code itself. Both must be tested, both are code. Would I like to write more product code? Sure - but I have to also write the tests that prove it anyway.