weswinham

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.

It might help to know that a study measured how stressful live coding interviews were on candidates and found it to be VERY stressful.

Half of the candidates did a coding exercise while someone was watching them. The others did the same exercise, but without being watched.

People being watched got ~half as far on the exercise, on average.

So you're not alone!

More and more companies are moving to mostly async for the technical portions, because of this. Study: https://www.engr.ncsu.edu/news/2020/11/11/tech-sector-job-in...

Yup! Onboarding can't just be tactical items.

New folks have valuable perspective on your company and product.

Soliciting new ideas from them not only helps the organization fight decay, but it creates more buy-in from the new person.

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.

The market rewards being good at job searching and interviewing. It makes a bigger impact on compensation than actual engineering value.

So get better at interviewing.

If you're already focused on coding, the next piece is systems design.

The more senior the job, the more likely part of the interview process is moving boxes and arrows around to design a scalable, reliable system.

This book is a great place to start: https://www.amazon.com/System-Design-Interview-Insiders-Guid...

I helped write a quick summary of 3 of these: https://www.woventeams.com/blog/3-books-every-new-engineerin...

In addition to those technical books, I'd check out:

* Staff Engineer- Great for the tech challenges beyond senior-level https://staffeng.com/book

* The Manager's Path- Good even if you're not going to be a manager. Understanding their perspective makes you more effective https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...

* An Elegant Puzzle- What if distributed systems engineering, but with people? https://lethain.com/elegant-puzzle/

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

So shorter and more-curated wins

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.

One sec. Just need to login to our CMS to update our tag line to "Woven: We're trying to unfuck developer hiring"

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.

Healthcare-improving UX Design Lead at PolicyStat | Indianapolis, Vancouver, or REMOTE | Full Time

http://grnh.se/flev3r

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.

Thanks for the heads up on the typo. Got that fixed.

As far as the decorator syntax, I absolutely agree. That's definitely a thing we should have. I ticketed it up at: https://github.com/PolicyStat/jobtastic/issues/11

Thanks so much for the suggestion.

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...

Thanks for the questions -wes

We definitely could have ported the entire thing in under 22 months if that was our goal. The goal was actually just to make product improvements and gather customer feedback as fast as possible in the time we had, and the porting from PHP to Django just kind of naturally fell out of that. For example, the only PHP left for quite a while were the index and login pages. Until we actually needed to touch that code again for other reasons (a bit of a UI refresh), it didn't make sense to port that piece. It was working just fine and we had (and still have) a lot of other things that are important to work on instead.

Also, for about 2/3 of those 22 months, the development, operations and support team were the same guy, so that does have some impact :P

I definitely just finished hacking on this problem for our deployment and this is a much better solution. Docs look great too.