First engineer role

[timgl]

We're hiring our first (and probably 2nd) engineer.

We're already getting a lot of inbound interest from people, and selecting the right person is going to be crucial.

The things I'm looking for are

• Strong communicator. A lot of our communication is going to be written down, and the rest is going to be over zoom. If they can't make themselves understood well, the job will be much harder.
• Proven ability to start something from scratch. A first engineer is going to have to start a lot of projects, ideas and initiatives from 0, without outside help. This seems to be a skill that is hard to learn/teach.
• Able to complete tasks quickly without outside help We'll be able to test for this during the paid work. My benchmark here is Marius, who despite not knowing Django was able to complete entire features right off the bat, without help.
• Seniority in writing and quality of work We're too resource-constraint at the moment to be able to take a very junior engineer and help them be successful. I'd like to see initiative and thoughtful decisions, and being able to explain why they made those decisions.
• Willing to make timezone (GMT) work. This is not a hard requirement, but I think there needs to be a decent chunk of overlap in timezones in the day so we can have a close feedback loop.
• Not be precious about their work The quality of our product needs to be very high, and everyone in the company needs to be honest & direct to achieve that. We're going to need to iterate a lot, so they need to be okay with throwing away work to make it better

[jamesefhawkins]

Agree with these. I'd clarify the timezone requirement to "be willing to make it work timezone wise".

[EDsCODE]

Interview Reflection

Overall, I enjoyed the process. Because the entirety of Posthog’s work is done transparently, I could jump in straight away and contribute/get a feel for the codebase. Tim being hyper responsive was extremely helpful and a positive sign for me. Couple of main points that I think could benefit later hiring:

• Structuring the tasks so that there’s a wider assessment of the candidate. (e.g. how they handle a bug fix, how they handle a small feature implementation, how they handle a small refactor would allow candidate different contexts to demonstrate themselves).
• More exposure to the rest of the team members in many super micro conversations or snippets of work. I got familiar with Tim quickly but still little interaction with rest of the team. I would’ve enjoyed a quick convo about the product process with Aaron or some code run through with Marius. (Understandably, right now is an especially hectic time and it takes more scheduling to coordinate a process like that)
• I liked doing a big plan post on on issue because it showed communication style and I realized the extent to which this company is being run in the public. I definitely was slightly concerned I was detracting from outputting code for you guys because I spent a part of Thursday doing this instead of working on an assigned ticket. It’d be too contrived to require candidates to always write some post, but I think encouraging candidates (maybe within job posting or in initial calls) to take initiative could allow some good learnings on how they communicate.

Otherwise, I thought it was great! I’m also biased because I enjoy jumping into fast-paced and less-straightforward environments but maybe that’s also what you’re interviewing for.