New Level of Interview Hell
old.reddit.com
old.reddit.com
I’m Juraj, Co-Founder & CEO of Better Stack — I designed this interview process so let me share why I think a PHP project is a good idea when interviewing for a full-stack position where you work mostly in Rails.
First, please understand how we operate.
We’re a small group of full-stack engineers. By ‘full-stack’ I mean that our engineers build products from the ground up end-to-end. There’s no artificial boundary between ‘backend engineers’ and ‘frontend engineers’, ‘database engineers’, and ‘SREs’, etc.
This means we move very fast. There are almost no meetings. No ‘sprint planning sessions’. No brainstorming. No need to ask for a permission from a different team to agree on a common API before you start implementing. You can get to flow, play your favorite music, write code and deploy the feature the same day.
We typically work with very senior people, many ex CTOs and VPs of Engineering. The idea is to have tiny teams of super experienced people.
If you love hacking on side-projects and writing software, you’d typically like it here.
…
Now, why do we ask you to implement a feature into a terrible PHP code from 10 years as a part of our interviews?
Multiple reasons.
A) To test your pain threshold.
Is 4 hours of PHP too painful? Then it’s probably better if you don’t continue in the interview process as you probably wouldn’t enjoy working here.
If 4 hours of PHP is too painful, you’d resign from the job the moment I’d ask you to implement a Terraform provider; or a data transformation function in VRL; or a wasm-compiled function in AssemblyScript or debug a conntrack issue at 3am during a downtime.
I had Rails engineer refusing to write a Dockerfile, “because it’s some else’s job to deploy the code”. That approach unfortunately doesn’t work with us. And if you do only want to write JavaScript and touch no other technology, that’s ok! Please just find a different company that works like that.
B) I consider PHP + JavaScript general knowledge.
One half of our engineers didn’t work with Rails before starting at Better Stack.
We don’t screen for Rails. We don’t screen for any single technology, in fact. We screen for general knowledge about developing software. The best engineers can pick up any reasonable technology quickly.
I want to work with you if you’re able to implement the test project and deploy it in an afternoon even with a technology you never worked with.
Great engineers who never worked with PHP successfully did this years ago. These days it’s even easier since we have Claude, Cursor, GPT o1.
C) Can you write software without modern frameworks? Do you understand how stuff works under the hood?
The task itself is so simple yet so many people mess up very basic things. I obviously can’t share our evaluation check list, but I can tell you that 50% of submitted projects are vulnerable to XSS, for example.
Do you blindly rely on the latest frameworks, hosted databases and PaaS to build your applications; do you rely on your teammates to catch your mistakes in a PR review and a different team of SREs to deploy your code to production? Or do you truly understand how things work under the hood? Are you going to actually test the page’s mobile responsiveness when you implement a UI? Would you implement the very basic best practices of UI usability or you don’t care about usability at all as long as the data gets saved in the database?
D) We test your personality.
Startups are typically a high-pressure environment.
How will you act if you disagree with me/your colleagues? We treasure the atmosphere at the company. We don’t work with brilliant jerks.
Some candidates simply politely reply: “Would it be ok if I implement it in Rails and Tailwind from scratch instead?” We say ‘Sure!’ and if the project is good we extend them an offer.
Some people start attacking us with aggressive responses. That’s a self-selection.
E) When do you consider the project being ‘done’?
What does production-ready mean to you? Some folks never shipped a production software on their own.
There’s no other person checking your work at Better Stack before it goes live. You can design, develop and deploy to production on your own. Will you ship good stuff or half-baked products? Will you ship secure features or introduce a security vulnerability?
The project is intentionally vaguely defined so that we see what you consider being ‘done’.
F) This is a paid project.
I don’t expect you to work for free. We kindly ask you to name your rate and issue us an invoice and we pay what you ask for even when we reject you. That sounds fair to me.
…
A good interview process is a glimpse into what the actual work is like. Interview process is not supposed to be pleasurable to all candidates.
So if you don’t like the process, the tasks or the interviewers — that’s alright! I want to sincerely thank you for investing your time into the process and giving it a shot, but it’d be better if you worked somewhere else. That’s what a good interview process does.
We do our best to be nice. To run a fast process. To explain why we do things the way we do them. To pay you for the assignment we ask you to implement at home. In F2F, if you don’t know an answer to a question we aim to educate and explain. We always ask for feedback.
And we do make many mistakes along the way, too — the company is growing fast and “when you chop wood, splinters fly.” So I apologize if you interviewed with us and had a bad experience.
Interviews are an approximation game: we try to guess if you’d enjoy working with us in a very limited amount of time.
I can’t win a popular vote here as we give offers to <1% of candidates. But I’m always delighted when a rejected candidate replies to our feedback email saying they learned a lot during the process and/or re-apply after a year.
The truth is that many software engineers would probably never enjoy working at a startup. Big tech and a fast growing startup is a very different environment. And that’s completely ok! Everyone is not meant to be working at startups. But self-awareness is key.
I wrote more about how we work here (https://betterstack.com/careers/engineering) and here (https://juraj.blog/p/100x-software-engineering). I plan on writing a series of blog posts explaining why run the rest of the interview process the way we do.
Thanks for reading and all the best!
Juraj
http://betterstack.com/careers
https://linkedin.com/in/jurajmasar/
P.S. Use Better Stack for your next project! https://betterstack.com
You found out very quickly to drop out of the interview process, saving yourself a lot of time.
Even so it’s good to get a nice clear “do not proceed with us, dragons be here” message from the employer.
The only caveat here is the required level of "readiness" for this deployment. In 4 hours (and PHP) it's going to be a PoC that will do what they asked, without extras that make it production-ready.
Years and years ago I went for an interview at Computer Associates, who were still doing accounting software at the time.
They gave me a test with idiotic questions about C, where the examples obviously had undefined behavior. Like what is the output of code that takes the address of a variable of type short, next to another such a variable, and then casts it to a long * pointer and retrieves the value.
I had a printed copy of ISO C in my briefcase and showed them chapter and verse how that is undefined behavior. I was told I'm not "doing very well here".
No hire!
They just wanted people to know what the Microsoft Visual C compiler (or whatever they they were using) does with various undefined behavior, because they have such stuff in their codebase. I could have guessed "right" on most of it, but homie don't play dat.
I was taken aback, so I went to the interviewer: how am I supposed to answer this, is it a trick question about undefined behavior? The compiler is allowed to just flag that with a diagnostic and even terminate after that.
He was like, what do you mean, undefined? It's just straightforward: what is the value? He had no idea what undefined means, or what is a language standard.
Where can I sign up? Only somewhat joking. Does anyone still remember how fast things could be when we weren't waiting for multiple layers of build processes and container deployments?