ntalbott
Joined 17 years ago
Karma
311
Submissions
81
Member since
Mar 22
Recent submissions
Comment · 10 years ago
I hope it has a lasting impact beyond Spreedly, too. The impact of founding a company shouldn't just be on customers; if we act in an upright manner, hopefully employees, vendors, partners, the families of all of the above, and a cascade of future endeavors will be positively improved.
RE feedback, we try to give it and make it meaningful, so for instance the pre-defined, objective grading criteria we use for work samples lends itself well to us being able to highlight why someone isn't a good match.
There may be a slight possibility that giving clear feedback opens us up to some sort of liability, but (a) a respectful process ends up documenting itself really well as a side effect (how else are you going to keep up with all the details?), (b) a respectful process hopefully leaves even candidates who weren't a fit feeling like they got a fair shot and thus not inclined to come after us for a perceived slight, (c) I think the fear around giving feedback is more about how uncomfortable it makes us feel vs. an actual legal risk, and (d) I hate not getting feedback when I fail and as a founder and executive I have the clout to take some risk and do what's right.
Comment · 10 years ago
Author here: you're right, nothing revolutionary here in technique. Most/all of our actual process is ripped straight out of http://sockpuppet.org/blog/2015/03/06/the-hiring-post/. But my experience, over the course of Spreedly interacting with 100+ candidates over the past few years, is that just doing pretty standard things well, with attention to detail, is in itself revolutionary. We hear story after story from candidates about other companies they have or are interviewing at that are completely disrespectful in how they're treating candidates. Whether this is cargo culting, lack of time to do things right, or a righteous belief that it's OK to treat candidates poorly, I can't say, but it's pretty disgraceful.
So, I wrote this little thing both since I needed to write it down for my coworkers anyhow - this is how we do things, showing respect for candidates by keeping reciprocity, incrementalism, and relevance in view - but also in the hopes that it's one more brick in a wall of "you're worthy of respect" for candidates.
The post itself wasn't about our actual process, though I did use examples from it; I hope to write about the actual process later. But I will note that my experience of phone screens is apparently very different from yours: I've experience them as a chance to pre-grill and filter candidates, and ours is 100% not that. I ask zero questions, but instead just talk about what we do and answer any and all questions candidates have. You're right that doing an intro call with each candidate isn't scaling, but we're not replacing me with HR, but instead have a live weekly intro call that candidates can join where I talk about the company and they can ask questions via text and I answer them on the spot.
And for what it's worth: "the current market dynamics" in tech hiring SUCK. So long as I have any say, we'll be playing moneyball by ignoring them and instead just continuing to iterate based on what actually works.
Comment · 11 years ago
Love this: like 99designs for code. Bet you'll get a lot of pushback on this "devaluing coding" just like 99designs has for design, which just means you're on the right track. Of course it doesn't; it just commoditizes basic coding skills, and more importantly makes the accessible to a wider set of people.
I especially liked the example that was scraping data off a bunch of pages and returning a spreadsheet/csv of the results; that's a great example of something a smart business person that thinks algorithmically can identify, but can't/won't implement themselves. I actually wonder if it would work well to target this service specifically at algorithmically minded business folks.
Hope this works well for you - great idea, and looks well executed so far.
Comment · 11 years ago
Spreedly already supports vaulting bank account information, and while the number of gateways that we support passing bank account info to is still limited, we're growing that rapidly at the moment.
Our gateway support is heavily influenced by customers, so anyone who has a gateway they'd like to pass bank account info to that we don't support today shouldn't hesitate to drop us a line.
Comment · 12 years ago
Thanks! The name's "test/unit", but I won't hold it against you ;-). It's pretty sweet that people have gotten so much mileage out of code I wrote, and if it's helped us as a profession - even a little bit - to write better code, I'm thrilled.
Comment · 12 years ago
You forgot to reference the great recursive essay Eric Meyer wrote on exactly this topic:
http://meyerweb.com/eric/comment/chech.html
Which essay I already knew about and chose to willfully ignore when I titled the OP. We could chat over beers sometime as to whether I'm a bad person for doing so :-)
Comment · 12 years ago
I think a lot of it depends on context. In a private repo I'm right there with you. But when I look at a public repo with a lot of contributors, I want to know what the "logical" history is a lot more than I want to know about the three steps it took to get a feature ready for public consumption.
Comment · 12 years ago
Well, quoting from that message, "If it's not ready, you send patches around". I think the big difference is that I'm willing to take patches that aren't ready and get them ready, whereas I'm sure Linus usually pushes back on the contributor to clean up their stuff. And I do think merges are super useful in a lot of cases, but Linus added `git am` too, and I like using all the tools at my disposal when they fit.
Comment · 12 years ago
Most of the contributions I'm merging in are 10 lines, but a lot of them (half?) take two or more (sometimes many more) commits to converge on those 10 lines, and none of those intermediate commits has useful information in them. The other half of contributions are only a single commit already.
If someone contributes a true 1000+ line contribution that I'm even willing to take (yikes!) then you better believe I want that in multiple, logical commits, and it may even be me that ends up doing the splitting.
I'm sure a lot of it just has to do with what types of contributions a given OSS project receives, so YMMV.
Comment · 12 years ago
Maybe, but... probably not. The thing is, I want to work with the changes locally before they get included. So it can't be a 100% web workflow. That said, there might be ways the web UI could make the transition to the CLI easier, and it would be great if Github promoted the `git am` flow on the PR pages as well.
Comment · 12 years ago
These quality issues become a problem sooner than I would have thought, and Linux is big enough that they can just demand contributors know their stuff. But I found that in between "hobby project of my own" and "huge project where people beg me to contribute", there's a big space of "big enough that it gets contributions, but small enough that it's not worth turning contributors away for small quality issues". And I love that hub + `git am` lets me take those contributions but still maintain the workflow I want on the project.
Comment · 12 years ago
FWIW hub is even handy for the "add a remote for the fork, check out the fork branch" flow, since it lets you just `git remote add ntalbott` instead of having to find or derive the full url for the remote.
Comment · 12 years ago
You may think of commits as literal quotations of the "Author", but it's important to realize that git doesn't. If you want to know who's ultimately responsible for a commit, you always want to look at the "Committer" since that's who actually signed on the dotted line so to speak.
[email protected] [email protected]
[ my public key: https://keybase.io/ntalbott; my proof: https://keybase.io/ntalbott/sigs/gA1J8tiUY5xfIkaJlZQI0xMt0i6mstl8j-PISm7I0zE ]