weswinham

5 ms·

1.
by weswinham 5y ago
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 e
2.
by weswinham 5y ago
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 exe
3.
by weswinham 5y ago
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.
4.
by weswinham 5y ago
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 comp
5.
by weswinham 5y ago
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 desi
6.
by weswinham 5y ago
I helped write a quick summary of 3 of these: https://www.woventeams.com/blog/3-books-every-new-engineerin...
7.
by weswinham 5y ago
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 m
8.
by weswinham 5y ago
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 hirin
9.
by weswinham 6y ago
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.
10.
by weswinham 6y ago
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 te
11.
by weswinham 8y ago
One sec. Just need to login to our CMS to update our tag line to "Woven: We're trying to unfuck developer hiring"
12.
by weswinham 9y ago
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 a
13.
by weswinham 9y ago
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
14.
Why all job interviews should include doing *real* work(medium.com)
6 points by weswinham 9y ago|4 comments
15.
by weswinham 10y ago
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 m
16.
Why Only 12% of People Succeed at Their New Year's Resolutions(22ideastreet.com)
3 points by weswinham 14y ago|0 comments
17.
by weswinham 14y ago
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 t
18.
My AWS outage takeaway: MTTR is more important than MTBF(devblog.policystat.com)
1 points by weswinham 15y ago|0 comments
19.
by weswinham 15y ago
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
20.
Followup: How we seamlessly moved from PHP to Django- Tech Details(devblog.policystat.com)
2 points by weswinham 16y ago|0 comments
21.
by weswinham 16y ago
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.
22.
by weswinham 16y ago
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 :)
23.
by weswinham 16y ago
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 s
24.
by weswinham 16y ago
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
25.
by weswinham 16y ago
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
26.
How we seamlessly moved from PHP to Django over 22 months(devblog.policystat.com)
41 points by weswinham 16y ago|13 comments
27.
by weswinham 16y ago
I definitely just finished hacking on this problem for our deployment and this is a much better solution. Docs look great too.
28.
DevOps at Our Startup(devblog.policystat.com)
3 points by weswinham 16y ago|0 comments