I will do take-home assignments (assuming 4~8h of work) or 4h+ onsite only if I am (quite-to-very) interested in the company. This is either the company is famous so I know them well, or there was a good interview process and they passed all of my questions/no red flags. If I'm on the verge of rejecting a company and they ask me for a sudden 4h+ process, sorry but not.
I live in Japan so it's been interesting as there's vastly different thinking companies, you have from the most modern flexible silicon-valley-like company (few, but there are) to very traditional ones that might even be confused when you reject them (again few, but some). Last time I interviewed I told a company I wasn't interested in their offer, only to receive an email later telling me they were not interested in hiring me. I could guess HR marking me as a no-hire was a lot better for that interviewer than marking me as rejecting them, but still made me laugh a bit of how much "no, I am breaking up with you" it sounded like.
I think this is the broken assumption—there are a lot of us who simply are willing to accept a sub-FAANG wage in exchange for a work environment/interview process that we feel respects us.
Could I use more money? Probably. But would I be happier with more? The research suggests I wouldn't.
I already make a 90th percentile income for my area, and I don't feel that investing additional mental and emotional resources in maximizing salary is the best route forward for pursuing happiness. I think that at this point there are other axes to optimize on that provide greater marginal gains to happiness.
I think for most people amounts up to something like 200-500k/yr (depending on COL) would provide increased happiness. Basically, if you ever have to worry about not having enough money, you could stand to make more.
Of course that doesn't mean it's necessarily worthwhile to work more to achieve that, that would be a personal decision you have to make yourself.
All the interviews at Google are 45 minutes, and when I interviewed only 2 had coding, so there was realistically 70-80 minutes of coding that day. I did maybe 15 minutes in a phone screen on an earlier date. Even if you did only 60 minutes for the whole process, you really aren't that far off from a typical FAANG.
You signup for a new Amazon job. You are a senior developer you expect to make $400,000 with the stocks/salary. Your base outside of California is 139,000 or 129,000. After year 1 only 5% vests.. after year two 15%.. the average employment length is 1.5 years. So you end up with $140,000/150,000 for working 16 hour days. If you manage to stay 10 years you could retire..(you have to because at this point you hate life) but they don't want people staying at the same level so you need to get a promotion when the 4 year vest up or you will be at your base. Getting one takes the right project and is hard and requires a breakthrough project.
Most people 95% of developers never worked at a faang and those who have, on average worked for 1.5 years. Very few are still employed or seeking faang employment. Faangs make popular entry level position but very difficult to keep for life but if you can survive many years you usually leave the field or create your own startup because of burnout. Faang adjacent companies can be the worst of all worlds same issues worse pay/upside.
I've had interviews with heavy LC and ones where I got plain old fizzbuzz and there wasn't much difference in staff competence or how quickly we delivered.
If anything, the place with the low bar had more well rounded peers I wanted to spend time with after work.
In the world outside HN I very rarely encountered people who'd turn away from any kind of hiring process. Maybe one in fifty candidates?.. I don't have the numbers, but I think I only met such people twice in my life.
I bailed from interviews for different reasons, but I think that homework is a legit way to test someone's skills, so I wouldn't mind that.
The reasons I cut the hiring process short in my job hunts were most commonly:
1. Employer is an MS Windows shop. Sometimes it's hard to figure this out from the job posting.
2. Employer requires employees to use company-provided tools s.a. code editor, or antivirus etc. In other words, an over-reaching IT.
3. Crazy / not very smart / borderline criminal employer. Examples include a guy who had "scrum cards" deck on his desk and essentially showed me to the door when I asked if they used this stuff for real. Another one who couldn't get my homework to run, asked for a Docker image, couldn't run that either, asked for a VM image, couldn't run that either...
----
There's one litmus test I have when interviewing that turned out to be surprisingly precise, and I don't know why. I ask potential employer if they ever use git-merge. If the answer is "no", the company turns out to be intelligent people who are nice to work with, and if the answer is anything else, it turns out to be dysfunctional in more ways than just infra. They will have toxic culture, under-the-carpet skirmishes where each department undermines another department, while at the same time trying to do as little work as possible.
As you can imagine, unfortunately, I had to take jobs where the employer answered "yes" or "sometimes" etc. That's how I know :(
For all I know, I once joined a company where the policy was to only do squash-merges. I left from there at the brink of mental breakdown.
And what's wrong with merge? How do you even use git without merging?
In theory I don't mind them. In practice I've found that I more often encounter a scenario where I wish a change had been split to smaller commits rather than the scenario where there were too many commits to go through.
Anyway... I intended my example as an explicitly anecdotal evidence to counter the seemingly absurd suggestion of using Git without ever using merge. Feels like going back to subversion or CVS.
For more reliable code-bases you want to do the following:
* Run tests on each commit when accepting PRs.
* Be able to remove or edit intermediate commits, if you find that they've created problems afterwards.
* Only have one path from past to the future.
This is so because if want to use git-bisect, and instead of deleting faulty code you reverted it, the command will keep failing on the code that you've already fixed, and there's nothing you can do about it. git-bisect also has to follow one and only path from the past to the future because if you don't, then, at best, you get an combinatorial explosion of possible paths git-bisect may take, and at worst, some of these paths will fail, but others will not.
So, what ends up happening is this: people who use merges are like people who never clean up their apartment. For some it will take longer, than for others, but, inevitably, the apartment will become a filthy mess. But this is just a symptom of people being afraid of not understanding their code, being afraid of making big changes, undoing things committed to long ago.
This fear is usually an indication that people aren't good at the technology they are using. They would be too afraid to delete code because "what if it breaks something?" -- and nobody can tell authoritatively "no it doesn't". In a situation like this any change in technology s.a. using a different version of the same tool, or replacing the tool altogether will be almost impossible to implement because of the fear.
It's also usually very characteristic of places like this to be afraid of knowing / learning the underlying technology, the one that supports the entire company's stack. Eg. if it's a Python shop, then they'd be opposed to writing Python modules in C, even though this is how Python typically works, because they are afraid that they won't understand this code and one day will end up with a "magical" program that sometimes fails, but nobody knows why.
It's also usually the people who won't even try an unpopular technology, even if the benefits were huge, based on their fear of not having expertise to deal with it. Eg. XML schemas are hugely superior to JSON schemas, and if you want to validate your inputs, XML is just a better tool for this, but the company I'm describing will never consider using it because they are afraid of not being able to find people willing to work with DTD / XSL / RNG.
Such a company will never consider self-hosting, and will pay through the nose for the expertise of others, being mortally scared by a prospect of running their own infrastructure.
----
And... this is the majority profile. The problem is, this is not a winner's profile. It's a scrapping-by profile. It puts an individual programmer in the situation where there's no need and no reward for bettering themselves. Where management is antagonistic to programmers because they are in a conflicting situation, where on one hand they want to give customers more stuff, but on the other hand they are too afraid to make more stuff, since it may deprive them of the stuff they already have. So programmers are punished whether they do or whether they don't. It's where cargo cult flourishes. Basically, Dillbert comic before its author went into politics.
Last 10 years no take home. Today it's coding something in a vc meeting, maybe in a web browser or coding env. Maybe beginners do some coding.
These developers may go their entire careers without ever reversing a binary tree on a whiteboard while juggling two bowling balls on a unicycle.
Well, I personally have always refused to do take-home interviews but happily will do live coding and systems design interviews.
For me it's about respect and power imbalance. A company asking me to do work without them putting in equal effort sets a tone for a culture I personally don't ever want to be a part of.
Like I find take-home interviews disrespectful.
Time-bounded interviews with an interviewer also there (aka FAANG style onsites with 4 hours of interviews) is far and away my preferred process, especially if I can do them all at once. One problem I've seen in a remote friendly world is companies wanting to spread the interviews out over multiple days.
You see people on HN balk at 500k+ engineering jobs even existing, so I think that's your answer.
Or startups. :)
Of course many carpenters work as contractors so that's why it seems a bit silly.
My buddy just got a job at a high-end cocktail bar as a bartender. Part of the interview process was asking him to mix a drink.
Gordon Ramsay has talked about how he'll interview chefs by asking them to make scrambled eggs.
Actors, even famous ones, generally have to 'read' for roles in order to land them.
Musicians interview for seats in symphonies by playing music.
MBAs have to do case studies to land jobs at high end consulting firms.
Hell I applied to Taco Bell as a kid and they made me take a short math test to prove I knew how to make change.
I could give similar examples for dozens of other jobs.
The cases where you don't need to demonstrate some skill in order to get the job generally fall into a few categories:
- There's some outside certifying body like the Bar, CPA, PE, various tradesmen unions, or all the licenses like a CDL.
- The jobs are undifferentiated so the workers are fungible (no special skills required).
- Job skill is immediately apparent (less than two weeks to know for certain if someone can do the job or not).
- The cost of a bad hire is low so you're willing to eat the cost and just cut the workers how don't work out.
Lately it seems take home projects are more and more common and these do take 8+ hours. If you want the job.
Here's what happens if you want to move to a "different place".
Say, you go to a different country: you have to spend upwards from a few month, but likely few years to confirm your degree. You won't need a stage, but you will not become an attending right away. In many cases there aren't even analogous positions if you move countries, unless medical systems are very similar, so, in most likelihood you will have to do at least a good chunk of residency training all over again. This will also be usually compounded by studying a new language to a very high degree as doctors are expected to produce a lot of written reports / engage in written communication, and, unlike programmers who almost universally use English regardless of the country they work in, doctors absolutely have to have good command of the local language(s).
Similarly, if you move between different medical organizations which manage hospitals. Sans the language requirements. However, within the same country hospitals will usually be more similar than between countries. Anyways, most hospitals will have fixed dates when job applications are processed, and even if you are extremely lucky and you don't need to redo any of your previous residency (both systems use the same PACS system, same or very similar internal organization etc.) you will still have to wait until the "draft" date. Typically, and due to competition, doctors will go to the hospital they intend to work at anyways before the "draft" date.
Even within the same hospital, if you want to move to a different department, you will still do residency, at least in part. I.e. say, you were already an attending in internal medicine, and you want to move to radiology: then maybe instead of 4 years, you'll do 3 years residency.
----
The above has a lot of compounding factors. Huge waiting times to get a position lead to doctors holding on to their positions with a lot more devotion than programmers. In many cases it's a job for life.
Because hospitals have to be in geographically diverse areas, they cannot, like programmers, all bunch together in one or two cities in a country and jump jobs w/o moving to a different apartment / house. A lot of hospitals thus include accommodation programs, which make it even harder to switch jobs.
It's very common for doctors to marry doctors. This makes some things easier, but it also means that if you need to switch jobs, then you have to do it in lockstep with your spouse.
Not in the least, if you move from a "less prestigious" country to a "more prestigious" country, you are almost automatically downgraded in your rank, and if you want the equivalent job, you'll have to jump through the same hoops the second time.
All of this is still not true in a most simple case, so getting job at a different hospital in the same specialization. Ex. in Poland most doctors are hired in multiple hospitals at the same time.
Genuinely curious how does this work? Do they get paid per the number of hospitals who hired them? How do they go to work? How do they know what hospital to go to?
PS. My wife is a doctor, and I had to live through what I described. So, none of that is invented, it's just what I see happen to her and to her colleagues. To make this more concrete, she was an attending in emergency department and wanted to switch to radiology. In her case this resulted in the full 4 years of study on top of about half a year of just showing up in the hospital and tagging along with the radiology team. (This was in Israel, one of the central hospitals). One of her colleagues was a transfer from internal medicine (also an attending), and he was doing 3 years of study to get into radiology. Another was a Russian emigrant doctor with about 10 years of practice from a hospital in St. Petersburg. He was also doing a 3 year of residency.
They also had two people drop out of the residency just during the year my wife was there (before she gave it up), and that's out of a group of six residents. One was a Brazilian emigrant, who eventually decided to go back to Brazil and another one was a guy who was an Israeli, but received his degree in Romania, which was cheaper, I guess. He just couldn't pull it up, and eventually was let go from the program.
The Russian guy was also on the verge of leaving due to some bad blood between him and the head of the department. The head was actively trying to sabotage him and make him leave for god knows what reason. The Russian guy though, despite having some sort of a chronic illness was spending multiple days in a row w/o leaving the hospital.
I mean, back to my original point: I saw nothing that could come close in the programming world. And the fuss people here make about home exercises is just a sign of being way, way overly privileged compared to the majority of the workforce. By which I don't mean to say programmers should suffer like everyone else, rather everyone else has to get better conditions. It's just of all people, presently, programmer should probably show more comradery with other paid workers instead of complaining about their own issues.
They have duty schedules, so they know where they should be at a given time. They have contracts signed with each hospital, like any employee. They can also work in private healthcare at the same time. It's just the case of setting up a schedules so they won't collide.
> she was an attending in emergency department and wanted to switch to radiology. In her case this resulted in the full 4 years of study on top of about half a year of just showing up in the hospital and tagging along with the radiology team.
That's normal because this is a specialization change. Not many doctors change specs or have more than one in most cases, at least in Poland.
How long is the lecture? 1hr? That doesn't sound bad compared to a 20hr programming assignment!!