The main problem I see with a lot of remote companies is that they seem to be overloaded with applications to the point they are making strange decisions about how to filter applicants. They also almost always require you to do some type of project which is a big commitment if you're applying to a lot of places. My best application experience apart from the one that hired me was Duck Duck Go. They pay you to do the project and I feel that is a far better approach. That way they don't have to feel bad about turning you down because hey you get paid, and you don't feel so bad about not getting it because hey you got paid.
I ultimately got a much better position at a fully remote company than I would have gotten at Zapier so it wasn't a matter of me overestimating my worth either.
I also found that a lot of the well known fully remote companies take forever to respond to you, gitlab, zapier, and DDG were the most responsive and communicative during the process, but I have some that I applied to 2 months ago that are just now emailing me to set up video screens. Startup companies tend to be the most responsive, I would get video screen invites sometimes within minutes after sending an email out.
In essence, if you require a project to be done for an interview regardless of the time limits and the applicant makes a reasonable effort and demonstrates adequate competency then IMO you should always give them an interview. If you're looking for something perfect then pay them. If you put hard time requirements on the project and expect it to be flawless you give off the impression that people are required to work under pressure.
That being said, I think it might be worth considering giving people the option of a take home project or a long interview. I know one guy who refuses to do take home projects and rather just sit in an interview all day and other friends who are the exact opposite.
If your first interaction with candidates, even from a huge, huge open pipeline of applications, is an automatic request for a time-intensive project or skills assessment, something is very broken with that hiring process.
You simply have to pay the (high & difficult) cost of evaluating & filtering applications and then having a detailed conversation with the small number of applicants you choose to move forward with. You need to understand their technical interests and match to the role, and let them ask lots of questions to even know if they are interested enough to invest time in the rest of the interviewing.
Personally one major change I’ve instituted over a few years in the ML & data science pipeline at my company is that we only do a technical conversational interview, no shared screen coding or take home project at all, it just doesn’t tell you anything, and counterintuitively you end up wasting more time and money administering it than if you just bring people onsite sooner and bite the bullet to evaluate them in a full interview day.
There's a whole slew of unfamiliar problems that come with remote work - and I believe that these companies are pioneering something that will become the norm one day. Work life balance is a serious problem, as well as relationship building. It seems to me that distributed companies have a hard cap on size before the disadvantages of remote become too cumbersome. These problems require creative solutions, and it's awesome to be able to contribute to it. However, it's difficult for me to identify which problems are caused by the remote-first culture, and which problems can just be attributed to the company itself.
This really resonates with my experience. What is my mindset vs what is inherent in the company/remote-work in general?
Work life balance is a serious problem
For example, Gitlab’s “compensation principles” [0] are horrifying to me. I could absolutely never work for an employer who openly acknowledges people who provide the same value to the company are explicitly paid less because of location, in a situation (unlike with physical offices in different locations) where there is no excuse for it.
[0]: https://about.gitlab.com/handbook/people-group/global-compen...
Notably it’s not just about paying different rates to different locales. They also actively adjust your salary if you move, even though it has no effect on them at that point (they are already paying you a certain rate at that point and don’t depend on your location). And they control the definition of multiplicative factors that determine pay between locations (instead of it being a negotiation), and those multiples are often ludicrously wrong (e.g. NYC & London compared to SF).
I asked him about fairness and he thinks it's fine. He finds that CoL should be paid according to area. When the company has a regional meet-up, he knows that people from around the region have the same capability to buy "tertiary" things, and that's a signal of fairness to him.
I'm not saying this is the right approach; just maybe a thought that companies have done this for longer than software companies.
For example, if I put in my own level on the compensation calculator of GitLab [0](Junior level, Learning The Role, FE Engineer, 0-2 years experience, living in Jakarta, Indonesia), I get $48k/year. That is pretty much the top 5% income bracket, not considering level. Entry level programmers here are paid $500-$1500 here, amounting to $18k/year at the most. That is a really large gap, and the vast majority would take it.
[0]: https://about.gitlab.com/handbook/people-group/global-compen...
Interesting! SF & NY based companies do it all the time.
> It’s a bit hard to tell whether 3,000 employees are a part of the TopTal freelance workforce or actually working on the core software platform of the company, but we’ll give them credit and say that they’re three thousand strong and a fully-remote, distributed company.