I don’t want in the least to be a jerk about this piece. I can relate to it, inasmuch as my last effort to find a new job was for the most part a miserable and disheartening experience, and I don’t personally have anything like the will to engage in good faith with the kind of bullshit that’s described here.
With that said, this kind of thing - of which I’ve read countless iterations by now - mostly functions for me as a reminder that, at root, the industry is completely fucked and somehow we’re all playing along. The fundamental work of most “software engineering” is poisonous to the world, the organizations described in these essays are owned by people who fall somewhere on a spectrum between con artists and malevolent oligarchs, and a class of diligent strivers is engaged in competing for a place in the second-order technical/administrative ranks. A status that lets you earn much better money than in most of the rest of the economy while directly helping engineer everybody else into a state of precarity. (A state which, of course, is what awaits you if you exit the predatory scene you’re enabling before extracting enough resources to be insulated from its effects.)
Doing well in this environment seems to require either a quietly mercenary attitude or a profound capacity for self deception. There is of course a lot of human wreckage along the way. It’s striking to me how seldom I see anyone make the leap from “trying to get these jobs was a bad time full of getting raked over the algorithmic live-coding coals” to “we should burn this entire structure to the ground”.
To be fair though, software engineering isn’t a homogeneous field, and I’m not sure ‘most’ is poisonous to the world. I have certainly never worked on anything I would consider poisonous, enabling of some kind of evil, or similar. What I do now is targeted at helping people out of bad situations and get themselves more stable.
If you have some analyses of software engineering across the full spectrum that can back up what you’re claiming, I’d be interested to see them, as what I hear in articles like this just sound like they’re from a bubble I haven’t been near.
what I hear in articles like this just sound like they’re from a bubble I haven’t been near
Those are exactly my feelings. For the last 10 years in the field I haven’t been anywhere close to the environment described in pieces like this, and yet every time they pop up people (mostly on the orange site though) always find it relatable and comment with their similar experiences.
Perhaps it’s just my own bubble, but it seems so alien and bizarre that it seems like an entirely different industry whatsoever. My first job was in a ~300-person company, and that was the last time I had a technical interview, and the last time someone asked for my resume. Everything since then was a “oh, we already know you from somewhere else/seen your code on github, that’ll do, when can you start”.
All this talk about having a Top Dog Company in your CV, and I’m yet to see anyone even bothering to look at mine. All this bragging about massive salaries if you can get there, and yet my friends at Google get about the same money as I do with me bouncing between small companies and niche startups. I don’t think I’m that unique here either – and it makes me wonder why do people choose to put up with that crap? Multi-stage interviews, GDPR-insulting background checks, and for what? A status symbol, bragging rights? In an industry that is so starved for competent engineers that it’s willing to please you left right and center if you ask for it?
at root, the industry is completely fucked and somehow we’re all playing along. The fundamental work of most “software engineering” is poisonous
and your solution (even though I hope metaphorical) is unrealistic and violent:
“we should burn this entire structure to the ground”.
I think that comments like that invoke raw emotions which harm constructive discourse. It is very unlikely that the “the industry is completely fucked”. I guess strong language feels good sometimes but may leed to people just expressing more of it and either cherishing their helpless victimhood or go for (hopefully harmless) violence.
It is very unlikely that the “the industry is completely fucked”.
This is undeniably a generalization. All the same, it encapsulates pretty well how I feel about the broad spectrum of the software economy, from smalltime undertakings to startups to bigcos to megacorps. There are places where writing code isn’t directly in service of anything particularly egregious, and employment relationships that are relatively benign, but both are still situated in a dysfunctional ecosystem in technical, social, and economic senses. It’s almost impossible at this stage for even the best of intentions and practices to escape this reality. To a first approximation, there is very nearly no ethical participation in software which is compatible with making a living at it.
So: Yes, I think, completely fucked. Many intelligent people of good will disagree with me, but as these feelings have solidified, I’ve also found I’m hardly alone in them.
I think that comments like that invoke raw emotions which harm constructive discourse.
Perhaps. I don’t have any desire to turn a venue like this one into more of a shouting match. On the other hand, when I read material like the linked article, I can’t help feeling that a lot of people would be better off with a straightforwardly negative view of the system within which they’re competing for status and access.
Do you have examples of professions with a better ecosystem in terms that you like?
I guess “burning down” wouldn’t work or would actually just create chaos that is unlikely to be filled with something better. But I’d be interested in how something better would look like.
Do you have examples of professions with a better ecosystem in terms that you like?
I’m really not sure. I think we could stand to learn from the healthier aspects of the trades, academia, and actual engineering disciplines. But then these are realms with their own deep problems.
But I’d be interested in how something better would look like.
I imagine there’s a possible path from where we’re at to somewhere better, however unlikely. I’d like to see people at existing companies unionize & otherwise organize. I’d like to see new enterprises organized from the start as worker cooperatives or similar. Beyond improving their own working conditions, I’d like to see technical professionals use their relatively high status and power to better the lot of working people in general and reign in the predatory impulses of capital. (If nothing else by, like, forcefully declining to pour labor into said predation.)
I honestly do not understand how trying to get everyone to speak like a cartoon version of a british buttler is an improvement of discourse. It’s not like this is a children’s tv show either, nor is lobsters funded by Disney.
I don’t think policing speech to try to make everybody write like a lawyer is gonna make the site “better”. Might reduce the ratio of curse words, but it will also make everything boring to read.
Complaints about interviewing seem rather similar to complaints about open-plan offices. Pretty much everyone agrees it sucks, but it also never seems to change 🤷♂️ Indeed, things seem to be getting worse, not better.
My biggest objection is that you’re often expected to spend many hours or even days on some task before you even know if you have a 1%, 10%, or 90% chance of getting hired, and then you get rejected with something like “code style didn’t conform to your standards”, which suggests they just didn’t like some minor details like variable naming or whatnot.
I usually just ignore companies that treats my time as some sort of infinitely expendable resource, which doesn’t make job searching easier, but does free up a whole lot of time for more fulfilling activities.
“Hire a candidate for a week” doesn’t strike me as a solution to, “Screen people without wasting anyone’s time.” At the very least, it forces the candidate to spend a week in what amounts to an extended interview. It seems to me like it’d be far more time-consuming for the existing team as well, what with coming up with a steady stream of short projects that require little or no onboarding, working with the candidate for the week instead of whatever else they’d otherwise be working on, evaluating the candidate’s work, and so on.
I’m not arguing that it’s a bad idea in general, just that I suspect it isn’t a good way to reduce wasted time.
The responses show that it is just hard to come up with a process that works for everyone. Maybe one needs to offer choices but that has its own complications and reduces comparability.
Some of those problems sound at least an order of magnitude harder than I’d expect in an interview unless it’s a specialized role and you were asked to prepare. Anyway, a positive bit of advice is that if you still want to do this, go try out interviewing.io. You’ll get concrete feedback on what they expect.
By the way, one tiny piece of information about the world (offered with no judgment, b64 decode if you desire the advice, leave alone otherwise):
“The best solution I’ve come across when working on something similar…”, Solve the problem while displaying experience, skill and phenomenal personality. Extra points for making them laugh. You could tell them you don’t know and attempt a solution - that’s the safer route, or you could lie and pretend cough be brilliant, like the unicorns they’re expecting and solve it perfectly.
I think your advice is spot on. I’ve heard that interviewers will often look for the way you approach a problem you’ve never seen before instead of your solution. You’re usually allowed to ask for help or explain the way you would attack the problem if you knew a specific piece of information that you’re currently forgetting. The interviewer probably doesn’t want to work with someone who says “I don’t have any experience in that” and lets their brain shut down right then and there.
The issue I have is that in a lot of interviews that’s not stated up front. So now I’m stuck in this spot of, do I ask and say I don’t know, and be downgraded or ignored because I “didn’t know it”? Or will I be downgraded because I didn’t ask when they were expecting me to. State up front what you want from me. Don’t leave it ambiguous.
This is the most important part of the post for me:
I have never been a part of a hiring team and I am sure there are things going on that I don’t know about.
I have some experience evaluating candidates (at small/medium sized startups). I’ve also gone through the BigTechCo interview ringer. My opinion: because the factors that make someone a good engineer are many, complex, and very hard to detect in the short amount of time given during interviews, and that we have no standardized licensing the way that other engineering disciplines, law, or medicine do, and that the work of programmers is so broad that two senior engineers can have almost no overlap in technical knowledge if they’re from different parts of the stack/different industries, there is no method for hiring that doesn’t suck. DS&A puzzles suck for hiring, but in ways that minimize the worst outcomes for companies.
The main constraint is time: Both the candidate’s and your own evaluating engineer’s. High demand candidates won’t interview with you if your process takes significantly longer than the industry average. You may need to spend 8-20 engineering hours on a single candidate - this could easily be $1000+ per candidate (plus recruiter/pipeline costs), and most will either fail or take another offer. You may get one hire for every 10 that goes through the full process. I’m making up these numbers but to be clear: it gets expensive.
Once you have them: You can have a technical conversation, but unless you see actual coding, this means bullshitters can get through. You can watch them code something closer to actual work, but actual work requires a lot of domain knowledge ramp-up. Throwing them into your own code base/some realistic simulation without letting them acclimate is not going to get you much signal very quickly. You can extend this exercise to multiple hours/a day, but then you only get to run a single trial, so to speak. You can give them multi-hour take home projects but the most in-demand engineers will just take an offer with somewhere that won’t make them do that. Additionally, these take more time for your own engineers to evaluate. It’s also game-able, they’ll ask their more-qualified engineer friend for help.
Data structures & algorithms are one of the very, very few things that all programmers are supposed to have some handle on. Almost nobody uses this knowledge directly day-to-day, but it’s the closest thing to a middle ground we can evaluate people on, because programmer skill sets are so varied. So we use it as a standardized test. People who are just incredibly smart/naturally gifted won’t have to study much to pass DS&A interviews. You want these people. People who are kinda smart but incredibly hard working will be able to study a lot and pass these interviews. You also want these people. There’s another huge class of people who are good at their jobs but don’t want to or can’t put in time studying. You probably want a lot of this group, but without the signal that DS&A interviews provide, you can’t tell who’s good without spending more time than a DS&A interview takes. Because of how expensive a bad hire is (easily able to provide negative value) even if only 1/10th of this group is bad, the expected value of riskier hiring is lower than throwing away candidates you’re almost totally sure would be good hires.
We’re basically using DS&A interviews the way other industries/disciplines use standardized licensing. There’s a formal process in place run by some central organization that tells companies that some person can be a mechanical engineer/doctor/lawyer. We don’t have this for software engineering because: software engineering is still in its infancy so best practices/required skills change 10x faster, required skill sets between different programmers can have nearly no overlap, the demand for software engineers is growing much faster, and for the majority of software engineers (maybe just web developers) when someone makes a mistake, no one dies, so there’s no external(government) enforcer of competency. It could be that in a few decades it may make more sense to have a licensing system like MechE’s do, once the field solidifies, or is broken into different specializations that are more easily evaluable.
It sucks but it sucks less than other systems - from the company’s POV. It sucks a LOT for us engineers. But unfortunately, this may actually be the current global maxima. I understand the complaints that the author has, but it should be tempered by the perspective from the other side.
without the signal that DS&A interviews provide, you can’t tell who’s good without spending more time than a DS&A interview takes.
There are plenty of other, more real-world, tasks you can give them though. At my last job we just asked people to write a CSV contact list importer for an SQLite database with some minor constraints (e.g. merge duplicate emails), and that seemed to work quite well.
The thing with many of these algorithm questions is that most of these algorithm were invented by people who went on to win Turing awards and the like for doing so, and have Wikipedia pages. You can’t really expect anyone to invent something equivalent in an interview, so you’re basically just testing memory/knowledge more than anything else. If you only hire people with enough interest in that area you’ll end up with only a certain type of programmer, which probably won’t be too great for the company, either.
This works, but you’re filtering out a lot of people who would be good hires but maybe haven’t done a lot of data engineer work recently. If you’re okay with that then great, but I think what FAANG+ are going for is something that isn’t going to advantage any one specific type of engineer. They’re also going to be filtering out a lot of good people, but not from any specific engineering demographic. I know engineers who I would regard as generally better than me who would not be able to complete the task as quickly because I’ve done a similar thing more recently, or maybe they just happen to not have needed to use SQLite in their careers so far. The big companies want a test they can use for any type of software engineer.
To your second point - right, I don’t think you’re expected to invent anything truly novel. If you have a deep understanding of the dozen or so algorithms that show up in these tests, what they’re looking for is which ones to apply when. You can acquire this trait as I said in my original comment by either being very smart and studying a little or being a little smart and studying a lot. So, the test ends up evaluating (intelligence*diligence) which may be better for large tech companies (who have a wide variety of work that needs doing, but can’t create a dozen tests for each discipline that are of objectively of equal difficulty[otherwise everyone who wants in would just study for the easiest test]) than how recently you’ve done something like the specific exercise you give them. I think generally any company can use smart and/or hardworking people, so this works well enough without biasing towards specific types of engineers.
If the difference for you is that you do just want someone with the specific domain knowledge of “data engineer who works with CSV and SQLite” then great, but that test doesn’t scale for your entire engineering team forever.
It seems to me that this kind of task is generic enough that it doesn’t really require a lot of “data engineering” experience; at least, that was our intent. Basic SQL knowledge is not completely universal, but it’s probably as close you can get, at least in the web backend space.
Note this was a “come back in a few days when you’re ready”-task, not a “please write this in n-minutes”-kind of task. I appreciate that some people may be more familiar with this kind of stuff than others, but in the “real world” you’ll end up doing loads of stuff without prior experience to the specific task. Even with 0% familiarity (which is probably very rare) it’s not very hard to come up with the required knowledge in a few internet searches. I think Joel Spolsky once phrased his hiring criteria as “smart and gets things done”, and I think this is a reasonable – though not perfect – test of that. In the end, it’s the kind of task people are expected to be able to solve in their actual job, regardless of previous experience.
I wrote a 40-line version (in Go, a rather verbose language) in 20 minutes or so. Most of the rejections I saw were in two categories: the horrible overcomplicated (instructions explicitly mentioned we were looking for just a “simple straightforward solution, no caveats”, some people sent in versions with loads of abstractions, needless parallelism, etc, sometimes hundreds of lines), or the chaotic clueless programming-by-trail-and-error where the candidate clearly had trouble understanding basic programming constructs and just tried-and-tried until something kind-of-maybe worked.
Companies like Google probably have many more applicants than we had (although we got quite a lot), so they can afford to be more selective, but I see loads of smaller companies copy the same techniques while at the same time complaining that it’s so hard to find good engineers.
In your previous post you compared software to other specialized fields (law, engineering, medical, etc.) and I wonder what the state of competency is there. I also doubt that (otherwise competent) people in those fields would be able to pass stringent competency tests in their field, just like quite a few drivers would likely fail a driving license test after 15 years.
At the end of the day, interviewing is hard no matter what you do and I don’t think there is One True Way™, but I’m skeptical that testing candidates on theoretical knowledge which bears almost no relation to their actual job is the way to go for most interviews.
It sounds to me that now companies are more afraid of hiring bad candidates than they are excited about the opportunity to hire a great candidate.
I currently work at a big tech company where I’ve talked to people involved in interviewing, and at some previous jobs at smaller companies I’ve been on the hiring side of the table myself. The dirty secret is that this is actually, literally, 100% true, and that this is also rational for most companies.
The cost of hiring a bad person is way, way higher than the cost of missing out on a good candidate in almost all cases, because a bad hire can disrupt the work of the good people already working there. A bad enough employee can bring negative value to the company, and firing people is a rough, traumatic event that can lead to reduced morale among everyone involved, not to mention the fact that you then have to put in a bunch of effort to hire a more competent replacement.
So the tech companies are explicitly aiming to minimize false positives, even at the expense of more false negatives, and that leads to articles like this being written by people that suffer as a result of it.
This is so true and I am pretty surprised at how few articles like this one mention it. It is especially puzzling to me because it suggests that people haven’t been involved in the hiring process at past jobs. At literally every place I’ve worked in the 30+ years I’ve been a professional software developer, both big companies and small, I’ve interviewed people, but given the frequency of “interviewing is broken and I know everything about the hiring process because I’m a candidate” articles it seems like there must be places out there where you can work for years and never learn what it’s like on the other side of the table.
I remember one candidate a couple years back who, when we asked if he had feedback on our interview process (which we often ask, whether candidates get an offer or not), said something like, “If you were faster at firing people, you wouldn’t have to be this careful about hiring them.” Which, if we hadn’t already known it, would have told us this was a super inexperienced candidate who (a) had never had the pleasure of being on a team with a bad hire who was a huge drag on the team, (b) didn’t appreciate the cost of getting to the point where you even know you want to fire someone, and (c) didn’t know much about what the process for firing someone looks like, and why it looks the way it does.
My favourite question so far - both as a candidate or as an interviewer: “what you did at your last job and what have you learned, what was hard about it?”
When this question is answered you know a lot about the candidate. And the interviewer can follow with a more technical question that can test something about the first answer.
I think they are selecting for fresh college absolvents who can still remember their algorithm proofs. Easy to teach their own way. No strongly held morals. Admiration of anything large enough built-in.
“Can you write an algorithm to find the Kth highest value in a binary tree?” is explicitly a type of question we are told not to ask on interviews at Google. But there are tens of thousands of interviewers so sometimes a few go rogue through inexperience.
That seems just the right kind of question to ask if you’re going to ask algorithmic questions: not something standard that you’re just expected to memorise but something you can very quickly and easily work out on the spot if you actually know how the first thing about algorithms.
I’ve never been through this kind of hell, maybe because I’m older; early on things weren’t so regimented, and more recently I’ve got enough experience that speaks for itself. On the other side, when I interview people I’m mostly looking at “people stuff” like whether they can describe their work in a clear way, or make intelligent comments about things I describe to them.
About 10 years ago I was at a company doing a lot of entry-level hiring, and I was interviewing recent college grads; we asked some easy programming problems (reverse a string in C, etc.) because we found a surprising number of them couldn’t do them. Not because they were flustered but because they didn’t have the practical skills. I also liked to go through sketching out a small object model because it tests how people map a concrete problem into abstractions. But no algorithm bullshit.
The thing that confuses me is: as an employer it’s really hard to find good candidates for SW Eng jobs. So I would imagine skilled, smart people like this guy have it easy. But from his experience, it seems like companies must be deluged with strong candidates and are using difficult tests to weed them out. What’s going on?
My interviewing style is to pick out real world problems that I’ve encountered, add in contextual information and see if a candidate can carry on a conversation about it with me like a peer. I’ve had to failsafe to silly coding problems to test if the person can even write elementary functions because I’ve literally had people try to bullshit their way through. Things like “maintain a list or other data structure of the top ten numbers seen so far for inputs of length 10, 1000, 10000” with “okay, let’s talk about why and how it behaves”
Unfortunately, the experience of travel to an unknown location for the developer equivalent of a free style singing audition is very tough for nearly everybody. I’ve had Java developers with four years experience forget what an interface is, Python developers who have minimal exposure to the standard library, college students who freeze up at the dreaded question “okay, let’s try a different approach” (as if I’m criticizing them as opposed to trying to engage in a discussion of compare/contrast because our world is full of choices and preferences).
The entire experience of using a few hours to evaluate fit is insane! That’s like speed dating and deciding on a ring for immediate marriage!
But what else can we do - every other process takes valuable time, time we don’t have to spare. Even Google, with its billions and billions, likes to do rigamarole “entire day speed interviewing with half a dozen people”, which is horribly draining. Not a long process of social integration but a sudden violent and draining speed date.
It’s really hard testing for flexible thinking. It’s even harder testing for code competency, because what you think is a common or simple algo is not others common/simple algo.
AFAICT the google of today tests for compliance and a baseline of intelligence. Candidates know what the question pool looks like - the test is whether they are willing to study pointless trivia in order to get the job.
Great! So this man is telling me that after I had spent 4 months studying for this interview, spent virtually every waking hour outside of work completing practice problems, and rehearsed how to present my background in soft skills questions that he didn’t bother to spend 10 minutes to glance at my resume.
Assuming negative intent or indifference won’t make the author any happier.
Here are some other possible explanations:
The interviewer had a bad day, was up late with a sick child, slept poorly, etc.
A recruiter thought that micro services weren’t required.
Team members disagree about whether experience with micro services is a requirement.
The interviewer has looked at dozens of resumes and has confused the details on them.
Another interviewer thought that the author was a good fit and could make a case for himself.
A shitty, gruelling interview process seems like the flip side of the coin for the incredible inclusiveness of the software industry. No other industry lets high school dropouts lead a team leading critical software development with billions of dollars and human lives at stake.
We can come up with better problems, sure – but the kind of thing that many people want (some sort of licensing board that certifies you as competent so that you can skip technical interviews entirely, for example) would close off the software engineering industry to vast swaths of people.
Here’s the thing I don’t get about “practicing for an interview”. There’s basically two scenarios in which an employer will want to hire me:
To do things I know how to do well, and have done before
To do things I’ve never really done before, but can probably learn how to do
For each scenario, there’s two hiring process possibilities:
a. They’ll ask me about things I’ll actually do in the job, or things I need to know to do the job well, or reasonable proxies to those things
b. They will ask unrelated stuff
For 1a, there’s no point in my practicing for an interview, because I’ll be setting myself up for failure. If they ask me about the things I’ll be doing if hired, and I don’t know them fluently enough to be able to answer without preparation, then I’ll not do well in the job. Better to fail now than 3 months in. A rejection email hurts less than being fired (source: been there, done that)
For 2b, if they ask me about things I’ll be doing if hired, they’re morons, I clearly stated I don’t know how to do those things. They should instead ask about maybe somewhat similar things I’ve done, and try to find out if I can learn fast enough.
For any b scenario, that’s an exclusion criteria from my part: If you want me to be a dancing monkey during the hiring process, it’s very likely I’ll not get enough autonomy and support to work well once hired, so I don’t really wanna work for you.
Granted, this is not a perfect criteria: an employer might have what seems like a reasonable hiring process, in terms of not demanding ridiculous tasks, but also having a shitty culture. The hiring process is relaxed just because they’re hiring anyone that will take the job. But then again, that’s not my only criteria.
Obviously, this comes from a quite privileged position of being able to take my time to find a job, every time I had to look for one. Maybe if you’re in a hurry, practicing is a better investment of time than waiting for a non-bullshit hiring process, since it will widen the pool of possible employers, even if at the risk of landing a not-so-great one (a developer’s gotta eat, after all).
I think one of the biggest problems is that the time put in by interviewers is significantly lower than the time put in by interviewees. If it did match, then we would see a lot of multi-layered good problem solving from both sides which would help assess candidates better and remove biases.
Usually things work out as is, and that’s why nobody bats an eye, but I would hope people and companies to strive to do better.
I don’t want in the least to be a jerk about this piece. I can relate to it, inasmuch as my last effort to find a new job was for the most part a miserable and disheartening experience, and I don’t personally have anything like the will to engage in good faith with the kind of bullshit that’s described here.
With that said, this kind of thing - of which I’ve read countless iterations by now - mostly functions for me as a reminder that, at root, the industry is completely fucked and somehow we’re all playing along. The fundamental work of most “software engineering” is poisonous to the world, the organizations described in these essays are owned by people who fall somewhere on a spectrum between con artists and malevolent oligarchs, and a class of diligent strivers is engaged in competing for a place in the second-order technical/administrative ranks. A status that lets you earn much better money than in most of the rest of the economy while directly helping engineer everybody else into a state of precarity. (A state which, of course, is what awaits you if you exit the predatory scene you’re enabling before extracting enough resources to be insulated from its effects.)
Doing well in this environment seems to require either a quietly mercenary attitude or a profound capacity for self deception. There is of course a lot of human wreckage along the way. It’s striking to me how seldom I see anyone make the leap from “trying to get these jobs was a bad time full of getting raked over the algorithmic live-coding coals” to “we should burn this entire structure to the ground”.
To be fair though, software engineering isn’t a homogeneous field, and I’m not sure ‘most’ is poisonous to the world. I have certainly never worked on anything I would consider poisonous, enabling of some kind of evil, or similar. What I do now is targeted at helping people out of bad situations and get themselves more stable.
If you have some analyses of software engineering across the full spectrum that can back up what you’re claiming, I’d be interested to see them, as what I hear in articles like this just sound like they’re from a bubble I haven’t been near.
Those are exactly my feelings. For the last 10 years in the field I haven’t been anywhere close to the environment described in pieces like this, and yet every time they pop up people (mostly on the orange site though) always find it relatable and comment with their similar experiences.
Perhaps it’s just my own bubble, but it seems so alien and bizarre that it seems like an entirely different industry whatsoever. My first job was in a ~300-person company, and that was the last time I had a technical interview, and the last time someone asked for my resume. Everything since then was a “oh, we already know you from somewhere else/seen your code on github, that’ll do, when can you start”.
All this talk about having a Top Dog Company in your CV, and I’m yet to see anyone even bothering to look at mine. All this bragging about massive salaries if you can get there, and yet my friends at Google get about the same money as I do with me bouncing between small companies and niche startups. I don’t think I’m that unique here either – and it makes me wonder why do people choose to put up with that crap? Multi-stage interviews, GDPR-insulting background checks, and for what? A status symbol, bragging rights? In an industry that is so starved for competent engineers that it’s willing to please you left right and center if you ask for it?
Your comment has generalizations such as
and your solution (even though I hope metaphorical) is unrealistic and violent:
I think that comments like that invoke raw emotions which harm constructive discourse. It is very unlikely that the “the industry is completely fucked”. I guess strong language feels good sometimes but may leed to people just expressing more of it and either cherishing their helpless victimhood or go for (hopefully harmless) violence.
This is undeniably a generalization. All the same, it encapsulates pretty well how I feel about the broad spectrum of the software economy, from smalltime undertakings to startups to bigcos to megacorps. There are places where writing code isn’t directly in service of anything particularly egregious, and employment relationships that are relatively benign, but both are still situated in a dysfunctional ecosystem in technical, social, and economic senses. It’s almost impossible at this stage for even the best of intentions and practices to escape this reality. To a first approximation, there is very nearly no ethical participation in software which is compatible with making a living at it.
So: Yes, I think, completely fucked. Many intelligent people of good will disagree with me, but as these feelings have solidified, I’ve also found I’m hardly alone in them.
Perhaps. I don’t have any desire to turn a venue like this one into more of a shouting match. On the other hand, when I read material like the linked article, I can’t help feeling that a lot of people would be better off with a straightforwardly negative view of the system within which they’re competing for status and access.
Thank you very much for the thoughtful reply!
Do you have examples of professions with a better ecosystem in terms that you like?
I guess “burning down” wouldn’t work or would actually just create chaos that is unlikely to be filled with something better. But I’d be interested in how something better would look like.
I’m really not sure. I think we could stand to learn from the healthier aspects of the trades, academia, and actual engineering disciplines. But then these are realms with their own deep problems.
I imagine there’s a possible path from where we’re at to somewhere better, however unlikely. I’d like to see people at existing companies unionize & otherwise organize. I’d like to see new enterprises organized from the start as worker cooperatives or similar. Beyond improving their own working conditions, I’d like to see technical professionals use their relatively high status and power to better the lot of working people in general and reign in the predatory impulses of capital. (If nothing else by, like, forcefully declining to pour labor into said predation.)
I’m not very optimistic about any of that, but sometimes I read essays like Considerations Regarding Distributed Software and dream a little.
I honestly do not understand how trying to get everyone to speak like a cartoon version of a british buttler is an improvement of discourse. It’s not like this is a children’s tv show either, nor is lobsters funded by Disney.
I don’t think policing speech to try to make everybody write like a lawyer is gonna make the site “better”. Might reduce the ratio of curse words, but it will also make everything boring to read.
Oh, I don’t care much about curse words. I think that the comment overgeneralizes in a way that is not helpful for discussion.
That is subjective and you are free to disagree. If you tell me why, I might even change my mind ;)
Complaints about interviewing seem rather similar to complaints about open-plan offices. Pretty much everyone agrees it sucks, but it also never seems to change 🤷♂️ Indeed, things seem to be getting worse, not better.
My biggest objection is that you’re often expected to spend many hours or even days on some task before you even know if you have a 1%, 10%, or 90% chance of getting hired, and then you get rejected with something like “code style didn’t conform to your standards”, which suggests they just didn’t like some minor details like variable naming or whatnot.
I usually just ignore companies that treats my time as some sort of infinitely expendable resource, which doesn’t make job searching easier, but does free up a whole lot of time for more fulfilling activities.
Getting rid of open - plan offices seems doable. Yet, we do not know how to screen for good engineers reliably with our without wasting anyone’s time.
Hire them for an extremely short contract? Bootcamp does that. They pay travel and $1000 to work for them for a week, which doesn’t seem too bad.
How would that work for anybody who’s currently employed?
The last time I interviewed, I was talking to about 10 companies. If the hiring process involved a short contract, they’d have been off my list.
“Hire a candidate for a week” doesn’t strike me as a solution to, “Screen people without wasting anyone’s time.” At the very least, it forces the candidate to spend a week in what amounts to an extended interview. It seems to me like it’d be far more time-consuming for the existing team as well, what with coming up with a steady stream of short projects that require little or no onboarding, working with the candidate for the week instead of whatever else they’d otherwise be working on, evaluating the candidate’s work, and so on.
I’m not arguing that it’s a bad idea in general, just that I suspect it isn’t a good way to reduce wasted time.
The responses show that it is just hard to come up with a process that works for everyone. Maybe one needs to offer choices but that has its own complications and reduces comparability.
Some of those problems sound at least an order of magnitude harder than I’d expect in an interview unless it’s a specialized role and you were asked to prepare. Anyway, a positive bit of advice is that if you still want to do this, go try out interviewing.io. You’ll get concrete feedback on what they expect.
By the way, one tiny piece of information about the world (offered with no judgment, b64 decode if you desire the advice, leave alone otherwise):
what’s the best acceptable answer ?
“The best solution I’ve come across when working on something similar…”, Solve the problem while displaying experience, skill and phenomenal personality. Extra points for making them laugh. You could tell them you don’t know and attempt a solution - that’s the safer route, or you could lie and pretend cough be brilliant, like the unicorns they’re expecting and solve it perfectly.
I think your advice is spot on. I’ve heard that interviewers will often look for the way you approach a problem you’ve never seen before instead of your solution. You’re usually allowed to ask for help or explain the way you would attack the problem if you knew a specific piece of information that you’re currently forgetting. The interviewer probably doesn’t want to work with someone who says “I don’t have any experience in that” and lets their brain shut down right then and there.
The issue I have is that in a lot of interviews that’s not stated up front. So now I’m stuck in this spot of, do I ask and say I don’t know, and be downgraded or ignored because I “didn’t know it”? Or will I be downgraded because I didn’t ask when they were expecting me to. State up front what you want from me. Don’t leave it ambiguous.
This is the most important part of the post for me:
I have some experience evaluating candidates (at small/medium sized startups). I’ve also gone through the BigTechCo interview ringer. My opinion: because the factors that make someone a good engineer are many, complex, and very hard to detect in the short amount of time given during interviews, and that we have no standardized licensing the way that other engineering disciplines, law, or medicine do, and that the work of programmers is so broad that two senior engineers can have almost no overlap in technical knowledge if they’re from different parts of the stack/different industries, there is no method for hiring that doesn’t suck. DS&A puzzles suck for hiring, but in ways that minimize the worst outcomes for companies.
The main constraint is time: Both the candidate’s and your own evaluating engineer’s. High demand candidates won’t interview with you if your process takes significantly longer than the industry average. You may need to spend 8-20 engineering hours on a single candidate - this could easily be $1000+ per candidate (plus recruiter/pipeline costs), and most will either fail or take another offer. You may get one hire for every 10 that goes through the full process. I’m making up these numbers but to be clear: it gets expensive.
Once you have them: You can have a technical conversation, but unless you see actual coding, this means bullshitters can get through. You can watch them code something closer to actual work, but actual work requires a lot of domain knowledge ramp-up. Throwing them into your own code base/some realistic simulation without letting them acclimate is not going to get you much signal very quickly. You can extend this exercise to multiple hours/a day, but then you only get to run a single trial, so to speak. You can give them multi-hour take home projects but the most in-demand engineers will just take an offer with somewhere that won’t make them do that. Additionally, these take more time for your own engineers to evaluate. It’s also game-able, they’ll ask their more-qualified engineer friend for help.
Data structures & algorithms are one of the very, very few things that all programmers are supposed to have some handle on. Almost nobody uses this knowledge directly day-to-day, but it’s the closest thing to a middle ground we can evaluate people on, because programmer skill sets are so varied. So we use it as a standardized test. People who are just incredibly smart/naturally gifted won’t have to study much to pass DS&A interviews. You want these people. People who are kinda smart but incredibly hard working will be able to study a lot and pass these interviews. You also want these people. There’s another huge class of people who are good at their jobs but don’t want to or can’t put in time studying. You probably want a lot of this group, but without the signal that DS&A interviews provide, you can’t tell who’s good without spending more time than a DS&A interview takes. Because of how expensive a bad hire is (easily able to provide negative value) even if only 1/10th of this group is bad, the expected value of riskier hiring is lower than throwing away candidates you’re almost totally sure would be good hires.
We’re basically using DS&A interviews the way other industries/disciplines use standardized licensing. There’s a formal process in place run by some central organization that tells companies that some person can be a mechanical engineer/doctor/lawyer. We don’t have this for software engineering because: software engineering is still in its infancy so best practices/required skills change 10x faster, required skill sets between different programmers can have nearly no overlap, the demand for software engineers is growing much faster, and for the majority of software engineers (maybe just web developers) when someone makes a mistake, no one dies, so there’s no external(government) enforcer of competency. It could be that in a few decades it may make more sense to have a licensing system like MechE’s do, once the field solidifies, or is broken into different specializations that are more easily evaluable.
It sucks but it sucks less than other systems - from the company’s POV. It sucks a LOT for us engineers. But unfortunately, this may actually be the current global maxima. I understand the complaints that the author has, but it should be tempered by the perspective from the other side.
There are plenty of other, more real-world, tasks you can give them though. At my last job we just asked people to write a CSV contact list importer for an SQLite database with some minor constraints (e.g. merge duplicate emails), and that seemed to work quite well.
The thing with many of these algorithm questions is that most of these algorithm were invented by people who went on to win Turing awards and the like for doing so, and have Wikipedia pages. You can’t really expect anyone to invent something equivalent in an interview, so you’re basically just testing memory/knowledge more than anything else. If you only hire people with enough interest in that area you’ll end up with only a certain type of programmer, which probably won’t be too great for the company, either.
This works, but you’re filtering out a lot of people who would be good hires but maybe haven’t done a lot of data engineer work recently. If you’re okay with that then great, but I think what FAANG+ are going for is something that isn’t going to advantage any one specific type of engineer. They’re also going to be filtering out a lot of good people, but not from any specific engineering demographic. I know engineers who I would regard as generally better than me who would not be able to complete the task as quickly because I’ve done a similar thing more recently, or maybe they just happen to not have needed to use SQLite in their careers so far. The big companies want a test they can use for any type of software engineer.
To your second point - right, I don’t think you’re expected to invent anything truly novel. If you have a deep understanding of the dozen or so algorithms that show up in these tests, what they’re looking for is which ones to apply when. You can acquire this trait as I said in my original comment by either being very smart and studying a little or being a little smart and studying a lot. So, the test ends up evaluating (intelligence*diligence) which may be better for large tech companies (who have a wide variety of work that needs doing, but can’t create a dozen tests for each discipline that are of objectively of equal difficulty[otherwise everyone who wants in would just study for the easiest test]) than how recently you’ve done something like the specific exercise you give them. I think generally any company can use smart and/or hardworking people, so this works well enough without biasing towards specific types of engineers.
If the difference for you is that you do just want someone with the specific domain knowledge of “data engineer who works with CSV and SQLite” then great, but that test doesn’t scale for your entire engineering team forever.
It seems to me that this kind of task is generic enough that it doesn’t really require a lot of “data engineering” experience; at least, that was our intent. Basic SQL knowledge is not completely universal, but it’s probably as close you can get, at least in the web backend space.
Note this was a “come back in a few days when you’re ready”-task, not a “please write this in n-minutes”-kind of task. I appreciate that some people may be more familiar with this kind of stuff than others, but in the “real world” you’ll end up doing loads of stuff without prior experience to the specific task. Even with 0% familiarity (which is probably very rare) it’s not very hard to come up with the required knowledge in a few internet searches. I think Joel Spolsky once phrased his hiring criteria as “smart and gets things done”, and I think this is a reasonable – though not perfect – test of that. In the end, it’s the kind of task people are expected to be able to solve in their actual job, regardless of previous experience.
I wrote a 40-line version (in Go, a rather verbose language) in 20 minutes or so. Most of the rejections I saw were in two categories: the horrible overcomplicated (instructions explicitly mentioned we were looking for just a “simple straightforward solution, no caveats”, some people sent in versions with loads of abstractions, needless parallelism, etc, sometimes hundreds of lines), or the chaotic clueless programming-by-trail-and-error where the candidate clearly had trouble understanding basic programming constructs and just tried-and-tried until something kind-of-maybe worked.
Companies like Google probably have many more applicants than we had (although we got quite a lot), so they can afford to be more selective, but I see loads of smaller companies copy the same techniques while at the same time complaining that it’s so hard to find good engineers.
In your previous post you compared software to other specialized fields (law, engineering, medical, etc.) and I wonder what the state of competency is there. I also doubt that (otherwise competent) people in those fields would be able to pass stringent competency tests in their field, just like quite a few drivers would likely fail a driving license test after 15 years.
At the end of the day, interviewing is hard no matter what you do and I don’t think there is One True Way™, but I’m skeptical that testing candidates on theoretical knowledge which bears almost no relation to their actual job is the way to go for most interviews.
I currently work at a big tech company where I’ve talked to people involved in interviewing, and at some previous jobs at smaller companies I’ve been on the hiring side of the table myself. The dirty secret is that this is actually, literally, 100% true, and that this is also rational for most companies.
The cost of hiring a bad person is way, way higher than the cost of missing out on a good candidate in almost all cases, because a bad hire can disrupt the work of the good people already working there. A bad enough employee can bring negative value to the company, and firing people is a rough, traumatic event that can lead to reduced morale among everyone involved, not to mention the fact that you then have to put in a bunch of effort to hire a more competent replacement.
So the tech companies are explicitly aiming to minimize false positives, even at the expense of more false negatives, and that leads to articles like this being written by people that suffer as a result of it.
This is so true and I am pretty surprised at how few articles like this one mention it. It is especially puzzling to me because it suggests that people haven’t been involved in the hiring process at past jobs. At literally every place I’ve worked in the 30+ years I’ve been a professional software developer, both big companies and small, I’ve interviewed people, but given the frequency of “interviewing is broken and I know everything about the hiring process because I’m a candidate” articles it seems like there must be places out there where you can work for years and never learn what it’s like on the other side of the table.
I remember one candidate a couple years back who, when we asked if he had feedback on our interview process (which we often ask, whether candidates get an offer or not), said something like, “If you were faster at firing people, you wouldn’t have to be this careful about hiring them.” Which, if we hadn’t already known it, would have told us this was a super inexperienced candidate who (a) had never had the pleasure of being on a team with a bad hire who was a huge drag on the team, (b) didn’t appreciate the cost of getting to the point where you even know you want to fire someone, and (c) didn’t know much about what the process for firing someone looks like, and why it looks the way it does.
My favourite question so far - both as a candidate or as an interviewer: “what you did at your last job and what have you learned, what was hard about it?”
When this question is answered you know a lot about the candidate. And the interviewer can follow with a more technical question that can test something about the first answer.
I think they are selecting for fresh college absolvents who can still remember their algorithm proofs. Easy to teach their own way. No strongly held morals. Admiration of anything large enough built-in.
“Can you write an algorithm to find the Kth highest value in a binary tree?” is explicitly a type of question we are told not to ask on interviews at Google. But there are tens of thousands of interviewers so sometimes a few go rogue through inexperience.
That seems just the right kind of question to ask if you’re going to ask algorithmic questions: not something standard that you’re just expected to memorise but something you can very quickly and easily work out on the spot if you actually know how the first thing about algorithms.
Yes but it does not require you to translate a “real world” problem into a pure algorithmic one, which is what our preferred questions do.
I’ve never been through this kind of hell, maybe because I’m older; early on things weren’t so regimented, and more recently I’ve got enough experience that speaks for itself. On the other side, when I interview people I’m mostly looking at “people stuff” like whether they can describe their work in a clear way, or make intelligent comments about things I describe to them.
About 10 years ago I was at a company doing a lot of entry-level hiring, and I was interviewing recent college grads; we asked some easy programming problems (reverse a string in C, etc.) because we found a surprising number of them couldn’t do them. Not because they were flustered but because they didn’t have the practical skills. I also liked to go through sketching out a small object model because it tests how people map a concrete problem into abstractions. But no algorithm bullshit.
The thing that confuses me is: as an employer it’s really hard to find good candidates for SW Eng jobs. So I would imagine skilled, smart people like this guy have it easy. But from his experience, it seems like companies must be deluged with strong candidates and are using difficult tests to weed them out. What’s going on?
My interviewing style is to pick out real world problems that I’ve encountered, add in contextual information and see if a candidate can carry on a conversation about it with me like a peer. I’ve had to failsafe to silly coding problems to test if the person can even write elementary functions because I’ve literally had people try to bullshit their way through. Things like “maintain a list or other data structure of the top ten numbers seen so far for inputs of length 10, 1000, 10000” with “okay, let’s talk about why and how it behaves”
Unfortunately, the experience of travel to an unknown location for the developer equivalent of a free style singing audition is very tough for nearly everybody. I’ve had Java developers with four years experience forget what an interface is, Python developers who have minimal exposure to the standard library, college students who freeze up at the dreaded question “okay, let’s try a different approach” (as if I’m criticizing them as opposed to trying to engage in a discussion of compare/contrast because our world is full of choices and preferences).
The entire experience of using a few hours to evaluate fit is insane! That’s like speed dating and deciding on a ring for immediate marriage!
But what else can we do - every other process takes valuable time, time we don’t have to spare. Even Google, with its billions and billions, likes to do rigamarole “entire day speed interviewing with half a dozen people”, which is horribly draining. Not a long process of social integration but a sudden violent and draining speed date.
It’s really hard testing for flexible thinking. It’s even harder testing for code competency, because what you think is a common or simple algo is not others common/simple algo.
AFAICT the google of today tests for compliance and a baseline of intelligence. Candidates know what the question pool looks like - the test is whether they are willing to study pointless trivia in order to get the job.
Assuming negative intent or indifference won’t make the author any happier.
Here are some other possible explanations:
A shitty, gruelling interview process seems like the flip side of the coin for the incredible inclusiveness of the software industry. No other industry lets high school dropouts lead a team leading critical software development with billions of dollars and human lives at stake.
We can come up with better problems, sure – but the kind of thing that many people want (some sort of licensing board that certifies you as competent so that you can skip technical interviews entirely, for example) would close off the software engineering industry to vast swaths of people.
Here’s the thing I don’t get about “practicing for an interview”. There’s basically two scenarios in which an employer will want to hire me:
For each scenario, there’s two hiring process possibilities:
a. They’ll ask me about things I’ll actually do in the job, or things I need to know to do the job well, or reasonable proxies to those things b. They will ask unrelated stuff
For 1a, there’s no point in my practicing for an interview, because I’ll be setting myself up for failure. If they ask me about the things I’ll be doing if hired, and I don’t know them fluently enough to be able to answer without preparation, then I’ll not do well in the job. Better to fail now than 3 months in. A rejection email hurts less than being fired (source: been there, done that)
For 2b, if they ask me about things I’ll be doing if hired, they’re morons, I clearly stated I don’t know how to do those things. They should instead ask about maybe somewhat similar things I’ve done, and try to find out if I can learn fast enough.
For any b scenario, that’s an exclusion criteria from my part: If you want me to be a dancing monkey during the hiring process, it’s very likely I’ll not get enough autonomy and support to work well once hired, so I don’t really wanna work for you.
Granted, this is not a perfect criteria: an employer might have what seems like a reasonable hiring process, in terms of not demanding ridiculous tasks, but also having a shitty culture. The hiring process is relaxed just because they’re hiring anyone that will take the job. But then again, that’s not my only criteria.
Obviously, this comes from a quite privileged position of being able to take my time to find a job, every time I had to look for one. Maybe if you’re in a hurry, practicing is a better investment of time than waiting for a non-bullshit hiring process, since it will widen the pool of possible employers, even if at the risk of landing a not-so-great one (a developer’s gotta eat, after all).
I think one of the biggest problems is that the time put in by interviewers is significantly lower than the time put in by interviewees. If it did match, then we would see a lot of multi-layered good problem solving from both sides which would help assess candidates better and remove biases.
Usually things work out as is, and that’s why nobody bats an eye, but I would hope people and companies to strive to do better.