Kyle Drake looks out for the integration quality and release cadence of Geoloqi systems.
Drake is what you might call a GeoLoqi "classic hire." He met Case and Parecki at a "cyborg camp," where they spent a weekend "building something cool" with Geoloqi technology. This had the benefit of being both a great technical interview, addressing whether Drake could, in fact, build things, but also a culture-fit interview.
After the meet-up, Case invited Drake to come hack on the system, first over a weekend and then at night for pay, and eventually to quit his day job to join the company. At every stage in the hiring process, things ended well for both parties. They get to walk away friends.
Geolocation in the Real World
Drake explains that, while you can simulate plenty of things about geolocation, some things are just impossible. "Say you switch cell towers, or go from inside a building to outside, with a sudden change of bandwidth and location quality, or you start to run low on battery power. We needed a way to test our SDK in the real world on real phones," he says.
Analysis: As Navigation Looks Indoors, New Uses Appear
Eventually, the team set up a bicycle route that starts at the office, goes down the waterfront, crosses the Sellwood Bridge and returns. It's about six miles in all. The final acceptance test of a new release involves throwing eight cellphones in a backpack, all running the software, and logging differences in behavior since the previous release.
Of course, that's the final customer level check. The team also does exploratory tests, and Drake has his own automated tests. "I focus a lot on the infrastructure things," he says. "I write tests to make sure our phones give us accurate location information, to make sure the servers are working correctly and not losing data, to optimize performance of an algorithm."
To accomplish that, Drake tests at many levels, from API down to unit tests. His current testing mostly involves validating the code at the API level. "I came from the Ruby community, where testing is given heavy priority, but writing automated tests does not intrinsically save you time," he says.
When automated tests aren't valuable, Drake conducts what he calls mini-tests. "I might not write automated tests for website code when I know that code is changing rapidly and the test will become obsolete quickly," he says. "If you make too many tests that are too rigid, they tend to be brittle."