The multiple rounds, take home test + online examination, followed by 3 interviews etc nonsense has been a part of tech interviews for the past few years. Perhaps more people are exposed to it now because they haven't been seriously job hunting until the recent bloodbath of layoffs, but it's certainly not a new thing. I think there's many reasons:
1. There's a lot of risk aversion in corporate culture these days, the cost of a bad hire can be very high and nobody wants to be held responsible. By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
2. It's an endurance test. Someone who can power their way through round after round of interviews, home projects, online tests and so on shows good "work ethic" or at least a genuine interest in the job.
3. Cargo-culting FAANG. If Google or Meta do this, then we should too (even though we're a tiny startup). It's a bit like picking microservices or Kubernetes: there's good use cases, but for a lot of projects they are overkill.
4. Concern about discrimination: companies are scared of showing bias (whether against or for certain ethnic groups, genders etc) and a formal process should in theory be meritocratic than the old days of "let's just have a quick chat and hire based on gut feeling".
There's good reasons here, but it's probably gone to extremes, particularly for positions at smaller companies with corresponding smaller salaries and benefits.
Point 3 is pretty important. I have seen so many small companies, that did not need really the very best engineer on the world to do their C# API suddenly ask Google questions straight from the "Cracking the coding interview".
Asking a 21 year old about a recursive O(nlogn) algorithm solution or how many ping pong balls fit on an airbus because you heard Google asks it when all you need is someone who can write a good integration test suite, use springboot, and create documentation for the clients to make the API useable and scalable is such a weird way to go about it.
And it seems entirely based on "if FAANG does it, it must be right".
The hardest interview in my life was a long time ago when I tried getting a part time/side job updating content on a mostly static PHP website (no database or backend). Thought this would be a nice way to get some extra beer money or something. The interviewer was the person who was currently maintaining the site and had just graduated from Yale and wanted to move on. Not a single question about PHP, javascript, HTML, instead question after question about implementing various algorithms in pseudo code. I figure he was asking me questions from a textbook or something. I didn't get the job.
Been a while since I've been in an interview but everything has been cake since.
I'll point out just one side effect. A highly qualified candidate interviews with three companies. One does two interviews in a week and extends an offer. The others take two weeks to get back to the candidate, then do two interviews and a take home, then two more rounds of interview. Meanwhile, the first offer is on the clock.
The only reason not to accept the first offer is because one of the other companies is that much better to work for. So the companies with the most onerous processes lose out on the best candidates or have to offer double the compensation to keep them in the maze.
The reality is that most companies can do fine with average employees. Bad hiring practices that lower the talent or increase costs don't kill them.
But the silly thing it, the convoluted interviews don't avoid the risk of a bad hire because they test for the wrong things.
The analogy I use is that it's like a hospital trying to hire a heart surgeon by extensively grilling candidates on trick questions about organic chemistry. I mean sure, the surgeons probably took that class a few decades ago prior to medical school. So they end up with surgeons that are wizards in organic chemistry but might well not know how to use a scalpel or know where the heart is.
> I've yet to see any evidence that it actually does reduce bad hires
And the OP's own point "responsibility is diluted so if there's a bad hire you can blame the process rather than one manager" would be needless if the process actually did avoid bad hires.
It's not a reasoning I would agree with either. The core of my original comment is "avoid responsibility": people don't want to be held responsible for a bad hire (or a discrimination lawsuit), so adding multiple rounds to the process shares that responsibility among as many other people as possible. By cargo-culting from FAANG you can also use the "nobody got fired for buying IBM" argument and this dilutes responsibility further.
So does that actually reduce bad hires (or increase good to excellent hires)? Probably not, but that's not really the purpose of all this theatre. The purpose is that if there's a bad hire, do I, personally, get the blame?
I actually ran into this. I was considering two companies, both about equivalent in terms of being "places I would want to work for", but one was quick to turn around with an offer and the other dragged their feet. I went with the company that made the offer. The other company I never heard from again, despite their engineering director totally assuring me "we get back to every candidate".
I think this actually works in their favor. If a candidate invests a week into you, they can only match that commitment a few times with other companies, and they might not actually get offers everywhere. Then you don't have to negotiate offers as hard, and they are more likely to accept your offer.
If candidates can get an offer after only a half day, they may as well have a dozen options, and you only have a 1/N chance of getting picked.
So your premise is that a company should draw out their interviewing process so that the top 60% of candidates will accept offers elsewhere and they can lowball the 40% that stick it out? And you justify this because they would only have a 10% chance of landing any of the good candidates?
From the company point of view that might make sense if they don't think about the consequences. But for the person, since we all know that usually any such projects are silently rejected without explanation it's totally not worth the effort.
Having been on the inside watching some people review take-home projects and arbitrarily reject them for the most random reasons ("I don't like the way he writes comments, what a loser") I also have zero faith on them being evaluated fairly.
The only way I'd ever consider doing any kind of endurance project for an interview is if the company guarantees results if I put in the effort. Could be something like: Write code to interact with and/or provide these well-documented APIs, it'll be run against a test suite where I can see the results and it needs to meet xyz performance criteria and if you can deliver it in X hours or less we guarantee a competitive offer. Only then would it be worth the work.
But to spend a lot of time just to be ghosted? Big no to that.
Companies should be hiring people on a contract basis to perform REAL WORK. This work should ideally be the very type of work they would be doing if they were hired full time.
If they do a good job, then great! Hire them on full time.
If they don't do a good job, but they meet the acceptance criteria of the contract, then they get paid, but don't get hired full time.
If they don't complete the contract requirements, then they don't get paid at all.
This arrangement is completely fair to both parties, and doesn't waste anyone's time. It's a win/win scenario.
Unfortunately, most companies are too lazy to set up a hiring process that looks like this.
These are actually all great reasons. Speaking from experience a bad hire can be extremely detrimental.
While all valid points i do dislike how often those tests and interviews focus a lot on areas that you will not be doing in the role. This is where I see the biggest frustrations. When we hire we do try to tailer the interview process in a related to the work involved as possible. It adds confidence that we have hired the right candidate for the job.
But usually there’s a 90 or 120-day probation period for new hires. How about letting them “interview” for the job, on the job. Screen them obviously, but after that… I mean the best way to see if they’re a good hire is to actually hire them. There’s no interview question or interview process that can perfectly duplicate that.
From the point of view of the applicant, I wonder if I would prefer a long probation period over a long interview period.
If I'm unemployed and I have bills to pay, a paid probation period is the better option - even if I get fired after 90 days, that's still 3 months' salary. On the other hand, if I already have a job, joining another company is a big risk - I'm giving up a comfortable position for a job I might lose in 90 days if it doesn't work out - maybe I'll be in over my head, maybe I don't get along with the manager or the team, whatever. A long interview process gives me plenty of opportunity to gauge my prospective employers and back out at any point.
Sure, but, at least in my experience, new hires are ALWAYS on probation. So to me the status quo is this: you get vetted "harshly" in the interview process, then you have to clear the probation period. That said, I think it's pretty much a given you clear the probation period if you don't clash with coworkers, and write decent code. During your first ~90 days, you're ramping up, learning the company's procedures and coding conventions (and code base itself), and getting to know your coworkers... so I think the only time probation really bites you is if it's a bad fit culturally (which I would think you're at higher risk for the smaller the company - those startups are selective as hell about who they hire).
You can and probably should negotiate that clause away. If an employer offers you an at-will contract, it should have a US salary written on it or at least a large sign-on bonus.
I've never had a job where there wasn't a probation period. It's one of my major gripes with the current hiring process. They can fire you at any point during the probation period, so why the hunger games during the hiring process itself? That's the whole point of probation periods: because sometimes they get it wrong.
My guess is because of the opportunity cost. If you hire the wrong person you end up firing 3 months later, you likely missed your chance to hire a better candidate (who is unlikely to apply again to work for you) and you will need to restart the whole expensive hiring process again (even a more lightweight process is expensive in employee time, maybe paying recruiters and job listing sites, etc).
Also onboarding is expensive: even an experienced developer who has all the skills you need still has to learn your codebase, processes, business logic etc. while drawing a salary, and all that goes to waste if they leave before they can start becoming a net positive to your company.
In the US I suspect "contract to hire" fills a similar function. I see that all the time but I don't think I've ever seen an official "probation period" on an employee role. (Could also be regional or industry dependent.)
The idea behind probation period is that it becomes much more difficult to fire someone after that due to labor laws. US doesn't have such laws, most states are at-will employment so you don't have to give any reason to fire someone.
Probation periods are seen in the US, despite "right to work" labor laws because A) the company is large and has employees in California, or another state where labor laws favor the employees a bit more or B) the company wants to minimize the chance of getting slapped with a wrongful termination lawsuit. Regardless of labor laws, it's universally illegal to discriminate/fire someone for their race, religion, gender, marital status, age, et. al. and I think companies, especially when they want to fire someone who might believe they are being discriminated against, want an airtight defense (usually a PIP). Even though the employer will probably win the legal case, they still would rather not have a lawsuit at all.
This works well. I’ve been in the industry about 20 years now and every job I’ve taken has had a short interviewing process followed by a probationary period, and then a full time offer is made after the probationary period.
I’ve only seen this approach fail once, and it wasn’t that big a deal, because very little time was sunk in to hiring the employee that had to be let go. At most a day or two was lost on-boarding.
Perhaps this is the right place to ask -- what would be the point of a probation period in the USA? All contracts I've seen here are at will and can be terminated for any reason or no reason. Now my experience is rather that most managers are uneasy about firing, but legally they are in the clear afaiu.
Probation in Germany goes both ways. Recently I worked there at a (small end of medium sized) company where work and pay was just so-so (nice, smart colleagues though). Then in a meeting the superior or my superior mentioned that there was some redundancy. Aha, I thought, I take that as a sign and promptly resigned some two weeks before the end of the probation period. They still expected me to come in 'til the last day, which I didn't mind too much, but still found a bit silly, since both parties agreed about the separation (also given the finite funds of that company).
It provides additional legal protection to the employer in the case they decide to terminate the employee during the first X days. Additionally, it serves as a "motivator" for new employees to be on their best behavior and to give it their all, at least for the first x days.
Laws that benefit the company, such as "right to work", mean that employers will often win lawsuits from former employees for things like wrongful termination suits, however companies would prefer to not be sued at all- even if they have a strong case. Court is expensive and a hassle.
That said, I did some moonlighting work for an employment law firm, and they say that they take less than 5% of the prospective clients who contact them, because they (and most law firms who only get paid if the client wins) want to be as sure as possible they will win the case. Of course if the prospective client were willing to pay up-front regardless of the case outcome, I'm sure most law firms would oblige. In such cases, I expect the former employers like to settle out of court to save time and money, even if the odds are good that they'd win in court.
This depends on where you are. What if the company is paying for the candidate's relocation? That can be quite expensive if it's international. And probationary terms might not be so easy to do in some countries.
If you have 10 promising candidates, and you'd like to hire one of the better ones among them -- then how are you going to accomplish that, with the strategy to "actually hire them"?
If among promising looking and speaking candidates, few are actually good, then what will the current employees think about people getting hired, fired, replaced a lot
Part of this is due to fraud from the last couple of years. I know multiple companies who dealt with remote employee fraud over the last 2 years. Companies are defensive now.
Personal favorite was refusal to turn on cameras while a different voice participated in each conversation, if at all. There was always a different reason why the camera couldn't be turned on too, while it clearly wasn't a problem during the interview. Tracked IP address access and it was hopping all over the world on a day to day basis.
Constantly acting confused after acing the interview. Never getting anything done and insisting on pairing with somebody else who just did the work for them.
Essentially the goal seemed to be to collect a paycheck for as long as possible until somebody noticed and you ended up fired. I heard variations of this from a few people and saw one first hand.
There were a few articles about people getting multiple remote jobs, doing the bare minimum to avoid getting fired for a while, eventually getting fired, and accruing large sums of money by doing that for years while presumably also holding a normal job in secret.
My employment agreement states that I agree to only hold one full-time job and that I agree to inform my employer if I decide to work another concurrently. This seems like pretty standard practice.
I think it's potentially more complicated than that. If an employer asks you if you have another job and you are working a second one, it is lying for you to say that you don't.
But what exclusive right does your employer have to your labor? That depends on your contract of course.
So if you signed away exclusive access to your labor, it's fraud. And that's not uncommon - there's often at least a "you will disclose other employment" clause in developer at-will contracts. That said, I think the only consequence of not disclosing is potentially getting fired with cause if you get found out. IANAL but I don't know of precedent for clawing back pay (which would be fitting for actual fraud).
If you didn't, then it's your employer trying to get more than they signed. And in that case, the lie is a necessary evil.
You know, when a working class dude busts his ass taking two, or even three jobs to improve his family's living standard, he's admired and they call him hard working. But when an office worker manages to slice up his day such that he can take two jobs (and do them up to performance expectations) they call it fraud. Not sure I understand this double standard. People get so hung up on this idea that full time should imply exclusive.
I think it's employers playing the game and optimizing.
Full-time employees are salaried. They cost the same no matter how much work they do. So full-time employers want them to do as much work as possible. They view time as zero-sum, so any hours you spend on another job are hours you could have spent on them. Even if - as we all know - there are diminishing returns on hours and those hours at job 2 would not produce the same output if pumped into job 1.
So, as always, full-time employers resort to soft power and psychological tricks to exert control over salaried employees. And I'd say it's increasing lately because remote work as shifted the power imbalance and employers are realizing the other side of at-will, salaried employment is that employees can work as little for them as they can get away with so long as they are good enough to remain willfully employed.
I saw a lot of that while doing phone screens: People who were getting coached via earbuds, people who were frantically searching Google for answers, etc.
The 100% virtual hiring process means that it is much easier to sub out your interview as there’s no point in the process where you show up for an on-site, present your government issued ID, and then interview.
I don’t remember ever showing my id in onsites. In some of those big places one could def skate by having someone else interview and then show up on first day and nobody would notice. Ime id doesn’t come up until hr wants work authorization on your first day
Yeah, I worked for a large employer who complained about this happening when people were onsite all day. Different people interviewed and showed up for work.
This is nothing new, it's just a media blitz by status quo lovers.
> By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
That's an interesting take I haven't heard emphasized before, but it seems plausible.
These stories make me glad I don’t go through the interview nonsense.
I’ve worked in software for 40 years, had exactly one of these ridiculous interviews. Despite years of relevant experience I bombed it because I couldn’t guess something stupid like how many tennis balls fit into Chicago. Recruiter told me they hired a more qualified candidate. Then two months later I got a desperate call asking me to start tomorrow. The person who aced the interview couldn’t actually do anything. I told them to stuff it, I had already found a better gig.
I have refused garbage personality tests by saying those violate the ADA. Think about what position that puts the company in. And I’ve had offers even after flatly refusing Myers-Brigg or similar nonsense.
This shit keeps happening because people put up with it and play along.
I interviewed for a company in London ten years ago (being from Sweden and flew in the day before.)
Interviewer: "How much water flows through the Thames?"
Me: "Well, I sat next to the Thames once, and it's maybe 50 m across. Depth... I dunno 10 meters? Speed..."
Interviewer: "Actually... It's 100 m across and..."
I could see the interviewer realizing this wasn't the most relevant question to ask to someone not from the area. Perhaps they wanted that interaction, I don't know. A silly question that just dealt with local knowledge, and (in the end) very little modeling.
I played along, then sat in my hotel room and shook my head.
However, one of my hard rules is that I don't spend more time on the hiring process than the company does. I'll happily sit and talk to an employee for four hours, but I'm not going to do a "take-home test" for more than 10 min.
Actually 100m across where? At London Bridge it's 265m wide. At the mouth it's 18 miles across. At the narrowest point it's only 18m across. At Oxford it's 46m, so you could say you only know the Thames from your time at Oxford.
What a stupid thing to ask in an interview. Answering that would prove... what? That you can multiply and make some wild guesses about a geographic detail you aren't familiar with?
I interviewed for a job in Sweden a long time ago (I'm a US citizen). The hiring team took me to dinner, and I got the impression my future at the company (or not) depended on my willingness to eat every kind of fermented fish offered at the restaurant. They didn't ask me how many liters of water Lake Mälaren holds.
> Answering that would prove... what? That you can multiply and make some wild guesses about a geographic detail you aren't familiar with?
Yeah, it was just weird. The interviews by the team in California were better, to be fair. (Though I still don't understand why they had to fly me there. The day after a 15 h flight across timezones, they spent 8 h giving me brain teaser questions. I was toast after that.)
> my willingness to eat every kind of fermented fish
Actually, not just where, but in which direction? Because during high tides the water can flow backwards up to the Thames Barrier in Greenwich, which they can close if it is too much.
And if you are from Sweden you can ask back: how many IT people does it take to eat a single can of surströmming? It is at least as relevant to doing the job well and to mix with locals, isn't it?
I once got asked how many first-grade pupils is there in a country I'm not from. I challenged the question and said that I have no way to know that since I'm not from the country and I doubt it's relevant to the position I'm being interviewed for. When pushed to answer I said "about 1% of population", the interviewer was not satisfied with my answer because I refused to elaborate why 1% and not more or less. On my way out I googled the fact to find out it in fact is 1% of the country's population.
The point of the question isn’t trivia or mathematics, it’s to demonstrate how you deal with ambiguity
At work you may be asked to spec out and implement a poorly-defined defined request.
They expected you to have asked clarifying questions rather than steaming ahead in the assumption that the Thames is 50m metres wide at all point.
The interviewer stating “actually it’s 100m” shows that they didn’t understand this point either though, and was probably repeating the answer they were told to give if the candidate asks this clarifying question
My view of the job market might be skewed, because I'm twenty-odd years into my career, and the people that are looking to hire me and often different than the people looking to hire a recent CS grad.
That being said, I wonder how much of this is just that people who have a bad interview experience are more likely to post about it than someone who has a "normal" experience.
Like you, I had one interview, when I was fairly new out of college, where they asked me how many golf balls it would take to fill a school bus. I've had a handful of interviews where I've been asked to do some live-coding; these were all less than two hours.
I've never been asked to go through six rounds of interviews, or do a take-home test, or tell them which color dragon my code is. Of course, I intentionally avoid FAANG, which is where I hear about a lot of this dumb-assery.
Same, I have avoided FAANG for a long time (I worked for Apple decades ago). At my age I don't have patience for nonsense. I freelance and work through an agency that vets clients for me, I never interview. Either I deliver or I don't charge for my time, simple. I stopped applying and using recruiters and going through the interview process a long time ago. I get jobs and gigs through contacts and reputation. That doesn't necessarily work for people starting their career, I understand, but if enough of us said no to these stupid interview processes maybe companies would stop using them.
Thanks for your perspective on this. I'm earlier in my career by a good bit, but not new to the whole gig by any means now (12 years in). 2 years ago I wanted to change it up and looked on the job market. Ended up applying to a large company that makes exercise equipment, and the first technical interview was outsourced to a completely unaffiliated party based out of Russia. They proceeded to ask the same garbage FAANG style algorithm questions, I just half-heartedly dismissed the interview partway through because why should I waste my time with these stupid questions if you're not going to give me the time to ask questions from someone who works at the company.
It's such a completely bizarre practice, and honestly insulting to a degree. I get that there's a huge influx of applicants at larger companies, however it's absurd to comply with this garbage structure where you can't even ask important questions to decide if you actually want to work there. I applied to a different job afterwards and once they told me they used that company as well, I refused to continue the interview process.
Worked out in my case, I ended up somewhere far better than either of those companies. I just can't bring myself to respect companies that treat prospective employees in this manner, it's crap.
I think I would just hang up on an outsourced interview like you describe. If the company can't take the time to talk to me that tells me a lot about how they treat their people.
Back when I had to interview for jobs I would try to turn the tables as early as possible. I would do my research on the company and their business. I would ask questions about the job, the company, the people. I would try to get the interviewer(s) to tell me about their job. People generally like to talk about themselves so I'd try to get them going on that. Of course you have to get in front of the right people -- an outsourced screening team probably can't even talk about the details of the job.
I get why companies do this. They want to screen out unqualified candidates early in the process, because big companies get lots of applicants. I don't think the way many companies go about this works. I've been in the position of hiring at places that get hundreds of applicants for a job, and there's no way we could interview all of them face-to-face. I don't think brain teasers or algorithm questions are useful, though. I used to prepare questions relevant to the job for screening and interviewing. And I would ask questions to determine if the applicant had done any research -- astonishing how many people get to an interview without knowing the first thing about the company or what kind of work they might do there.
This is a fair enough take from your position as (I expect) an experienced, seasoned developer who knows your own value. The power dynamic is tilted in your favor because there are way fewer people looking for work at your level, and if a company needs somebody with your skillset they're going to do what it takes to get you.
If you're a recent grand or early in your career, though, you just don't have that kind of clout. You're going to jump through these hoops because you need the job, and you're going to be competing with people in a similar position doing the same.
Yes I understand that people earlier in their career don't have the clout of long experience. They also don't usually have a solid professional network, which can help tremendously because personal referrals are much better than blind applications.
Developers trying to get a break early in their career should remember that companies want to hire people they perceive as adding value and fitting in to their team and organization. Lots of people can crank out code. Just knowing a programming language or framework is not a competitive advantage in the job market. You need to communicate good people and team skills, and either domain expertise or curiosity about the business domain. I've interviewed too many inexperienced programmers who have focused solely on technical skills that, while hard for them to acquire, don't actually stand out much in the field of candidates. Some time learning to speak to a group without anxiety (Toastmasters, for example) can have more value than learning how to traverse a tree in Python.
Early in my own career companies commonly hired people with little experience, fresh out of school or eager self-taught programmers, and then trained and mentored them. Companies had to do that because of short supply, and because every computer system was proprietary and unique. Now companies won't put any effort into growing someone into a career, they want interchangeable people they can slot into a job and get work out of right away. To differentiate yourself in those conditions you need contacts and reputation, or you need to come across as someone who can add value and commit to the organization. A good recruiter (admittedly not easy to find) can help a lot because good recruiters have contacts inside companies and can coach the candidate and maybe get around some internal roadblocks.
I have some articles about job hunting and interviewing, more tilted to freelancing but possibly valuable for f/t job hunters, on my site typicalprogrammer.com. Opinionated, free, no ads, signups, popups, or affiliate links.
You don't have to discuss any disability. I leave that to the interviewer's imagination. The point is to let them know they are already on thin ice. They would have to show how they administer their tests fairly, how those tests have some scientific basis and predictive value, are necessary for the job, and don't discriminate against protected groups. Of course they can't show those things so they have always just dropped the issue. I've had recruiters try to haul out their personality tests too, just say no.
Companies fear one thing even more than making a bad hire, and that's getting sued for their shoddy interviewing/HR practices. A complaint can trigger investigations and lawsuits from the state, not from the candidate. The ADA is sufficiently vague and comprehensive at the same time that it's a bogey-man for HR people.
To put it another way, a US employer has to comply with the ADA whether I have a disability or not. And they can't ask me what disabilities I might have unless directly relevant to the job, i.e. a person in a wheelchair probably can't operate a fork lift.
Some US states already prohibit pre-employment background checks and credit checks. States should prohibit employers from casting nativities and reading entrails during the interview process as well.
When asked my Myers-Briggs "Type Indicator" I always say "Scorpio." Weird how so many rational and educated people fall for that bullshit. And yes, that's exactly how a Scorpio would behave.
The hiring process has been like this for a long time.
I had a hiatus from work in 2016 and when I tried to get back to the job market it was impossible to find anything, even when I was over qualified for many of the positions I applied to and was even willing to take a considerable pay cut just because I was switching business domains (although the stack and many of the required soft skills to do the job remain the same)
The vast majority of the interviewers I faced had no idea what they were doing or trying to measure.
Loop interviews were the worst because it generally takes just one guy out out five to dislike you even if you had a great time with the other four.
I mean I bet most of these guys in loop interviews would not even hire themselves
It became so dreadful and time consuming that I had to tell recruiters right away I would not be doing any whiteboarding or solving puzzles. Pair programming and short take home projects were fine.
That helped filtering companies but my leads dropped by 90%.
I can relate to the hiatus situation and "one dislike".
I'm employed right now, for about 1 and half years, but there was a time that I tried to switch path from Web/Mobile developer to full backend developer, and in this attempt I got a job interview for a digital bank; I had everything checked out and expected to continue to step 2, even a friend of mine who works there thought I'd pass the process easily, but to our surprise, I didn't make it to the next step, and when I asked the interviewer for feedback they gave me a bullet list with just one bullet saying that I didn't "explore business logic much"! It didn't make any sense! I found it preposterous and insulting, to say the least.
When I ask for feedback, I want to know what are you looking for and why I wasn't compatible with your position.
It's more or less impossible to review non-trivial code without feedback from the author (i.e. have a conversation) outside of cases where it's just truly obviously awful. Often stuff just gets rejected for "I wouldn't have written it like this". Okay, fine; but that doesn't mean I can't write it like that. But if I don't know what you want...
The reason people don't give concrete feedback is because there often just isn't a clear one beyond "I don't like it".
Software Development and related careers are the only ones where grown up adults with years of experience in their fields are still treated like college students in the interview process.
It doesn't matter if you wrote a library 15 years ago still being used today by hundreds of thousands of developers around the world some even working for the company interviewing you.
Were you responsible for designing and building QA systems used by Boeing and NASA? That's cool, now please write a bubble sort algorithm on a whiteboard and then guess how many cars there are in the US (explain your thought process).
Imagine how ridiculous and insulting it would be for a seasoned lawyer, a doctor or a CPA, to endure this nonsensical, pointless scrutiny when interviewing for a job.
But somehow in tech this is not only common but accepted by job seekers as normal.
I think you actually explain why these interviews are structured this way. Tech is pretty ageist and obsessed with youth, and in fact stodgy aerospace like Boeing and NASA are kind of held in contempt and derided for making peanuts.
These interviews are a good way to filter (and even discourage) older applicants, since the cultural fit for the task IS someone recently in college.
> Imagine how ridiculous and insulting it would be for a seasoned lawyer, a doctor or a CPA, to endure this nonsensical, pointless scrutiny when interviewing for a job.
Good examples, because lawyers, doctors, and CPAs all have formal exams and licensures, and a board that certifies that you have the qualifications to do your job. So when a hospital interviews a doctor, they don't have to go over first year anatomy to understand whether the doctor knows where the appendix is. The process certifies a base standard of knowledge.
Software engineers don't have this, and every time it's brought up in conversation, it gets poo-poo'ed. So, 1. Companies have no idea if you know how to even turn on a computer, and 2. Candidates have to start from scratch every time explaining what a linked list is.
Wouldn't it be great, both from an employer's POV and from the candidate's POV, if you could show that you passed the exam and received your license from the Coding Board, therefore you have some very basic set of skills? Then, you could both skip the fizzbuzz part of the interview and interview about more domain-specific questions. It would cut the interview time by probably 50-75%. But for reasons, HN commenters hate this idea, it's imposing "gatekeeping" and infringing on their freedom to pick up a Raspberry Pi and call themselves an engineer. So..... we all have to live with these incredibly inefficient and capricious hiring processes.
> Wouldn't it be great, both from an employer's POV and from the candidate's POV, if you could show that you passed the exam and received your license from the Coding Board, therefore you have some very basic set of skills?
There are some certification authorities in the US, but as far as I'm aware, the top programs haven't even bothered with it (MIT, Stanford, CMU...).
The main issue is that all CS degrees aren't created equal. Someone can graduate without much programming at certain schools (where the degree is way more math focused). That's completely fine in itself, it's ok to have an option to focus on theoretical math, but it's not necessarily what employers are looking for.
Abroad, like in France and Switzerland, they seem to have some certification body that checks the course curricula and determines if it passes the bar to be called engineering. Perhaps not the best example as these two countries are smaller and, at least for France, way more centralized than the US.
To be completely honest, I fast track interviews for new grads of certain institutions because I'm familiar with their programs and I know what they studied.
> The process certifies a base standard of knowledge.
It'd be great to have CS and software engineering board tests that can be taken once and then do away with all the interview nonsense like other professional fields.
There's just too many devs chasing too few jobs imo, programmers have become somewhat of a commodity and it's going to get much worse now with interest rates higher and staying higher. And soon A.I might eliminate humans from the equation even further.
At the same time there are professions like child care, education, healthcare where personnel is always needed and overworked. To me it looks like we need to reorganize the job market but we'll see what the higher ups come up with - maybe they prefer to let "market forces" do their thing.
> There's just too many devs chasing too few jobs imo, programmers have become somewhat of a commodity and it's going to get much worse now with interest rates higher and staying higher.
Programmers, sure. Engineers? Everyone seems to be fighting to hire them.
Writing code from a detailed spec is the easy part. Back in the days, people were doing it directly in assembly before someone came up with a compiler. When the great offshoring craze started, suddenly everyone was now an "architect" writing these specs and submitting them to an "AI" (called a programmer in India) to be translated into (sometimes working!) code.
So the coding part was cheap and easy, but getting the detailed spec hasn't gotten any easier than it was. And the industry learned (mostly thanks to FAANG) that the best people to write these specs were also capable of coding them faster than by splitting teams in two and having the actual programming be done elsewhere.
> At the same time there are professions like child care, education, healthcare where personnel is always needed and overworked.
Then maybe they should make these jobs more like engineering. Where's the Google of child care?
Seriously, one of the big caveat of education and child care is that comp is on a pay scale, voted by the public, and you get paid for years of services and not results. So the teacher that can't get fired because of union rules, that keeps getting complains after complains and doesn't care will get more money than you and will get first pick for any assignments.
Thanks to over-regulation, healthcare is by far the most dysfunctional field of work in the western hemisphere. Turf wars between professions, bloated administrations and out of control spending is the norm. Most of the overwork is due to completely dysfunctional management.
> Who are all the people companies like Meta, Alphabet, Amazon are firing?
A lot of them were in "tech-adjacent" positions. PM, tech recruiters or evangelists, community managers, DEI folks... At one point one layoff announcement had "returning to a healthy ratio of engineers to non-engineers" as a goal.
> Loop interviews were the worst because it generally takes just one guy out out five to dislike you even if you had a great time with the other four.
Steve Yegge famously described Google's "interview anti-loop" where you got two interviewers in the pipeline that wouldn't have hired each other, so whatever pleases one interviewer would get you rejected by the other (and viceversa). In those cases there's no way to win. I suppose the length of the interview process increases the chance you'll hit this anti-loop.
No doubt, the number of interviewing antipatterns out there is nuts. Leetcode games, hiring by committee, and a market flooded with candidates with resumes that look and read the same.
On the flip side, I’m interviewing candidates with a decade of experience (per their resume) that can’t discern the difference between basic data types and how they are stored with the very language they claim expertise.
Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well.
If you’re skilled, don’t despair. Most companies are terrible at hiring and terrible at business as well. Those rejections from the gauntlet of flaming hoops they make your jump through are doing you a favor.
Rejection is God’s protection and all that. And I like to think that’s right.
There are developers great at solving business problems, which is what the vast majority of companies actually want.
And there are developers who say things like "[other programmers] can’t discern the difference between basic data types and how they are stored with the very language they claim expertise"
That's not the actual job we do. Unless you happen to write libraries or crazy high performance code.
Most of the time it doesn't actually matter how the data is stored in the language, it actually matters how it's stored in the DB. Because that's where the performance problems are.
Most of us don't even have to remember that, even if we ever learnt it. It simply doesn't matter.
Most of our jobs are to turn business requirements into working programs. That makes us an expert, not knowing a language spec verbatim. That doesn't matter at all. It's a meaningless metric.
It reminds me of a colleague who could tell you all the performance problems of += vs StringBuilder but shipped sweet FA for 6 months. And do you know what the difference actually is? Nanoseconds. NANO.
Or the person who seemed to be able to quote the entire SQL manual, yet typed with one finger and spent 3 months building a 10 line SQL statement.
Or the colleague who could give you text book definitions of every design pattern you can imagine, but when asked why they'd implemented a complicated mediator pattern for saving simple forms couldn't explain, "that's how it's done!".
And when I ripped out the several thousand line monstrosity and rewrote it in 100 lines or so, they still admantantly said it was better even when presented with load tests that showed the new code was orders of magnitude faster.
What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two. Sometimes they intersect. Sometimes they don't.
> There are developers great at solving business problems, which is what the vast majority of companies actually want.
Many developers find themselves in a position of being a subject matter expert in a particular business or industry, and that becomes the primary value they deliver. They remember where that error message originates or why that column in the database is named so strangely. They know the lingo and business quirks inherent to their industry.
Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly. Their programming muscles atrophy while their subject matter expertise grows. But that knowledge doesn't always transfer well.
I've fallen prey to this trap (personally) on more than one occasion, getting lost in what I was doing instead of seeking to better understand what I do.
> What are you recruiting? Language experts, or coding experts? As you seem to be confusing the two.
I'm recruiting problem solvers, and I think it's necessary to understand the tools you are using to solve problems at least one level deeper than autocomplete shows.
Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort. When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags.
Sure, tools and language (e.g. Javascript) often abstracts much of the details away, but my experience is that those developers with a familiarity of those details and why they matter (even if they might need an occasional reminder from a search engine) are a cut above.
> When I ask a candidate to convert an input string of digits to its output integer (e.g. "001234500" to 1234500) equivalent and they don't seem to discern that's an important distinction, it raises red flags.
Why do you feel this is important? To clarify, what are you testing here?
It’s important because "001234500" and "01234500" are two strings that don’t compare equal (and that sort in a specific way), but after conversion to an integer they do compare equal. When you use such a value as an ID, for example, the type you use makes an important difference here.
It shows that you understand how equality relates to values and data types, and that changing the type of something can make the same conceptual operation behave differently. This is the kind of fundamental technical understanding and precise thinking you want a developer to be absolutely familiar with.
Actually, in the old days a string number with a leading 0 in javascript got parsed as an octal. You used to have to do parseInt('0012345', 10) to get it to parse properly.
Faced a similar issue in Java. Someone decided it was a good idea to convert string postal codes to int. For sorting... Using Integer.decode()... Everything was ok until a "09677" show up.
> Over time they lean more and more on that knowledge and the extent of their software development is mostly spotting patterns in the existing codebase and regurgitating those patterns repeatedly.
That's what the majority of all the industries on the planet are doing. Repeating the correct patterns in the right place and right time. The value is knowing the right patterns and repeating them at the right time and place.
And it makes sense - how many different ways are there to iterate and manipulate a given set of data that contains customer/user records, orders, social post meta or whatever is commonly used in modern tech? Aside from very specialized organizations that are working on the cutting edge of the tech in this or that specific sub-specialization, most of what we are doing is juggling data in the same way everyone does. The chances of anybody bringing a totally new way to juggle that data through exemplary and precise knowledge of the language are ultra slim. And if that ever happens, everyone would soon know and start using that method anyway. Which brings us to the point below:
> I'm recruiting problem solvers, and I think it's necessary to understand the tools
The problem solvers would know that we are living in 2023, and not only the abstractions that we use, but also the stacks and languages that we use have evolved to handle as much as they can to make our work easier, including data types and their manipulation. The memory space inside a developer's mind that is allocated to knowing those data types and manipulating them manually is memory space that is wasted and not being used for remembering other things and increasing his or her impact.
If your logic held out, we would still be manually allocating memory in our programs. We dont. Those who need to know allocating memory on a daily basis and needing to not letting that knowledge atrophy are those who work on hardware, low level hardware-softare interfaces, those who build and maintaing languages, packages, or stacks for industry-wide use. Not the developer who solves !business! problems.
> Frankly, I think developers are getting good at combining Google search results into a codebase that reads more like a ransom note of copied-and-pasted snippets than a deliberate engineering effort
Yes. And that's what enables them to take on the ownership of increasingly broader features and systems. In the same way it enables even fewer founders to bootstrap or launch more complex startups. Everything we do in tech is for automating, optimizing and making easier a given level of problems to be able to rely on that automation to move on to the next level.
> Sure, tools and language (e.g. Javascript) often abstracts much of the details away
Yes. They do. Every stack, language, framework does. That's what amplifies productivity. Not holding on to knowledge you will rarely ever use.
...
The difficulty of modern tech is in creating reliable, user-friendly and cheap systems that bring advanced technology to the masses. Anything that prioritizes specialized knowledge on what is already handled by the existing technology stack is more academic than anything practically engineering related. Such approaches could exist inside gigantic old-school organizations like IBM when they had their heyday, and they did exist inside tech gians which literally made themselves a continuation of the colleges which their founders graduated from, fueled and floated by zero-interest investor money, prioritizing only 'growth' without paying attention to the business fundamentals. But in the new, non-zero-interest economy, they can hardly be justified.
> The value is knowing the right patterns and repeating them at the right time and place.
And that discernment, at least in part, comes from understanding what that code is really doing.
I get 45 minutes face-to-face to develop an opinion as to whether or not a candidate can do the job well. I value candidates who’ve not only asked “what?” but have also asked “why?”
I’ve no doubt my approach has filtered out people who would have done good work. I’ve certainly passed people through that didn’t work out for various reasons. But generally, my approach has served me well so far.
> comes from understanding what that code is really doing
It does come from understanding the !business code! that is involved. Not the rarely important features of the underlying language that the stack, the framework or the models handle.
Which makes that argument further moot - you should not be messing with how the models or the framework handle those data types. There is a reason why they were built and deployed.
I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews, and I’ve always wondered if they really don’t know these things, or if it’s just the environment- like in my experience I can wax and wax and wax in a non-interview setting, but in an interview setting, even from the comfort of my home office, I seem to block out- not forget, because in the moment I know I know something- parts of my knowledge. You might say “well you should practice interview more” or something to that effect, but I have to wonder, if so many developers seem to “know nothing” despite their supposed experience, perhaps it’s not that they “know nothing”.
On my LinkedIn I have the following: what I currently get paid by my current employer (!!!), what I am looking for in my next role, both regularly ignored by recruiters of course, and then I have links to my StackOverflow, Medium and Github profiles, any of which ought to demonstrate my “expertise” as well or better than an interview ever could. Heck if you just read some of my answers to StackOverflow questions, I think you’d see I am capable of writing code for your company…
Most people aren't this consistent. At work does someone say that I will watch you code in a particular time of the day and you will be able to perform on a random question that's useless?
No.
Interviews have 0 context that's needed for anyone to perform. Usually you can't use your IDE, your settings or your ways of working and you've never paired up with the interviewer so might not feel comfortable.
To make matters worse the interview topic is 90% chance not what you do on a day-to-day basis. No 1 is answering leet code questions at work. We're going to be using a library or tool and not to try write an analytics algorithm.
Another harsh reality is that for most jobs, the initial interview is by far the hardest part of the job. Once you pass it, the rest is cake. It takes a lot less effort and brainpower to keep a job than it does to get it.
I still look back to a FAANG interview a decade ago being the most difficult thing I've ever done in my life, and I've worked my way up from a shit mining town to the middle class, developed a complete complex software product starting from an empty text file, gotten an advanced degree, built a single engine airplane, and managed to stay married for 20 years. But out of all that, a stupid FAANG interview was the most difficult. It's just ridiculous what companies put people through.
I've bombed interviews numerous times only for the answers to come to me when the interview is over. My best outcomes are when I am relaxed (already have a job ;)) and I've gone through some basic material and whipped up some example programs.
I've never had a problem in a real world setting or writing code.
Its just so different talking while being judged by people you dont know, throws things off. I bombed a few last time, one in particular where I was writing a switch statement. They wanted me to use a map. They asked what if the cases kept growing and... it didnt occur to me to use a map.
Im sure i looked like a novice. But in my day to day code... i flip between maps and conditionals and switch statements all the time, with ease. Its natural. But while interviewing? It just doesn't come out of me.
It’s weird because at the end of the day, it shouldn’t matter. I’m about to interview for a job two states away. If I fail, well I fail. The worst outcome is status quo, but I’m still terrified of looking like an idiot tomorrow.
> I’ve always been fascinated with the idea that someone can be a software developer for 5, 10, 20 years and bomb in interviews
i cant remember who said it but many people with 10 years experience really have 1 year of experience and 9 years performing tasks doing the same thing over and over.
First of all, software frameworks and technology evolve. Second, it's pretty hard to find someone who worked for 10 years at the same company with the same software project doing CRUD actions.
On the other side, if you meet linux kernel engineer who maintained kernel for the past 10 yers, this argument fails short. Same for someone who worked on Postgres internals.
> and 9 years performing tasks doing the same thing over and over.
I mean that's what experience is.
If I want an expert in x, I want someone who has being doing x for ten years. I don't want someone who has dabbled in ten different things in ten years, thus having very superficial exposure to ten things and expertise in nothing.
If I need a heart surgeon, I want the doctor who has been doing only heart surgeries for a couple decades. That's an expert. I certainly don't want some doctor who has been switching from heart surgery to podiatry to dentistry and on and on without specializing in anything.
> Once upon a time the stereotype was that hiring developers is hard because they can’t communicate. Now candidate after candidate is able to communicate like they are a professional podcaster but they can’t seem to solve problems well.
LOL I've noticed this too! Somebody must be out there teaching people to do this! I mean I interview people, and they are so over-prepared with their sound bites and their canned speeches, and they deftly try to steer all conversations back to topics they are prepared with. Their style, body language and communication tactics are polished and sophisticated. They sound very pleasing. Their slick enunciation, cadence, and confidence make them sound like 20 year NPR veterans. But the content itself is a millimeter deep. It probably fools the exec class, but it doesn't fool a practicing engineer or technical manager in the trenches.
In regards to experience, I’ve noticed this too. I took over the lead position at a company with multiple senior engineers that wouldn’t pass a junior interview with me. No intuition for time complexity and not a care in the world to reuse functions etc (every task was a from scratch build out of mostly duplicate code) etc. the worst was a guy who claimed 15 years experience
I'm not a dev anymore, but even when I was decent to good with multiple languages over the years, I would not have known this.
I do remember being in interviews where one smart person on the other side of the table asked me some piece of tech that was mostly specific to their daily use, and when I didn't know it, they were shocked -- shocked, I tell you.
I can't pair program, especially not in an interview setting. Being watched makes me so nervous that I can't think straight, unless it's someone I know well. I also can't think and talk at the same time, and someone talking to me makes me lose my entire train of thought. I don't think I'm the only one.
You're not the only one. I will say that comfort often comes with practice.
I do pair programming sessions with people as part of my job. This has made me a substantially better at pair programming as part of interviewing (on both sides). Perhaps it would be worthwhile for you to time to work with some colleagues to build some of these muscles.
I do agree that alternatives should be offered if someone is uncomfortable.
I don't think it's the same at all, because people aren't watching every character you type, including the mistakes.
My mother told me I spoke very little as a child, but in the evening she could hear me practising words outside my bedroom door. I suppose this is some deeply seated neuroticism.
Then you are not gonna do well in any interview or team setting; which basically disqualifies you from working in this field unless it’s open source or something.
Pair programming is quite rare in most orgs. Most code is discussed async after its been written. A take home test where you modify some existing code based on new business requirements would be far more similar to the real job. LIVE Discussion about the requirements before or code after would also be similar.
Interviewers all seem to state the problem and then let me work quietly between a few clarifying questions. My impression of pairing is a lot more talking with no time to start thinking.
What on earth are you talking about? I’ve been in the industry a really long time and have never seen anyone actually pair program. The entire concept of pair programming is silly. If anything it’s ear phones on and don’t bug me.
This is very close to what our company does, and I think it's a great process. We like to give a two part problem - something relatively simple like an "early-December" Advent of Code problem. We give the first portion as a take-home project, then do a pairing style interview, where we spend a little bit of time discussing the solution, and then pair on the second part.
We see how the candidate approaches problems from their initial solution, and then we get to see how they react to being asked to extend things. We get to talk to them about how easy their code is to change, how their tests helped support the changes. We get to see them work through a problem under slight pressure, and hear them communicate with a partner about the problem.
* We keep the problem easy like the one above because we're not trying to see if a person is a genius or has memorized a lot of algorithms. We just want to get a basic pulse on their skill level. For a junior dev, this kind of problem is doable but might take a little while. For a senior, this should be basically trivial.
* When I mention that a candidate is under some pressure, I don't mean that we add any artificial pressure - that would be dickish. I just mean that interviews are naturally a bit of a high-pressure situation, so we get to see if they keep their cool, etc.
* The candidate drives, but we try to approach the problem as a real pairing situation, so the candidate should talk through ideas with the interviewers, the interviewers can and should _actually help_ solve the problem, etc.
* The "take-home" portion is designed with the intent of not taking up more than an hour or so of the candidate's time, and is really there just to give us a starting point to talk about. It also ensures that the candidate has a project set up and ready to go for the interview in the language of their choice, which eliminates a lot of churn from the beginning of the interview.
I helped design the process so I'm biased, but I think it's extremely effective.
I would hate that and do terrible myself. I need to focus to do my best and having another person around to interact with would be a huge distraction. Plus in 25 years of working on software I've never produced anything of value working that way.
Hell no. If I could possibly smell whether you had a shower this morning, you are too close. I'm not going to share a keyboard, terminals are cheap and have been for a long time.
This is a cultural thing. Don't expect me to become a new person to fit into your work flow.
Now I know that buddies of mine did great work like that as teenagers creating games (and some sold reasonably well), so yes this can work beautifully. Thing is just, you're not my buddy and I'm no teenager any more.
I participated in a paired programming interview once. I didn't get the job, but I walked away with respect for the organization doing it.
It gave them a chance to see how I worked as part of a team. Even if day to day I'm not pair programming, it starts off the relationship saying "If you need help on a problem, you can be comfortable working with your teammates."
The great thing about the setup is that it doesn't have to be a unique or complex problem. "Write a function to reverse a string. We'll write unit tests in parallel with that."
Or one of the thousand other problems. You're not testing algorithms here, you're testing whether the candidate is arrogant. Or talks too much. Or doesn't ask for help. What happens when they get stuck?
You're right, it's a lot of effort. But the resources spent on a bad hire can be even more expensive.
Have been hiring designers and developers for nearly 15 years. The easiest way around this is to just make a website that shows your work. Put up a small project on Github (even if it's a small hobby). A resume tells me nearly nothing and the logos on it only get you past the recruiter. It is absolutely mind boggling to me that people looking for Internet-related jobs do not own the story of their own career on a website of their making.
If I need to have a conversation with you to figure out if you know what you're doing, I'm wasting your and my time. I'd rather have a conversation about whether you're a good fit.
I've experienced the exact same thing. People would go, "After seeing your resume and noticing you made X software by yourself, I immediately installed it and it worked great. I just wanted to say thanks!"
Proceeds to ask me to solve random leetcode questions anyway.
What would you expect if it the person interviewing was a mobile developer, or backend developer? What should they put on the website? A mobile developer perhaps some screenshots of app screens? What about backend logic?
I'll give my two cents as someone who's in the same position.
I look for code style, commit messages (both proxies of quality of work), following standards, good code orga and tests. Show me that you understand why clean code is important basically
I suppose a backend engineer could produce screenshots of parts of the front-end that they helped enable, charts that visualize any improvements to metrics they made, and maybe systems diagrams to show services they built or maintained. Each one would need some accompanying text to give context
This is what has landed me 3 of my 4 programming jobs.
1. Having a web portfolio which has system designs, images, or gif videos of my apps, and points to my github code which interviewers can view.
2. Then walking interviewers through a project during the interview.
Whereas 3 months ago, I had a call w/ a "Director" of Engineering for a small startup (5-10 engineers, about 10-20 other staff). He wanted me to do a take home project. "it's just a 2 hour project: a CLI tool to lookup data via REST API, based on arguments passed in. And expose a gRPC endpoint, writte in Go or your favorite language, but we want to see it ready for production with tests". Everything except the REST API part was new to me: a CLI framework, gRPC, protobuf typing stuff.
Three hours in, I realized I crossed my self-imposed timebox and that the project would really take about 8 hours (or perhaps 16 if I wanted to polish it and have a higher rate of getting hired). However, I was on my vacation and the purpose was to spend time away from technology.
The place I'm currently at is hiring a principle engineer. I've performed a few tech interviews so far. We just started the process less than a month ago.
We have (2) interviews. The first is more of a soft skill analysis (casual conversation) that the engineering manager does and the second is a tech interview. Each are 1 hour long and are usually scheduled on different days. There's no algorithms, whiteboarding, puzzles, take home tests or desktop sharing. We just video chat about a range of tech topics for an hour and ~20% of the time is left to ask us questions.
In the past I've mentioned that if I were ever in a position to hire someone I think it's possible to accurately identify someone's skill sets with a casual conversation and I still believe that[0]. No matter how good of a speaker you are you can't BS your way through certain kinds of practical tech questions. You either know them and can explain them in detail or you can't. There's a million little things to pick up on through out the conversation which weigh in on being a hire or not-hire in the end.
[0]: There's exception of course, my specific case applies to fairly standard web apps (something comparable to GitHub or Shopify in scope). Exceptions would be hardcore low level programming.
This is similar to what I do and IMO it works. 90% of a good developer can be found in their desire to learn / desire to problem solve as long. You can get most of what you need from an interview just by getting somebody talking enough to geek out on you.
Not only for developers. My current "favorite", which I hope is never surpassed, was a 3+ months long process involving nearly a dozen different interviews, essays, tests, an interview with the CEO who actually approved hiring me, a direct statement that I was the only person who had made it through all of that and that it was probably impossible to find someone better suited for the specific role, and, then, nope.
Developer hiring is exceptionally awful for lots of reasons, but there are wider problems now.
Nobody gets a CS degree dreaming of working for Walmart, but they have 1315 openings with the word “software” in the title. Many jobs are in CA, TX or WA
My brother has been a software engineer since 1996. After working exclusively at mid-to-large tech companies, he started working at a very large national retailer in 2019, mostly because he wanted to move closer to family and that was one of the few good employers around.
He now says that this has been the most fulfilling job he's had. This retailer was working on ancient systems that, while old, were exceptionally well-designed. Moving these systems over to a modern tech stack was challenging but also incredibly rewarding.
I work in finance and a lot of my job is getting the right numbers to come out of the system in the desired timeframe. To my son that sounds boring, and he asked me if I'd switch to work on VR or something flashier. I told him that there's a lot of challenge in solving the problems that I do, and I wasn't sure that optimizing rendering or something in VR would be more rewarding or not (not to mention I'd have probably been laid off by now anyway). I suspect the challenge and reward is the same but using different tech stacks.
Working for a non-tech company can feel different though, because they are less developer-centric. Especially in the early days I remember many weird conversions I never had before: why do you need this weird software on your computer, or even admin rights? Do you really need that expensive computer/phone/monitor for your development, it's not the company standard? Why do you need to access non-standard ports via VPN?
On the other hand, I really enjoy working on things that benefit non-tech users and solve "real-world" problems.
Walmart, CVS, and Target are not sexy at all (on the tech side). But they're stable, pay well, and you get to work on interesting technical problems that actually matter. You are more likely to deal with an interesting issue at WCT then at a FAANG, there's less red tape to deal with, and everything is just better designed in general since it needs to be reliable.
If you're still there after a year you'll probably spend your career there.
Not too long ago I was approached by a recruiter from Walmart for a role that was deeply technical in areas that I never would have imagined Walmart to be hiring for. So they seem to have some great teams doing interesting tech work.
Unfortunately they wanted on-site presence in a different state than where I live so couldn't go forward with it. Otherwise might well have taken it, to my surprise.
My last interview was with some large US corporation. I had scheduled the first interview with their tech lead in one of the departments. Interview started on time, we managed to say hello to each other, then something bizarre happened.
I think the tech lead thought he has lost the connection, but I could see him and hear him clearly. Suddenly he started shouting, swearing and then he violently swept things off his desk and that's when the interview was cut off.
I got a call an hour later that they have "technical issues" and the interview will be rescheduled.
Three days later I got an email that I didn't pass the interview that I didn't really have in the first place.
That was quite funny actually.
I think we should start hiring in the US :D that's horrible. We do 30 mins of chit chat (general fit) and then meet the team + quick deep-dive on tech without flip charts or any tests (the German market doesn't work like that). And that's it. The second meeting on site including pizza with the team.
German (and most other non-US) companies offer much lower compensations for devs than US companies. This is an aspect that I find most often overlooked in the complaints about tough US dev interviews. The compensation for US devs is extremely high, both compared to other US jobs, and to non-US dev jobs. The FAANG get literally millions of applications per year, so the interviews must be setup to fail the vast majority of applicants.
Might be, sure. But we have social security, lower costs of living and stuff like that. We need to compare real compensation plus other soft factors like happiness, feeling of security etc. Also talking about the top 1% is not that interesting, because most companies behaving like they are FAANG just aren't FAANG ;)
/edit: but I agree that wages need to increase in Europe overall for developers!
Yeah, the whole reason these practices even exist in the US is purely due to compensation.
If the compensation was lower - no one would bother. This is why you see companies that do these practices but don't pay FAANG wages having a much harder time hiring - while FAANG never has any problems hiring ever.
I work for a german scaleup and I had a full day interview. It was not a horrible leet code stuff but it was definitely a time killer. Can you share the name of your company or a way to contact you?
You can chitchat and learn someone's skills. It takes practice, but it's the same skill set for solving problems. Ask what they did, what problems they encountered, and dig in three levels on the interesting topics.
I would prefer to see actual code you've written, GitHub or something. I don't care about fantasy logic tests on a whiteboard, I feel they are non-predictive. I also always talk about values (clean code, writing tests etc.) and you get a feel about aligned values. And most importantly, in a small company the team fit is the biggest thing of all.
" I've been in the market for a couple of months, and I have no idea what employers are looking for"
IMO that's because they (employers) too have no idea what they are looking for. It's a mess and only getting worse.
My 2 cents is just say yes to that rare proposal that comes after one or 2 interviews. And yes, they do exist but almost everyone passes them because "if it was so easy the role must suck". Well, the possibility of role sucking is exactly the same if you went through 10 hoops to get the job.
I’ve been doing this for a long time now, and I’ve had good results from companies with humane interview practices.
Places that treat candidates poorly tend to treat employees badly, and companies that drag out the interview process tend to miss out on in-demand talent.
As a result, places that respect your time and well-being have been more likely to have good engineers who have stuck around. Places that are toxic and/or bureaucratic tend to combine bad hiring with high turnover and create a terrible environment.
My current company has the most humane interview process I have ever experienced. When I started I was shocked by how many good engineers had stuck around for 5+ years, a few for more than 10. That's crazy for a non-FAANG non-legacy software company. It turned out to be a great sign that the company respects one's time and well-being!
Part of OPs problem may be that it's hard to differentiate yourself in that kind of position. Full stack web development is not easy to get right, but the competition pool is huge. It helps to find even the smallest little angle to differentiate yourself.
The personality tests can fuck right off, though. Agree with that.
I once aced an interview before and been told they'd make an offer after this one little Big Five personality test, I think it was called. Fail with no feedback. That's not constructive or actionable. Is that test any better than phrenology or palmistry in practice?
Probably the big 5 personality matrix/dimensions. It's based on statistics to cluster personality questions and answers that tend to cluster together. The acronym most used to remember those dimensions is OCEAN.
Openness - how easily you are willing to accept new ideas
Conscientiousness - how careful and how hard working you are
Extraversion - how quickly you are to engage with the outside world
Agreeableness - how quickly you are to agree versus disagree
Most people aren't a point on the spectrums, they have a range. For example a lawyer might be very disagreeable at work when talking with opposing counsel, but very agreeable when dealing with their children.
In fact stability is the strength of Big5. People's personalities seem to be stable over their lifetime. See the 3rd paragraph [0].
The weakness of Big5 is it may/probably does not capture everything. It seems to completely miss abnormal personality traits. Which in a job interview... I hope has been ruled out with initial screening.
Most people, without practice, are not a range as wide as "very disagreeable" to "very agreeable", most people are flexible around a point, to a lesser extent if they've never paid attention to how they behave and never tried to directly practice behaving differently.
Sure, though I certainly see pretty wide variances in myself based on my environment. If I’m happy and in a good environment then I tend to be very agreeable. As my stress and unhappiness go up, I tend to get pretty disagreeable.
I had one job that was absolutely awful, and to be brutally honest my attitude sucked. I wasn’t as nice to my coworkers as I wish I had been. I wasn’t a complete asshole or anything, and my behavior was never raised with me as being problematic, but I’m not proud of how I acted through that time.
But over the course of a fairly long career I’ve gotten a lot of comments about how laid back and friendly I am, and how I tend to go out of my way help people. I like to think that’s who I really am, but I can definitely be unpleasant if I’m miserable.
First, the trait examined is a range and is also situational. Second, your self knowledge of your ranges and situations is also variable and introduces more error. Third, the test introduces more error, it seems. Nobody on this thread has given any evidence this is a useful hiring tool.
My impression is hiring is difficult and there's no shortage of companies pretending to solve it with science, but it's not solved and it's not science.
This test addresses some of those problems by not only posing the personality questions to just the person you're trying to study the personality of but also friends and co-workers that know them. You can capture that range there. If you're always a jerk at work but nice at home this would capture that You just have to dig into the details.
I wonder why personality tests are not illegal? This is essentially screening for neurodivergent people and facilitation of discrimination based on disabilities.
Until risk to the business increases, a possibly worthless speedbump on the hiring path doesn't hurt hiring and effectively makes more work for the HR manager's team, which means team growth - HR win!
Don't forget to Strongly Agree with everything your boss would want to hear and Strongly Disagree with anything that suggests you're a functional human being with goals outside the company's.
> Is that test any better than phrenology or palmistry in practice?
As a rule of thumb, if it involves psychology, the answer is always no. Humans do not have the ability to do valid experiments to verify claims, so it is all BS.
The competition pool is huge but also the number of jobs. I'm not sure he would have it easier if he specialized in some esoteric think Erlang. Yes he would compete against less people but also have barely any openings to apply to.
I meant even within the world of being a full stack dev, having an "angle" on your experience or resume. Full stack dev with lots of experience in Pandas. Heavy database optimization background, etc etc. Nothing quite as esoteric as Erlang, but I think in a pool that big you need to find something to stand out a bit.
Most full stack roles aren't that specialized (by definition). So if someone has a heavy database optimization background he probably wasn't a full stack dev. It's just a different role. Sure you can maybe pick up on some of those skills on your job while troubleshooting some performance issue, but those issues are quite rare and far between.
And again, I'm not sure a database optimization guy would find the current market any better than a full stack developer who specialized in Node and React. How many companies need a heavy database optimization background guy? Why does it make you more attractive if you have that on your resume than someone who worked only on Node and React for 8 years?
At the moment the number of open jobs is not huge. The majority of companies that haven't had lay offs have simply closed their open positions. Combined with a ton of layed off developers, most job postings get hundred of applicants within a few hours.
At the moment the number of open jobs is not huge.
As someone else mentioned here, Walmart apparently has over 1000 software related openings right now. I know a few companies outside the traditional 'Silicon Valley' company ecosystem trying to hire developers and I can promise you they're not getting 100s of applications within a few hours. The jobs are definitely out there, they're just not where most people are looking and perhaps not in a field, company or geographic location that are most people's first choice.
Only if the person taking the test is willing to lie. I imagine most people understand that you are supposed to lie on these tests, but I could imagine some extremely honest people failing them even if they were smart enough to figure out what the employer wants to hear.
For me this is not answerable question because it is lacking context. If it was not possible to go to the next question, it would be where I would end the interview.
Context is everything, and why these fail. When I did one, the process included the narrative version of the results. I had a question that was something like "It's important to support your organization", which I agree with. In the narrative form of the results, it concluded that I "may not tell the truth to superiors if something is wrong" from that.
Of course I support the organization, and I think being honest with superiors is the best way to do that.
In the end, these things are so imprecise that you have to get to know somebody to know which parts are accurate (some were) and which aren't. By †he time you know how accurate it was, you know the person well enough to not need the test.
> The personality tests can fuck right off, though.
Disagree. I can train you to do your job but can't train you to have a better personality. If someone has a toxic personality I would like to screen them out before sinking time into them.
I suspect OP was referring to myers-briggs questionarres or similarly borderline-pseudoscience survey based means of answering "are you a $a or a $b?".
I agree that personality is an important thing to consider in interviews. But trying to gauge it with tools like that is at best a waste of time and at worst actively misleading.
The problem is that the most common "personality test", the "Myers-Briggs" has nothing to do with "personality", let alone "toxic personality", so an argument about "personality" is not an argument for that particular personality test. This is a bait-and-switch dishonest argument - the gap between them is exactly the problem.
This is because the "Myers-Briggs" is hogwash, with as much predictive power of personality as astrology. i.e. none.
If the people administering them are using them for the intended purpose, they're rejecting candidates on nothing more than a roll of the dice. If not, then as others suggest, they are covert way of "screening for neurodivergent people""
So: This _personality test_ can fuck right off.
I doubt that any other quick multiple choice questionnaires are much better. If anyone wants to claim that they're worth anything, show the proof please.
Then you would need to screen them for personality disorders such as narcicism, not for how introverted they are or how much they appreciate art.
No, neuroticism isn't what you are looking for either, neither is conscientiousness. It can be argued that for an academic position you would want high conscientiousness, but I think many would argue that you want some of your professors to have disorganized, messy offices.
Echoing a comment from that thread, IT does have a huge superiority complex. I feel these long interview processes are related to the hiring managers’ need to feel superior due to feelings of inadequacy. Perhaps because huge sums of cheap money has allowed many departments which produce very little to exist for a long time, so they look for meaning and value in the hiring process
meanwhile, we hire managers that don't have basic decision-making or people skills...
They justify their higher salaries due to their higher responsibilities, which they just assume the risks and jump jobs when shit goes south.
A reminder that your pay corresponds with your expected skills, hiring a top 1% de offering market average, is a delusion. But the interview process is out of control for devs, and basically non-existent for managers.
Ps: I'm a manager, so I can say that I'm overpaid for what I deliver, while devs are underpaid and the expectation on them is out of reality.
Agree there are a lot of bad managers out there, a decade of tech bull market and hyper growth didn’t help. Not sure why you think expectations and interview standards are lower for managers in general though. For me, managers have a much higher bar than ICs because they must have a high level of technical experience and judgement in addition to all the people skills and strategy. An EM must fill the gaps between other functions because at the end of the day engineering (for software shops) is who ships the product. If you think it’s easier than being an IC I don’t think you’re doing it right.
Line managers basically never have the final word on pay, at most they sometimes get discretion to move pay around within a defined band. Pay bands are handled by the C-suite in small companies and compensation departments in large companies. Both generally reference databases of "market rate" compensation.
As a rule, people are not paid "what they are worth", they are either paid market rates or convince the company they have a differentiated skillset that warrants compensation beyond what is normal in the market (usually by tying their performance to some important metric). No one has yet found a way to change this from within a corporate structure.
The takeaway from this is that in communities open to everyone there is an overwhelming input from people with zero experience struggling to get on the ladder.
Even more infuriating are interviews that expect you to complete a complicated 'homework assignment' that is essentially the company trying to get free coding work from its applicants.
I once interviewed where they gave me a big assignment to complete. I must have spent about 8 hours on it. Since I wanted them to see my thought process along with code examples; I gave them something that was about half pseudo-code and half real working code. The hiring manager said they couldn't accept it until I had converted all the pseudo code into working code as well, along with a set of tests that exercised the code. I estimated that the assignment would take me an additional 20 hours or so to complete.
I told them that I had spent enough time working for free and if they wanted to pay me for the work I was doing, I would be happy to complete it. They declined, which told me all I needed to know about the company.
This is the main reason I opt for freelance work rather than going full time. I don't want to spend so much time preparing for an interview / test / what-not only to be stalled or excused for some unmentionable reason.
Freelance market is awesome these days with more businesses reducing in-house staff and outsource whatever they can to cut operational costs.
I've been hiring and managing developers and engineers for almost 20 years, and I don't/won't do any of this nonsense.
During the course of a single interview I describe what we are building and how we are building it, and invite the candidate to explain if/how they could participate in that. One or two senior guys from the team will ask them some smart questions about real-world problems and complexities to get a sense that they know their stuff. No quizzes or puzzles or abstract questions. No homework. No second or third or fourth interview.
I interviewed a bazillion times last year. What most places are looking for is a replaceable commodity they don’t have to train. If you want to be employable against that focus only upon what’s currently trendy/popular. If want to appear as a rockstar in that context spend about an hour each with up to 30 different popular tools. The goal here is do not differentiate yourself, but just be extremely proficient in the most common technical requirements building a CRUD tool with the flavor of the moment.
in my opinion, all job postings shall state their pay ranges in the title, to avoid wasting everyone's time.
followed with key requirements, locations(and if remote is OK)
followed by your interview process steps.
that's all I need, I don't need schedule a 20-30 minutes call for each recruiter for info I can filter in a 2-minute read, in fact a twitter-size job post can cover all the essentials before any meaningful talk, why making a lengthy process longer than necessary.
and, if you're asking for many years experience for a junior position, or you're asking a senior developer to be great at leetcode challenges, you might be doing something wrong.
I have been unable to find work for so long that I am on the cusp of exiting the industry. I need a paycheck. I've been in full stack web dev for over 20 years, and I've never once had trouble finding a job before now.
For months it's been hard to get any response to an application, let alone an interview. And when I do get responses, they are often strange. One company where I would have been a perfect fit claimed that my code sample had "scary" SQL injection vulnerabilities. It did not, I have been doing this for decades, and I know how to sanitize my inputs.
I asked for specific file name and line number, and they sent back a vague non-response on how to identify vulnerabilities, so I stopped pursuing it. It was a lost cause, even if I showed them how they were mistaken, it wouldn't work out. I suspect they were using some kind of automated scanner that flagged some false positives.
I don't want to stop making software professionally, but that decision may not be in my hands.
The comment about healthcare (life-altering health outcomes at play) interviewing being less of a rigorous process than screening the devs for icanhazcheeseburger is spot on. What the fuck is wrong with us?
You hire a responsible experts when you want to trust them with full decision authority. You can only do this if there's no real risk of failure.
But when you're producing software with real risks, you have a QA-first process that details, validates, and verifies all requirements. You have a large team, cross-checking (and helping) each other. The key virtue of a developer in this context is diligence and honesty.
It's a great gig. In FAANG and software-only products, you're always on the critical path. For medical devices, it's typically the chemistry or device that sets the schedule, so software can proceed at an even pace.
A friend of mine is currently looking for .NET developer job in Switzerland. Looks like everyone there is doing a one day of on-site interviews with HR, technical tests/pear programming and meeting managers.
> Anyway, the task they sent me was estimated to take 8 hours of work and couldn't be paused.
Once I was given a task to create some validation code for given criteria and integrate it in the given project.
They then invited me to an in person interview. At one point, I had to pair program with one of their developers and what I saw kind of shocked me.
They integrated my code from the interview into their production code and their developer had an issue with it and asked me to help getting it working and write a couple of extra tests. So I did and they seemed very happy.
I didn't get the job though. They said I am not a "cultural fit".
I asked them if they actually used my code and if so they would have to pay me for the whole day, but they never responded afterwards.
I decided it wouldn't be worth to legally pursue, but since then I decided to not do any pair programming or coding tests.
I actually noticed that started happening in Europe. Last month I had a similar experience, where a mobile startup wanted to hire me as a mobile developer, but wanted to test me, and the test was to implement a new feature and screen of their existing app released on the App Store..
I aced it, they were more than pleased, yet in the end they did not hire me as they said that they are actually closing the position because of the market downturn.
At least they gave me a 50€ amazon gift card..
So your work is good enough to use in production, but not good enough to pay for? I would contact a lawyer on principle. Minimum write a Glassdoor review.
I am a bit on the spectrum and their team was quite younger than myself, they've been talking a lot about how they like to party together after work etc. Not my cup of tea, so to speak.
I much prefer apple programming to pear programming. (ba dumm tsss.... sorry, couldn't resist :))
Although I'm on the Java side, I've yet to see a leetcode interview in CH, maybe I got lucky so far, but most of the interviews I had before were completely reasonable, maybe even too easy. The one that I failed miserably was an architecture discussion, in which I got an empty paper with a pen, and was expected to come up with the design of their existing system (I was allowed to ask questions). But even from that I learned so much, so no hard feelings. I will know much better what to do next time :)
Hey everyone, if you're frustrated with interviewing processes I high recommend build your own company. You do not have to aim for 1 billion USD valuation after 5 years. Just aim for happiness and make your customers happy too. It is not as hard nor scary as many of you think it is. It requires you to take responsibility though. The world is still mostly running on spreadsheets and we all know software developer skills can transform spreadsheets into better business value.
It's very difficult to pull off though. Especially outside the US. My advice is:
- Don't aim too big (there will be way more competition if you're trying to build a world-changing product).
- Don't go into any sector where big tech corporations are already offering products (no matter how bad those products are, you will not be able to compete on marketing; nobody will find out that your product exists).
- Find a niche. The more boring and tedious the niche, the more likely you are to succeed.
Basically, base your entire strategy around minimizing competition at all costs. Do not underestimate competition. Do not underestimate the power of a great big pile of capital in the hands of your competitors; no matter how terrible they are.
This is not capitalism. This is crony-capitalism. NEVER FORGET THAT. As you rise up the ranks, prepare for less ass kicking and more ass kissing.
It’s true, and partially why I pivoted away from web development. Web development is so repetitive. It can be oversimplified to “make me a GUI for this database”. Yawn. I didn’t want to spend the rest of my life correcting my CSS and JS for subtle changes to browser engines. When IE died, Safari took over as the “problem browser”. I think there will always be a “problem browser”.
This is happening because it's drilled into managers' heads that one bad hire is disastrous for the team/company. So the cost of a bad hire exceeds the cost (to the company) of implementing arbitrary amounts of screening to make sure bad hires are caught -- even when you take into account the effect of a very high false positive rate prolonging the interview process.
How much does it cost the company? The process described is 4-5 hours taking time from people who have jobs to do, and they don't look like the cheapest employees.
With rejections and applicants who finally turn off the offer, it must be quite significant, especially for a 6 month contract.
IMO, the rates are very bad after a lot of layoffs from big companies and a few big bank collapses. The interview processes frustrated me before. It's not good (mentally and physically too) for you if you get frustrated. So, forget all the failed interviews and move on.
I don't think this anecdotal reddit post says much of anything. We don't know the persons resume/background/experience, nor the position. $65/hr with 10 years of experience is uber low. That rate is comparable to FANG intern pay. You could find a contract job 15 years ago paying that, working for some insurance company or large boring bank. It just sounds like a shit job at a shit company. Probably located in a small market/geo. OP also says "actual client" - so this job is likely via a third party (either a staffing firm or some MSP); AKA that $65/hr rate is even lower than it should be, because the third party needs to take its 20-40% cut.
LOL - Heh, COBOL didn't work out to well for making 'developers' entry level personnel. :-D IBM had dreams of minimum wage programmers what - 50 years ago now ?
Oh, sorry - guess I mis-interpreted your "highly paid" comment..
As for decision making - like every other field, I think that has more to do with the individual then anything else. Some people are good at it sorta naturally gravitate that way, others have no interest or skill in it. I know I'm much happier as an IC/team lead/etc. Sitting in meetings and paperwork really aren't my thing :-/
I found it strange that at the height of the hiring frenzy when everybody was complaining about not being able to find people... is precisely when this stuff seemed to hit peak.
I have to agree, the current job market is truly flipped upside down and you can feel the uncertainty in the air, at least in Europe.
It seems there is a mismatch currently in the market, between what companies are demanding, and what employees are offering.
I am honestly thinking of creating a service, where I would create a database full of developers looking for work, and then only give access to companies seriously looking to hire, so basically like LinkedIn but minus the trash and spam.
Ever since I stopped doing mainstream stuff, and went niche[1], I've had zero problems finding a job and I'm not that special. There's a lot of people on the planet, more every day, so if you expect your life in the gray mass to get easier over time, well, it probably will only get harder.
It was all over the place in terms of interview practices last year when I was looking -- which I found odd given that that was kind of the height of demand; start of last year people were complaining about not being able to find people, but then the interviews would often be quite crazy.
But I think it's only going to get worse now that the market is getting flooded with people coming from rounds of lay-offs, and the VC market tightening, etc.
I have my first interview in 4 months tomorrow. I'm pretty sure I'm going to completely fail. I'm not sure what I'm going to do if I don't find something soon though, the few recruiters trickling in have started suspiciously asking how long I've been on the market. I've kinda expected I would end up here for years, I've just completely to prepare for it.
Honestly I'm at the point now where I'm considering moving on from software as a career. I've kinda got what I wanted out of it anyway and most of it is snakeoil anyway. I just need to find a way to meet my basic living expenses with minimal work.
It's not all hellfire. I accepted a job offer earlier this month. There is distinctly less opportunity at tier 1 public companies (FAANG etc., and even those are still hiring) but I still had plenty of interviews and got a reasonable payrise.
1. There's a lot of risk aversion in corporate culture these days, the cost of a bad hire can be very high and nobody wants to be held responsible. By having multiple rounds - which in turn requires a lot of people involved - responsibility is diluted so if there's a bad hire you can blame the process rather than one manager.
2. It's an endurance test. Someone who can power their way through round after round of interviews, home projects, online tests and so on shows good "work ethic" or at least a genuine interest in the job.
3. Cargo-culting FAANG. If Google or Meta do this, then we should too (even though we're a tiny startup). It's a bit like picking microservices or Kubernetes: there's good use cases, but for a lot of projects they are overkill.
4. Concern about discrimination: companies are scared of showing bias (whether against or for certain ethnic groups, genders etc) and a formal process should in theory be meritocratic than the old days of "let's just have a quick chat and hire based on gut feeling".
There's good reasons here, but it's probably gone to extremes, particularly for positions at smaller companies with corresponding smaller salaries and benefits.