HNHacker News
TopNewBestAskShowJobs

gtolle

7 karma · joined February 10, 2013

submissionscomments
gtolle··on Accounting for Developers, Part II
The book Central Banking 101, by Joseph Wang, is a good deep-dive on how the accounting works on the central-banking side when money is created, etc.
gtolle··on Orbital Mechanics – How do rockets get to where they're headed?
Sorry, it's iOS only, and likely will be that way forever (unless I'm suddenly blessed with a huge pile of free time again).

I second giving SimpleRockets a try, though.

gtolle··on Orbital Mechanics – How do rockets get to where they're headed?
If you'd like to try out some of these concepts on your phone, I've been working on a side project -- an iOS mobile game called Solar Express [1]. You can launch a rocket, rendezvous and dock in orbit, transfer between moons and planets, and land. It's a bit like a mini-KSP with real orbital mechanics, but more casual - no rocket building, and lots of delta-V to play with.

[1] https://apps.apple.com/us/app/solar-express/id1503449353

gtolle··on How Slack hooks users through artificial urgency
There's the "remind me about this" feature for messages. The intervals are well-spaced, too. (in 20 mins, in 1 hour, in 3 hours, tomorrow). I find it to be a great way to deal with an interruption that can't be ignored entirely, but comes while I'm in the middle of doing something more important.
gtolle··on Ask HN: Who is hiring? (October 2016)
Boon + Gable | Server-Side Rails Developer | San Francisco, California | Full-Time | ONSITE

Boon + Gable is a personal shopping service that takes care of all your clothing shopping needs - big or small. We make looking good easier by providing immediate access to stylists who bring a variety of brands and clothes to your home.

We're currently 8 people (2 engineers) and growing. We raised a $2.5M seed round from top investors in the e-commerce space.

We've built an end-to-end system to support our styling service, all the way from algorithmic item recommendations to scheduling to logistics, with 3 iOS native mobile apps, with only 2 engineers. We've helped hundreds of customers who love us.

Come join the team! https://boonandgable.com/careers

gtolle··on We only hire the trendiest
I love this approach. I'm also wondering what you think about giving well-designed work-sample tests over Google Hangout instead.

The candidate shares their screen with you, so you can watch as they solve the problem in their own dev environment. You can understand how they approach problems (quick and dirty, slow and methodical, lots of rewriting, etc), and you can ask questions at the end. You get a good sense for how they work as an engineer even before having to bring them onsite.

This seems to resolve the time asymmetry of take-home tests as well -- the interviewer spends as much time watching as the candidate spends working.

The only downside I can see is that you have to design your problems to take about an hour instead of the 2-5 hours you could imagine for a take-home test. But, you can break them up into multiple rounds, and give additional exercises to the candidates who do well on the first one, for no more total time cost than a collection of onsite interviews.

For what it's worth, I've done this at my startup and hired a great developer, and got very positive feedback about the process from the candidates I didn't end up hiring.

gtolle··on How to Pass a Programming Interview
At my startup, I've had some success hiring mobile devs through "audition programming" on Google Hangout.

I create a "real-world-lite" task like "connect to this simple JSON API I built and implement a recursive product category browser on top of it". I've done this task myself already with a timer and am confident that it will take about an hour to implement. Then I ask the candidate to share their screen and implement it in Xcode while I watch. As they develop, I can get a sense for how they attack problems (quick and dirty, slow and methodical, stack overflow copying, etc), and afterwards I can ask questions about their thought process.

If they did well in the first one, we block out a second one for another hour, and a third for another hour after that, each one testing different skills.

This avoids the time imbalance inherent in take-home projects, because I'm spending just as much time as they are. And it avoids the painful "implement a red-black tree" whiteboard questions by focusing on real-world work in their own dev environment. It also means I have a decent sense of their skills before I ever invite them to an on-site interview.