It's also worth thinking about the timeline inclusive of hiring delay. More detailed requirements makes hiring slower.
I know 2 startups both hiring their first set of non-founder engineers.
One startup took 4 months to hire 2 senior engineers who weren't in their stack and then gave both of them about a month to come up to speed on the tech. Literally running tutorials.
So 5 months in, they have two onboarded senior engineers.
The other startup is 6 months in and hasn't made either hire. They see deep experience in their tech stack as required and don't want to wait longer for onboarding.
But in retrospect, they would have gotten to an onboarded team faster if they had hired like the first company.
The more the company sees developers as a cost center (e.g. legacy companies who put developers in the IT org), the more they're looking for specific technologies.
"I need a dev with 7 years of Spring Bott!"
The more the company sees developers as a crucial input to innovation and building a more valuable company, the more the emphasis is on capabilities.
"I need a senior developer that's great at solving problems. I don't care what tech stack"
But in the second case, a core capability needs to be passing a typical developer interview. So you'll need to practice writing code in a time limit with someone watching you. You'll also need to practice designing a system.
^ it is dumb that this capability matters, but it's the reality today. There are some companies that interview differently where you actually build real-world things without someone looking over your shoulder, but it's not the norm yet.
Written, async interviews give candidates who are better at the job an advantage from those who are just better at schmoozing and exaggerating their resume.
So a C+ for effort, but this is a great example of what NOT to do.
1- This is hiring by committee. They sent out a call for questions to a bunch of people and then didn't curate it. Everyone's question get in
2- Too long for the candidate. The best candidates will bail. Companies targeting ~10 minutes on a phone get great response rates
3- Too long for hiring committee. NOBODY is going to read this for most candidates. The reasons resumes win is because they're short for the hiring team, not because they're high-signal
I think you nailed it that it's a team composition question. Too many folks like that is a problem, just like too many folks who hate the pain of bleeding edge/messy/unstructured work is a problem.
This story would make a great culture test! "Would you hire this candidate?"
You only want to work with team leads who agree with your answer, whatever that might be.
Personally, I love working with folks who enjoy playing with technology, so I'm a Hell Yes. I don't see a lot of risk that this candidate would actually try to ship that regex to production.
While that 1-week (or longer) ramp-up is generally true for companies, it's clearly not true for most (successful) open source projects. The things that a good open source project has (good documentation, onboarding, tests, etc.) are also the things that a good work sample will have.
If the work is in any way usable to the interviewing company, definitely. We went that route for one of our work samples where abstracting out a context-mirroring scenario was going to be very difficult. We then paid the candidates for the time spent doing the 4-hour take-home work sample.
One anti-pattern here involves turning all of your work samples into week-long consulting engagements. Those are a great way to evaluate candidates, but it means you can only hire folks who are already doing consulting (or are otherwise unemployed). For some companies, that works.
PolicyStat’s mission is to improve healthcare delivery through better processes. We help our clients make their policies and procedures easier to find, access, and manage.
We need a senior UX designer to lead our design process and help us take our product to the next level. Our product team understands the importance of good design and we need someone to help us, guide us, and teach us. We’re a process-driven team looking for a fellow process nerd with strong opinions about how to bake good UX design into iterative product development.
Our interview process is a portfolio review, a phone screen, a fixed-time work sample, and a culture conversation with your future team. Full details provided in the automated email sent out after you apply.
I'd say your choice between Quora's engineers being incompetent or AWS being dishonest/incompetent is a completely false dichotomy. Anyone who has been around AWS (or basically any technology) will agree that the things that can really hurt you are not always the things you considered in your design. I just can't believe that many of the people who grok the cloud were running production sites under the assumption that there was no cross-AZ risk. They use the same API endpoints, auth, etc so it's obvious they're integrated at some level.
Perhaps for Quora and the like, engineering for the amount of availability needed to withstand this kind of event was simply not cost effective, but I seriously doubt the possibility didn't occur to them. It's not even obvious to me that there are many people who did follow the contract you reference who had serious downtime. All of the cases I've read about so far have been architectures that were not robust to a single AZ failure.
As for multi-az RDS, it's synchronous MySQL replication on what smell like standard EC2 instances, probably backed by EBS. Our multi-az failover actually worked fine this morning, but I am curious how normal that was.
That was definitely the eureka moment that made us realize that it was possible. I'm pretty sure someone on the django users mailing list actually pointed me to the phpserialize library, which was the key to the whole thing.
Sure thing. I'm going to try and get together a follow-up post with some of the php session engine details and the apache configuration we went with. Hopefully you'll find it interesting :)
You're definitely correct that this post was light on the motivation for Django versus continuing with custom PHP. Perhaps it would be worth a follow-on post, as long as I can figure out how to not turn it in to a framework flamewar :)
In short though, we wanted to realize the obvious benefits of web frameworks over our poorly-constructed prototype raw PHP application (DRY, code re-use, reusable applications, MVC organization, testing tools etc.). We're now seeing basically all of those. Our code is clean and well-constructed because we were able to lean on the wisdom of the Django community. We use fully 24 different reusable Django applications, along with a couple dozen python libraries. Whenever we face a challenge, more often than not we can find a great blog post from the community that addresses a very similar issue and sometimes we can contribute back a little bit. When we hire new people, we can point them to Django's great documentation if they're new to Django, or they can jump straight in to our project and feel at home because it looks like basically every other Django project.
We're very very happy with Django and what it's given us over our own raw PHP. Other frameworks, like RoR would have given most if not all and more of these benefits, but the important thing in my opinion is that if you're doing a web application, you find a web framework that meets your needs. Honestly, when it came down to evaluating frameworks, it was RoR versus Django because that's where the community was. For me, it was Django because I like python's "one obvious way" versus ruby's many ways, which is a purely aesthetic judgement that plenty of people much more qualified than me make in the other direction. Once I realized that both of them would do a great job solving the problems our business was facing, I just made a decision and started writing code :)
1) When evaluating the options (mid 2007), Django and Ruby on Rails were the two projects with the most community momentum, and I personally put a lot of weight on that. I had used and was a fan of CakePHP, but the reality was that porting the mess that we had to either CakePHP or Symfony (the two we look most closely at) would have taken a significant amount of work. Since we knew that it wasn't possible to place development on hold, the main requirement was that whatever we did would need to live side by side with the existing code, and it was only a little bit more difficult to do that with another language and framework than another framework written in PHP.
I don't at all mean to say CakePHP or Sympfony would have been bad choices, but our technical team was such that switching languages wasn't a hurdle. I think the number of startups that have chosen Django or RoR as their platform of choice since mid 2007 in part validates our decision, but that doesn't mean other choices would have been bad.
2) It took 22 months to eliminate the last bit of PHP, but that was by no means the focus of development. During that time we made very large changes to the application based on things we learned from our customers. The reality is that no matter what technology we would have chosen, basically every single line of code would have been rewritten over the next two years. There was a little bit of us embracing technical debt in spreading the full port over 22 months: http://www.startuplessonslearned.com/2009/07/embrace-technic...
I know 2 startups both hiring their first set of non-founder engineers.
One startup took 4 months to hire 2 senior engineers who weren't in their stack and then gave both of them about a month to come up to speed on the tech. Literally running tutorials.
So 5 months in, they have two onboarded senior engineers.
The other startup is 6 months in and hasn't made either hire. They see deep experience in their tech stack as required and don't want to wait longer for onboarding.
But in retrospect, they would have gotten to an onboarded team faster if they had hired like the first company.