cramey
Remote: Yes
Willing to relocate: Yes
Technologies: Android, Bash, C, CSS, Docker, Elasticsearch, Git, Go (golang), HTML, Java, JavaScript, Linux, Lua, macOS, MariaDB, MongoDB, OpenLayers, Oracle, PHP, PostgreSQL, Python, Redis, Solr, SQLite
Resume/CV: https://binarythought.com/r/e/sume.html
Email: [email protected]
I'm a skilled generalist with over 20 years of professional experience in software engineering, across multiple languages and platforms. My favorite part of my current position is mentoring junior developers. I work best in small groups where team members wear many hats. I enjoy learning new things, and would relish the opportunity to work on ML systems or learn Rust, but I'm open to anything.
That's a 10 to 14% hiring failure rate, which is absurd. In what other context would a failure rate that high be acceptable? Those sound like sweatshop numbers.
Also, with traditional pair programming (one driver, one navigator) you're allocating two programmers on a single task, meaning that pair will need to generate at minimum the equivalent work of two programmers operating independently. I've never seen that work out to be true.
The only argument for pair programming I've ever subscribed to is that it can be used to more rapidly educate inexperienced programmers. If you compared the relative costs of inexperienced vs experienced programmers that math might pan out. Of course, then you have skilled programmers you're potentially underpaying, which is a problem in and of itself.
Wikipedia also says their server is open source: https://en.wikipedia.org/wiki/Signal_(software)
1: https://en.wikipedia.org/wiki/Comorbidity
2: https://www.cms.gov/CCIIO/Resources/Forms-Reports-and-Other-...
Musicians and actors are better examples, as they do have auditions, but lots of actors and musicians get jobs based on their previous body of work, rather than an in-person audition.
I'm curious, can you name more professions that use what is essentially auditions for hiring, besides artist-types?
Ideally the candidate offers code samples, I then pick through the code samples to find things that strike me as unusual or problematic and ask questions about those parts. This gives me a great deal of insight about how people think, and their relative level of skill. I firmly believe this is the best way to interview.
Failing that, candidates frequently provide details on projects they worked on. I'll then ask questions about those projects like, "What language did you develop it in and why?" and "What do you think was the most difficult part about this project and why?" These questions are a gateway to the same kind of details you get from code samples. For example, a candidate once mentioned he had worked for the Navy, and had done water simulations for them and I asked, "What's so difficult about water simulations?" and he gave me a 20 minute lecture on how water simulations work, which won him the job. It's probably worth noting that the job had nothing to do with water simulations, but his lecture made it clear he had passion and knowledge and could do the job.
The worst interviews are ones where the candidates worked in an environment where they can't offer code samples or talk about previous projects (military contractor, for example) - these you just kind of muddle through by talking about programming in general.