I checked out the open positions. There were more positions open than total employees. Are those real positions you are looking to fill or always open positions that rarely result in an actual job?
I asked this because the interview process has this step where you ask the candidates to do a project and than go over it with someone. One of these little projects is design our api or build a github issue viewer frontend/backend. You still have 4 more rounds after someone invested all that time.
The amount of effort to work here seems high and the chances of the position existing and you filling it is so low. I feel bad for the many looking for work.. do you invest 10+ hours in a process where a job may not exist in the first place and the company brags about the goal of one person servicing a million
I can’t speak for the Railway team, but I am hiring at an early stage startup myself. There is absolutely no way we’d extend offers for all of the roles we have open if a candidate arrived for all of them next week. Growing that much so quickly would be a disastrous onboarding experience for most of the new hires and potentially risk our ability to build a consistent culture with the team. So we’ll hire whichever candidate(s) successfully complete the process first and then pause the other roles until we’re ready to onboard more people.
Then there’s also the reality at this stage you need people who can wear multiple hats. And there’s a bunch of roles where your ideal candidate doesn’t have a neat pre-established label. So sometimes we’ll post the exact same role with different titles to try and make sure it gets the attention of someone who most strongly aligns with one of those job titles.
At a previous place we worked remotely, and so the same job would be posted as both remote and then also as a dozen different specific city locations too. But if we were hiring multiple of any roles you wouldn’t multiply that, you’d just post the one listing(s) and keep it open until all the positions were filled.
A jobs page is a marketing artefact for potential hires, it’s not a financial reporting/forecasting tool.
TLDR: don’t make any assumptions from a job board about how many roles a company is realistically hiring for.
Listing multiple possible openings for a limited headcount is common, but not necessarily nefarious. A company may be open to a junior, mid, or senior developer but have different expectations, compensation, and requirements for each of those titles. Posting different job listings allows you to cast a wider net without having to dilute the job descriptions too much.
> do you invest 10+ hours in a process where a job may not exist in the first place
The company isn’t going to spend the time walking someone through the hiring process if they don’t have any intention of hiring someone.
10 hours of interviewing is barely more than a single workday. It wasn’t long ago that interview processes required several rounds of phone screenings, interviews, and maybe testing before you were expected to come on-site for an entire day of in-person interviews - or more! I don’t think it’s unreasonable for a company to expect candidates to invest some time into going through an interview process. The phenomenon of hiring people into high paying jobs after a couple hours of casual interviews was largely an artifact of the recent tech bubble. It’s also part of the reason we’re seeing mass layoffs, IMO, as a lot of these companies hired so fast that they couldn’t reasonable screen everyone. It turned it “hire now, fire later if it doesn’t work out” when cash was plentiful.
It might not be nefarious, but if companies are putting out "feelers", and I'm investing ~30 hours per company, and half the companies I'm applying to are like this, then there's a huge waste of time (mine and theirs). I've started calling out this bullshit: "is there a job here, or is this a position to gauge the market?"
>10 hours of interviewing is barely more than a single workday.
It's never 10 hours. It's 5+ interviews, plus a take-home test (that can take ~10-20 hours), plus scheduling, prep, etc. It's never 10 hours. Stop validating shitty behaviour.
>I don’t think it’s unreasonable for a company to expect candidates to invest some time into going through an interview process.
I wouldn't mind, if there was a job on the other end. I can't even list the number of times I've gone through the whole interview process (at big companies!) and have been ghosted at the very end. I wish they'd stop wasting my time.
>The phenomenon of hiring people into high paying jobs after a couple hours of casual interviews was largely an artifact of the recent tech bubble.
That's how it's been most of history. 10-30 hours of interviews for a single job is a relatively new phenomenon.
>It’s also part of the reason we’re seeing mass layoffs
This is so false. We're in layoffs because we overhired, not because the interview process is too easy.
I just want to say that this is a much higher number than necessary. If you've got skills there's just no reason to ever accept more than 90-120 minutes total before the on-site. That's plenty to receive multiple top-of-market offers (or not top-of-market) even in the current market. Any company pushing trying to make an interview take this long on your side is not worth working at.
Playing devil's advocate if you don't want to do the take home test then they just filtered you out and actually is serving their desires on who they want to hire.
A reasonably-scoped take-home project is fine in isolation.
The problem is the sheer number of steps required, of which the project is just one step. For example for a recent position I looked at:
1. Initial interview with some HR person: 1 hour
2. Interview with a tech person and review some code sample (spot security issues, bugs etc): 1.5 hours
3. Take home project (supposed to take 2 hours, but you'll want to make it look good so you'll probably spend twice that): 4 hours
4. Another in-depth interview with a couple other tech people: 2 hours
5. Another interview with the CTO: 30 mins
6. References & background check.
That's not atypical. Round after round of interviews. It becomes an endurance test, where only the most dedicated will stay the distance. While the 8-10 hours might not seem much stretched out over several days, you want to add some prep, keep your calendar clear so it does eat up your spare time, especially if you are already working.
And that's just one job. What if you are interviewing at multiple companies?
Note the take-home is at the start of the process, not the end: so you can end up putting a lot of effort in before you have even cleared four or five other hurdles. Oh, and I don't even have an offer yet. It could well be the offer on the table isn't worth my time.
Now you could say "well, we only want dedicated people". Fine, but I'm dedicated in so far as I get paid to be working for you. I don't get paid to run your interview gauntlet. Maybe you want people willing to do free overtime?
And this is way more than it used to be maybe 10 years ago, and it's for small to medium sized companies, not FAANG or other big corps. Nor is it a feature of recent layoffs and resulting increase in the talent pool: this has been the case for a few years now.
Just how many companies are you putting that far down your funnel‽ I mean, that's a bunch of time, yes, but you should start filtering out companies at step 1. If you're trying to collect a dozen offers before jumping ship then yeah, sure, but that's quite a lot of offers! The other question is how many of those result in an offer? Because I can see the frustration of there being no payoff at the end if you're not getting an offer most times after step 6.
FWIW, last time I interviewed at Google, there was no take home test, so I don't know where people are copying that from but I don't think it's Google.
I'm not disagreeing with you. But, I think the optimal way to actually assess someones abilities would be to pay them one day's wages for the role that they would be going for and to clear one task with a interviewer instead of this maddening complexity of an interview. Honestly I have been thinking of getting a tutor to help me pass these tests.
Take home projects are not work from the company’s backlog. They’re tests and all candidates receive the same test.
It doesn’t make sense for a company to open up their code base and infrastructure to random candidates and ask them to work on it. That’s an IP and leak nightmare.
OTOH, if you are taking a paid contract job to work with a company on real work as a trial, you could definitely be violating contractual agreements with an employer. This type of interviewing is extremely rare, though. Few full time job holders would consider it, so it would be largely limited to unemployed people who have the time to do it.
Yeah this. There's often a presumption like "I'm a very talented software engineer and everyone should want to hire me and thus companies shouldn't design a hiring process that I personally find annoying."
Hiring is a matching process. If a company with an annoying hiring process is a bad match for you, that's fine.
In what sense does the company have more information? They have more information about the details of the job, sure, but the applicant has more details about themselves. Which is “more valuable” depends on the market I guess. But why do you say one party has strictly more information?
Posting multiple job listings targeting different salary ranges isn’t a “hack response”. It’s literally how you hire properly without a crystal ball to predict exactly who will apply.
Again, no company is going to drag candidates through interviews for jobs that don’t exist. I don’t understand why anything thinks that’s the case. Interviewing is work for the interviewers, too.
> no company is going to drag candidates through interviews for jobs that don’t exist
This happens all the time. The team will have an internal candidate they want, but HR dept is worried about optics of fairness, so the team is forced to put on a show by interviewing people who have no chance of being hired.
I have heard this but as I’ve only worked at startups I’ve never seen it play out in real life. How common is it that it happens “all the time”? Only at bigcorps?
Most of the companies laying off people are huge businesses that apply the most onerous of interview hurdle jumping practices.
They didn't cut down on the process, or the five stage interview processes during the last two years of over hiring, they doubled down on them.
There are very few careers where entire industries like leetcode, hackerrank, coderpad etc have been founded to promote the practice of making every Dev slog through a mass of made up crap intent on wasting the time of everyone involved to make HR feel like they've achieved something.
The company isn’t going to spend the time walking someone through the hiring process if they don’t have any intention of hiring someone.
Oh, the logical fallacy of appealing to logic.
I have personally seen companies post, interview, with no intention of hiring. No guff!
Case 1:
* "Just in case" they get a contract to provide thing X, they "want to be ready" to go.
Case 2:
* Forced to look at internal staff first, knowing full well they would not hire external, but going through the motions for appearance sake
Beyond the above two, I have heard:
* A government department interviewing, offering, and then the union hears of it, and challenges the new hire
* A company interviewing a dozen people, ready to hire, and a stakeholder suddenly thinking "let's contract this out instead"
* A company doing 3rd round, time consuming (for them and the candidates) interviews, after an offer, while waiting for the response. And I mean, scheduling and doing, not "already scheduled and doing".
I usually spend around 20hr on the test task they give me. On top of this there are at least 3/4 rounds of interview (spanning from half an hour to two hours).
I tend to make sure that the job actually exists though and I'm wary of small companies. I'm particularly avoiding the ones where I would be the only developer working on my domain/stack.
Congratulations on achieving this milestone and probably keeping your customers very satisfied along the way, but I eagerly look forward to the future where everyone is so sick of virtual assistants, bots, and knowledge bases that a low ratio is what gets celebrated as a growth milestone rather than a high ratio.
Automated triage is great for digital companies that want to scale cheaply, but not so great for the people who need to figure out how to usefully navigate them, with the brick wall support experience of Google/Facebook/etc being the already vivid example. It helped those companies grow and court techno-optimist investors, but nobody outside of their enterprise customers is happy about the customer service experience. Eventually, that becomes dirt on their reputation and works against their continued growth and success.
When I have a problem with a service my ultimate goal is to get it solved - as fast as possible.
If I can solve my problem though an automated support channel that’s actually better! Because I don’t need to wait for a human to do something. Computers don’t sleep, take lunch breaks, etc.
The problem with google/Facebook/etc isn’t that they don’t have human support. It’s that when your account gets locked out there’s no way of getting your problem solved. If a working useful automated support system existed few would complain.
I don't think many people will disagree. But, Google has been doing it longer than almost anyone and has an amazing technical team and it's still an incredibly frustrating experience. By all means, keep investing in the technology. But have a plan B that can solve the problem.
For better or worse, slow, biologically constrained humans can often understand and solve problems when given the authority to do so. (I'm well aware there are horrible human support options.)
Honestly, you hit the nail on the head on what drives me. Before this I was a PM, and way even before that- I was an Infra Engineer. I think that brick-wall of contact when working on some Enterprise tool was what got me. ESPECIALLY so when there was a bug blocking my company and it felt like no one cared.
When I first joined- this is why I would take great pains to respond to everyone extremely quickly. When I realized that was not sustainable, the focus then shifted to really making sure that our users are heard and their concerns are acted upon. Sure first contact SLA of 30 mins is great but- doesn't mean shit if we don't solve your problem.
So I think yes, tooling should be first. I think there is just a way for that tooling to serve the developer, not some OKR.
Agreed. Where I work now (Hivelocity) is a breath of fresh air. There are so many support techs, that every ticket is answered within minutes. It's definitely not cheap to do, but the customers are always happy when they can get almost instant support for their dedicated servers.
My client bought in the marketing slides of an Indian company that there was response within x hours of raising an incident, not actually solving but response.
It's basically a "hi, we started the triage see you", in another one, DocuSign to not name, with the premium support, we are basically redirected to their help page even after 2 or 3 exchanges for clarification.
Support is just awful everywhere. Hell, our management is asking the same with our L1-L2 ones for internal customer.
Not sure this is something I’d be bragging about. What happens when you do eventually have a major outage and need to rapidly provide reassurance and tailored support to hundreds of people. Like when Atlassian deleted thousands of JIRA tickets by mistake and seemed completely unprepared to scale up their support.
Is that something you can reasonably prepare for as a company? Like just keep a bunch of extra support people on payroll in case there's a catastrophic event?
It's about not optimizing for a single variable. If you're trying to reduce headcount (and payroll cost) as a single goal, your business becomes a brittle shell subject to disruption by any number of circumstances. Investing in some redundancy is responsible to your shareholders and respectful to your customers.
What a great question. Perhaps the answer is “not entirely” but draw up some best effort contingency plans (pool of contractors, insurance cover, etc). I still wouldn’t be highlighting how few support staff I have per customer like this in either case!
Ha I definitely agree with you there. While impressive from the company's standpoint, I'm not sure it's something I'd highlight either. If anything, learning this would steer me away as a prospective client.
> As a team of one, we were able to support 250k users, and now that we've crossed that bridge, our goal is to support two million users with our 2-person team for a 1M-to-1 ratio.
This is actually the original blogpost that we used to make our first hire!
> You will be working with our existing Support Engineer, Angelo - to build out processes, formalize policies, and build out integrations between systems to make it so that we can track and record issues.
I accidentally left that one open... but the Ashby interface is so confusing I don't know where to toggle the visibility. I will remove that and then wait for our jobs page to rebuild.
FYI, not disclosing at least minimum pay means applicants should assume pay will be below average. Also, it says “remote - anywhere” at the top, and if you are hiring remote in California, Colorado, New York City, or Washington state, employers are legally required to advertise pay range on job listings and possibly other compensation details.
> At Railway, we provide best in class benefits. Great salary, full health benefits including dependents, strong equity grants, equipment stipend, and much more. For more details, check back on the main careers page.
Hey! Ashby co-founder here, you can either close the job (if you’re no longer hiring) or unpublished the job posting, more here (https://www.notion.so/How-do-I-set-up-jobs-089229a8631f4b9fb...). Feel free to reach out to support@ashbyhq.com and we can chat there (if you haven’t already)
Can anyone comment on the security implications of using a service like this, render.com, fly.io, etc vs. rolling your own infra on AWS EC2 and friends?
It's possible for a PaaS to improve your security posture by implementing many of the security controls you'd otherwise be responsible for yourself. Every PaaS provider has a Shared Responsibility Model, like this one from AWS [0], and a good PaaS can eat up much of what would otherwise be your responsibility as an AWS customer: network architecture, secure configuration, IAM, system access (and auditing), intrusion detection, etc.
On the other hand, many PaaS providers obfuscate their security implementation, and ultimately your data could be compromised by their mistakes. Things you should look for when evaluating PaaS providers:
- How are resources, networks, etc. separated/isolated per customer?
- What are YOUR security responsibilities on the platform?
- How transparent is the provider about their security controls? Do they have security whitepapers, SOC 2 reports, etc. that are transparent and legit? Better yet, can they prove to you in the product how security controls are being implemented?
Disclaimer: I'm the CEO and founder of Aptible [1], a PaaS specifically built to meet and prove security requirements for companies in regulated/high-compliance environments.
I have a question about endpoints. It seems like you guys charge per endpoint. I don't quite understand this. So if I'm developing an api only application, every api endpoint I develop in my application will be charged? And for Aptible to keep track, would I have to register each endpoint I develop?
If my application was just serving dynamic html pages, I wouldn't be charged per url of my application right? So why would I be charged per api endpoint?
EDIT:
Another question. Do you guys offer any SSO solutions? If not, if I used say Auth0 for authentication, are there any issues with integrating with Aptible?
"Endpoints" on Aptible are load balancers. So you would pay for each load balancer your API needs (usually just 1), not every API endpoint. Thanks for the feedback on that — we will update the language to be clear that these are load balancers, not API endpoints.
We don't provide a solution for implementing SSO in your own application, but many of our customers do integrate with Auth0 without issue. For your own team's access _to Aptible_, we offer SSO through SAML integration with any provider (Google, Okta): https://deploy-docs.aptible.com/docs/sso
Another question. I tried looking for the answer on the website, but couldn't find it. Is it possible to use my own AWS account and integrate it with Aptible or does Aptible provide their AWS assets for my use? The former would be ideal for us as we would like to own (more accurately, rent them ourselves) all of our AWS assets and just have someone like Aptible help us to manage them.
Aptible hosts (and pays for) AWS resources on your behalf, similar to Heroku/Render/Railway. Last year, we built support for integrating Aptible into your own AWS account, but only a handful of existing customers are currently using that, and it's not available in the product by default. I'd be interested to learn why you prefer this model. If you're willing to chat about it, my email is in my profile.
Alternatively, have you checked out other PaaS-in-your-own-IaaS solutions like:
Is there something specific you've got in mind? There are a ton of "it depends" type questions in here, but generally speaking I'd argue that rolling your own infra has some parallels with rolling your own crypto. There are countless mistakes you can make when doing it yourself, and a reputable entity that's been doing it for a bit has probably already made those mistakes or, at least, considered them. Quadruply so if they've got certifications of any kind.
At scale, or with a seasoned ops team/team member, the scenario is a bit different, but if you're asking "is it more secure for a few full-stack developers hacking at a startup to roll their own infra or use something like fly.io" I feel preeetty comfortable saying the latter is going to be more secure.
I work at Amazon and most teams do not have a single support engineer despite serving hundreds of millions of customers. The number of employees in the position X is absolutely meaningless.
It depends on the type of product. If you're selling to consumers versus businesses, engineers versus HR, how mission critical your product is, etc... Given they're selling a mission critical piece of infrastructure it's a high ratio.
It's typically in the form of access to features that are reserved for higher paying "enterprise" customers. Cloudflare's MVP program does this for example.
Unbelievable how a single developer... or a handful runs an entire organization. I hope the developer gets paid handsomely and not just in exposure through this blog :)
What an impressive company. A good reminder that, even in a market with umpteen competitors, success comes down to execution. Hope they keep up the good work.
Railway does look impressive. However, as someone in the market for a Heroku alternative - I’d say there really aren’t any Heroku competitors. At least nothing directly comparable. The thing that keeps me (and I’m sure other small business owners) tied to Heroku is just how much they take care of for you. I literally never ever want to think about my infrastructure beyond initial setup. Heroku, to my knowledge, is the only provider that allows me to do this while servicing more than 100,000 users.
Oh there are numerous alternatives to Heroku. Just look for "PaaS" and your favourite software components (programming language, DB, CDN etc) and you'll find a list.
I find Platform.sh is an excellent alternative to Heroku, dare I say better. Same thing - configure once and operate forever, scale as you need...
Really Heroku used to be a big name but it is now declining, and lets face it - many used it just because it had a tiny plan for free.
If this is the kind of experience you’re looking for I would check out Platform.sh. (Full admission, I work there)
You get a good level of abstraction for infrastructure (github.com/platformsh-templates for examples) that gets provisioned automatically, plus a built-in relationship between branches and envs that results in true staging environments for every pull request.
Like others have said there are a number of Heroku alternatives out there that are more or less viable to meet your requirements, which I've gathered to be:
- Serving >100k users
- Helping you to achieve SOC 2
In my capacity as one of the leaders at a Heroku alternative PaaS, I've studied the PaaS market a bit to understand the space and available alternatives to Heroku. Here's what I've found about some of the most popular:
- Fly is managing its own infrastructure allowing it to be extremely competitive on cost. But on the flip side, its heavy focus on infrastructure is missing the “managed” options that make PaaS so valuable, such as a true Managed Database offering. This IMO makes it less of a viable alternative to Heroku.
- Render is offering a more truly “managed” alternative, and is innovating on cost as well. But it’s early and is still missing some table stakes reliability features that you'd probably expect from a Heroku alternative.
- Railway has a blockbuster FTUX, I love deploying and using PostgreSQL databases in the UI without even signing up. Coincidentally probably how it got to its count of 250k developers. But it’s own docs caution that it’s not exactly production ready, especially its databases.
- Platform.sh has grown really well by focusing on enterprise marketing teams and their use cases. I think this is a great niche for them and has paid off well. In their capacity of working with enterprises I'm sure they could handle SOC 2, etc.
- Aptible has run critical web apps and APIs dealing with sensitive data for hundreds of companies and has helped a few go public or get to billion dollar acquisitions. I am certainly biased, but Aptible seems to be the only non-Heroku PaaS focused on product/engineering teams that has repeatedly handled true "production" requirements, like your larger user base (many of our customers fit this description) and SOC 2 (most of our customers use our security & compliance dashboard for this). But that comes at a cost: Aptible is typically more expensive than the others, perhaps save for Platform.sh.
Disclaimer: I'm one of the leaders at Aptible, which in my (admittedly biased) view is the best positioned alternative to Heroku for product/engineering teams that have any sort of scale or production use case.
(Render CEO) Other than Postgres PITR and HA which are both in active development, are there other 'table stakes reliability features' on your list for Render?
With bad documentation on buildpack, it's hard for me to go on with Railway. (For example, there's no sample or docs at all for how to build image with multiple buildpacks like in heroku).
And these days, good documentation is 1st criteria to trust a platform / framework / library.
I think it's interesting that their whole shtick is "all to serve the developer" but they just kept overloading their own engineers, moving from new solution to new solution, before they just decided to hire more people.
Assuming that the support experience for the customers is actually good, I'm amazed they've managed to scale their support efforts that far. I work on a similar type of product, except in-house in an organization with around 2000-2500 engineers, and handling support has by far been the hardest thing to scale as we've grown. Even with documentation available, internal Stack Overflow with plenty of common questions answered, unified search, Slack integrations, error messages linking directly to documentation, pre-defined observability dashboards and monitors, we still get so many questions that it's a full time job staying on top of it. Can't imagine having 100x that amount of users.
> I am convinced that Software Engineering is more of an art than an engineering practice.
Back in 2010, Monash University’s Bachelor of Software Engineering had a unit ENG1061 Engineering Profession mandatory for the degree (for a terrible reason: Engineers Australia accreditation of the degree, which no one that I ever talked to cared about in the slightest). The first lecture listed The 17 Branches of Engineering. Guess what wasn’t one of them. It went downhill from there.
How did you measure that 250k? That’s the population of like Iceland. Sounds like a lot, but perhaps my “how many golfballs fit in a schoolbus” guesstimate game is off.
I have spent the last 10 minutes on their site and am unable to figure out what the pricing even is.
Going by the top of their pricing page (https://railway.app/pricing): $10/GB per month RAM & $20/vCPU per month is actually pretty expensive when compared to services like fly.io and even EC2/Azure.
Apart from that, what vCPUs are these exactly? What are the bandwidth costs? Custom domains? Certificates? Load balancing? Disks? Databases?
Clicking "Choose Plan" takes you to a login page, but then if you log in the pricing page disappears altogether.
One thing that didn't make it into the article (I ramble and rant) is how I set it so at one point that Teams were entitled to a reply from me or the founder 24/7. This broke nearly instantly after 50 Teams.
At the moment we don't but I spoke to the fmr. Head of Support at Stripe and he told me we should think about our product coverage like an API, some parts of the product (builds for example) should be more critical on response times than others. My main goal this year is to publish an SLA table so that we can work with ever larger customers setting the right expectation.
I asked this because the interview process has this step where you ask the candidates to do a project and than go over it with someone. One of these little projects is design our api or build a github issue viewer frontend/backend. You still have 4 more rounds after someone invested all that time.
The amount of effort to work here seems high and the chances of the position existing and you filling it is so low. I feel bad for the many looking for work.. do you invest 10+ hours in a process where a job may not exist in the first place and the company brags about the goal of one person servicing a million