courtewing

Tech tends to be more friendly with vacation time in the US than most other industries. It still varies a lot, but it’s not uncommon for a tech company to start you with 3-5 weeks of vacation time plus 8-12 paid holidays throughout the year. It still could be a lot better though, and I agree that it contributes greatly to burn out.

As with anything that is potentially contentious and involves humans, there's a lot of nuance here and breaking it all down into a couple paragraphs doesn't really respect the unique needs of everyone. I've worked with some amazing people that respond best to very informal processes around performance-based feedback, and I've worked with some equally amazing people that desire a relatively rigid and analytical process. I think we all try to do what's best for each person.

That said, it's important that we do have guiding processes and principles here to ensure that everyone is being evaluated both fairly and effectively, so it's not like the wild west or something.

Every "track" has levels with defined expectations in terms of the type of work they do, the impact they have, the interactions they have with teammates, others at Elastic, the community, etc. High performers would be folks that are at least meeting the expectations established for their level, which is where promotion comes in.

Promotion is not necessarily role-oriented in the sense that you don't get promoted out of being an engineer into management or something like that, they are different parallel tracks. For example, I technically took a demotion to switch from a Tech Lead to an Eng. Manager role.

Processes do vary a bit team by team, though they've become more consistent over time and are pretty similar now. This is how things work on my teams:

I have 30 minute 1:1s with each person that reports to me every 2-3 weeks depending on their seniority. This is pretty informal, but the consistent face to face gives us opportunities to talk frequently about how things are going.

Every quarter I do a longer review with each team member. This isn't super formal or anything, but it is more structured with a corresponding doc that I fill out in advance and that we both expand upon during our meeting. Nothing should be a surprise here as I give positive or critical feedback more regularly, but this is where we can really dig into aspects of their performance, rehash current expectations for their level and make plans with them for how to achieve their professional goals, whether it be promotion, type of work, transitioning to a different role, etc.

The 6 and 12 month reviews are a little more comprehensive as I also include anonymous 360 feedback from peers and others throughout Elastic.

Nope, I missed that part if it was in the Gumroad post.

We do, yeah. We include "target" seniority designations in the job post titles, so if it doesn't say "senior", "principal", etc, then it isn't a senior position. We also don't (for the most part) have requirements around years of experience, though in practice there's an obvious correlation.

That said, at this very moment we happen to have a boatload of more senior positions available. There are a couple less senior ones though.

Wouldn’t this problem be even harder to deal with if you didn’t work remotely? You only need to plan for the radius of one person’s commute rather than limiting your housing options to a balance of two locations.

For every one position we hire for we’ll see 100s of applicants, and we might have 5-10 good choices to hire. Filters are a critical part of managing a candidate pipeline, and for better or worse a degree is widely used as a filter for those companies that don’t lack a pool of qualified candidates, which also tend to be pretty attractive companies to work for.

And another: Edge doesn’t support nonces for script files. It supports them for inline scripts though.

I live in a small city in the US, and remote work has provided me opportunities for career progression and networking that would otherwise be impossible for me unless I moved my family somewhere else.

The key for me has been to work for distributed companies rather than as one of the few remote workers on the team. This seems to make all the difference in the world.

We don't do much with C++, unfortunately. The closest thing to this would probably be golang on the Beats team.

Possibly, though it's hard to say without seeing the details of your experience. There are multiple java engineering positions open as well, though.

Kibana's an open source project, so if you're looking to volunteer, you can contribute directly to it without having to jump through hoops, do interviews, etc. We follow the same process that our open source contributors do, so read through the contributing guide, take a look at the issues, and dive in!