Follow-up to "The dystopian world of software engineering interviews" - <AUTHOR> https://www.jarednelsen.dev/posts/what-to-do-when-you-reach-number-1-on-hacker-news <comment><USER3> I will never forget the time I was given a coding "challenge" and sent home with the instruction to send it back whenever I felt it was complete. This sent my OCD into overdrive, of course. For the better part of two days straight I coded my heart out and came up with this (what I thought perfect) robust system with all the bells and whistles. Heard nothing back. At all. My calls into the recruiter went unreturned and I figured I must have offended them somehow.

Fast forward a year and a friend of mine gets hired there. Turns out not only was my code pretty good, but had magically made its way into one of their production systems. The test cases that I wrote for my interview the year before word for word copied and pasted right into the prod test runs.

I know this because I used my name as the input for fname, lname trying to be a bit cheeky.

<comment><USER4> One has to wonder, then, why they didn't hire you.

I have a theory. It's quite cynical, but it's taken me about 5 decades to arrive at it: life is a beauty pageant. I don't say this lightly. It was a very slow process to get to this point.

A friend, colleague recently interviewed at a very popular, pre-IPO company that is often discussed (positively) here. He doesn't look like your typical engineer, but he's literally the smartest person I've worked with. He gets shit done. He learns new things all the time. As his current manager, I told him I would give him a perfect recommendation. He had an "in" with a current employee. He aced 5/6 of the mini interviews, but "failed" one. Fine, it happens. But, something he said to me stuck in my head: the building of said company was filled with rows and rows of 20-30 white kids. He saw 2 people of color, and one was a greeter at the front door.

I don't believe the people that interviewed him were racist, but I think every person applies a "does he/she look the part" filter and if the answer is no, the mind finds reasons to not hire.

It's not just hiring that I think is pageant-like. So many things in life are. So much so, that I think people themselves actually live up or down to their physical features and characteristics. Look at the executives at a F500 company. Male and female. Why do they look so similar? I live in a somewhat affluent community. Why does everyone here look like they "belong"? This is not a gated community, so why does that happen?

Physical features are such a basic filter, applied to ourselves and others, that I don't think we are hardly aware of it.

EDIT: there are always exceptions. It's been my experience that exceptions are rare, though. And the exceptions sort of prove my point.

<comment><USER5> I often think it would be better to introduce a random element into the process. Set some minimum criteria then just roll a dice.

<comment><USER6> Lots of biomimetic optimization algorithms like Ant Colony Optimization do this. Maybe adding some randomness in the hiring process would be a good thing?

</comment></comment></comment></comment><comment><USER7> What is tragic here is the amount of effort that is now expended by young computer scientists into the game of algorithms. Whereas a young programmer in the past may have spent their extra days writing games in Basic or static web pages, hackers these days seem to do Leetcode until the wheels come off.

We are failing to bring certain softwares into existence by effectively requiring programmers to their effort into the World Wide Nether, finding the Kth smallest element in an unsorted BST for the millionth time, for seemingly no purpose except for it is "how things must unfortunately be done."

<comment><USER8> > What is tragic here is the amount of effort that is now expended by young > computer scientists into the game of algorithms.

This is a funny topic to me. A decade ago, before Leetcode, Hackerrank, and _Cracking The Coding Interview_ , it was common for developers to complain that software developers were losing touch with algorithmic knowledge. HN-type websites were full of discussions about clueless software engineers doing damage to companies by implementing O(n^2) algorithms that worked fine on small datasets but failed in production. It was popular to complain that modern libraries, frameworks, and programming languages were making developers too soft to write good code.

The industry responded by re-emphasizing the value of CS fundamentals and algorithmic knowledge. The training industry responded with easy tools to teach and learn these algorithms. The internet is full of easily accessible materials to teach these principles to anyone motivated enough to Google it.

Now, the popular narrative has flipped. Internet comment sections want to hate algorithms and suggest that programmers don't need to understand the basics. Just rely on the frameworks and libraries to do the right thing. Just Google the solution and weave the libraries together to do what you want.

> Whereas a young programmer in the past may have spent their extra days > writing games in Basic or static web pages, hackers these days seem to do > Leetcode until the wheels come off.

Young programmers don't wake up in the morning and choose between writing static web pages or grinding leetcode. There are more opportunities than ever before to learn whatever you want.

Have you actually worked with students lately? Leetcode style systems are a lot of fun for people. It's a straight to the point system that teaches algorithms and other fundamentals in self-contained brain teasers that are straight to the point. And it's trivially easy to Google for supporting training material. In my experience, the same people who are self-motivated enough to build web pages and games are frequently also interested in Leetcode style brain teasers.

People aren't choosing between one or the other. That's a false dichotomy. All of the highly driven students I've worked with have a range of experience from toy projects to Leetcode style learning challenges.

<comment><USER9> > Leetcode style systems are a lot of fun for people.

That's not true for everyone, especially in such high stress situations as an interview. I like crosswords, but I wouldn't want to do them in front of someone judging me for a job in 45 min while thinking aloud.

<comment><USER10> All job interviews are stressful. Are you just scapegoating whiteboarding?

<comment><USER9> Not scapegoating anything, nor do I think it's reasonable to expect interviews are not stressful.

</comment></comment></comment></comment></comment><comment><USER11> I've mentioned this before.

I have a portfolio that consists of six figures LoC of code, across dozens of open-source repos; most of which I am the 100% sole author.

I've written a fairly large open-source system that is rapidly becoming the world standard for a specific (rather small) demographic. It deliberately uses old and rather primitive technology (which is a big reason for it becoming a standard).

I've written hundreds and hundreds (probably thousands) of pages of documentation and Web site entries, designed Web sites, and helped hundreds of people and organizations to develop online presence (all for free). I've run instructional courses on a number of different topics.

I speak Swift without an accent. I can write ship-ready applications for every Apple operating system. I've been writing shipping software for over thirty years.

I'm good with device control. I've written embedded operating systems (long ago -different beast from today's).

And, of course, I can PROVE it. It's all out there.

And no one bothers to look at my portfolio when I've been contacted to apply for engineering positions. I usually send a couple of links to repos and/or blog entries that apply directly to the position. My portfolio leaves absolutely no question at all about what I can and can't do, technically.

I once even had someone insinuate that I had somehow faked my portfolio. I'm not exactly sure how they thought I did it. Maybe I hired an Indian shop to write tens of thousands of lines of code, hundreds of blog entries, design multiple Web sites, and hack GitHub and BitBucket to fake a decade of commit history.

At least, that was the reason they gave for ignoring the links I sent, and instead, giving a binary tree "Draw Spunky" test (I don't do well on them; never have, never will. I spend exactly 0.0 hours on HackerRank, practicing).

I stopped trying to look for work. I don't need it, and I was getting tired of the grind.

I just set up my own gig, where I do the stuff I want to do. Maybe someone will want to work with me in the future; maybe not.

I don't really care, and I'm quite happy.

<comment><USER12> > no one bothers to look at my portfolio [...] I usually send a couple of > links [...] My portfolio leaves absolutely no question at all about what I > can and can't do, technically.

I hear this a lot from software engineers, but it might be worth thinking about the underlying expectation that anyone should spend time poking through repos on the internet, why they would, and how hard it might be to standardize a hiring process that compares you to other candidates. Contrast your own opinion of HackerRank with the hope that hiring managers, who perhaps often don't have the time, interest, or even ability to read someone's portfolio to determine the quality of the code.

As someone who's done a lot of hiring, I often glance at an online portfolio briefly, but I find it to be a low-quality signal for whether I will want to hire the person, and even for the technical ability. If I don't know you, I can't tell from your online portfolio whether you're the sole author and/or how much you've contributed to a project. I can't easily tell if you get a lot of your code from StackOverflow, or write it yourself. I can't tell what motivates you, whether you love programming or you are hoping for a high salary.

While high technical ability is a requirement for someone I hire, it's not actually the primary requirement. What I need to know is how adaptable people are, how well they'll work in a team, how quick they are on their feet, whether they're friendly under pressure, a whole bunch of things that you can't learn from a github account. Communication, attitude, curiosity, optimism, and cooperativeness are incredibly important traits, as is technical potential vs existing technical ability. I seek out ways to hire people who can (and want to) learn quickly, regardless of current skill level.

Personally, I'm totally convinced by your comment that your technical ability is high, where you say it is. You would easily pass my entry filter and make it to an interview. But after that, I'd want to talk to you, not sit at my computer looking through your portfolio.

<comment><USER11> I've done a lot of hiring, too. I managed a team of C++ image processing engineers for 25 years. All my coding was on the side, as open-source. I did it to keep my dev chops up. That's a big reason I have such an extensive portfolio.

I learn faster, and much, _much_ more comprehensively, these days, than I ever did when I was younger (I suspect because of the vast context I got from experience). The main reason I'm doing my own thing, is because I love learning so much, and I see there's a whole world of stuff to learn.

StackOverflow is a critical tool for me, but only a reckless madman would stock a majority of their code from there. I use it to solve occasional vexing problems, from time to time, and _always_ modify the (usually tiny) snippets I may glean from it.

All the rest is mine. I've been writing original code, often far ahead of its time, since the 1980s.

I would have been happy to work for a fraction of the salary a lot of folks far less capable would have asked; simply because I love doing this, and the challenge of the job would have been the most important coefficient.

But that's water under the bridge, these days. Once I accepted things the way they are, and just started doing what I wanted, on my own, I became much happier.

<comment><USER12> You do sound like you're in a great spot, congrats! I've tried to do the same thing and haven't made it there yet. I did start my own company hoping it would turn into a lifetime of being able to always do exactly what I wanted, but it didn't end up working out that way. It was a ton of fun and a ton of work, and I had to sell it and take a job so I could feed my family.

Would love to hear a little about how you're making ends meet and still doing what you want on your own. Are you selling software, doing contract work, making money some other way and doing software on the side...?

<comment><USER11> Not especially a _great_ spot; an acceptable one. I have enough invested and working for me that I don't _need_ to work again, but I won't be flying in my private jet anytime soon.

I also have two corporations, one with restrictions, but decent assets, and one with few assets, but a lot of flexibility.

</comment></comment></comment></comment></comment><comment><USER13> There is no other sane and effective way to filter the insane amount of FAANG applicants, only DS&A.

Other non FAANG/Unicorns that don't pay as well as FAANG can drop the practice of asking DS&A questions. But for those companies that pay really really well, there will be insane amount of people that are willing to get a job there, and DS&A is a "May the strongest win" filter (although luck play a very strong role as well, yes there are stories where a junior job applicant get 4 Hard Leetcode out of 5 questions). I happily oblige. I happily will get through 1000 Leetcode and roll the dice (apply multiple times) if I need to in order to get that salary. No I'm not willing to get lower salary than FAANG/Unicorns, that's why I'm doing this.

For companies that don't pay as well as FAANG, just drop your DS&A interview practice, or just lower the bar, otherwise it is a waste of time for either the companies or the applicants.

EDIT:

TL/DR. The whole answer to this DS&A debacle is only 1 thing: SALARY. End. Period. No other factor matters.

You lower the salary, no one will bother with DS&A. You increase the salary, every single person on earth and their dog will study DS&A 24/7 to get that FAANG salary. Don't believe me? Head to Leetcode forum and reddit cscareerquestions. Actually we don't even need to go that far, just look at this topic on HN every single time. It is all about SALARY. Full stop.

<comment><USER14> But there is a way to filter the amount of FAANG applicants!

It is as follows:

Offer ridiculously low pay, such that only basic expenses could be paid for, like basic housing...

Then, see who shows up.

Whoever shows up... really wants a job.

You don't hire them yet.

You implement your own corporate bootcamp, where you give then coding assignments. These start easy, but progress, over a number of weeks, to those that are similar in form and difficulty to the type of work that the corporation does...

A supervisor or group of supervisors reviews their work after every week.

People who do not meet expectations are let go.

What you're left with after that process is your new hires.

That's how you cut down on frivolous resumes.

That's how you weed out the casual job seekers from the purists.

The purists don't care about money as much as working with the right people.

It's not for everybody.

People who need salaries obviously, beyond the most basic of living expenses, would be unable to apply...

<comment><USER13> Sorry, this won't work. 1\. Too arduous for the FAANG company 2\. If the end result is $250k/year salary, then absolutely insane amount of people will stick it until the end. I know I do. Heck, I will live at FAANG office 24/7/365 if I need to, and I know a lot of people will do it. See the current state of Leetcode forum and reddit CS career questions to get the feel of the type A people who flock there. It is go big or go home. Bleed and get up again.

Hypothetical scenario, tell the startups/VCs to pay more for software engineers, just a little bit lower than FAANG, then two things will happen: 1\. Either FAANG will even increase their salary even more to attract type A types 2\. A huge number of applicants of varying quality will flock to CS as an industry lowering the overall quality, forcing companies to do hard DS&A questions to filter applicants.

<comment><USER14> I agree, it probably wouldn't work for the FAANG companies...

I posted what I said as a note to my future self, if/when I run a software engineering company... if/when that happens, then that's how I'm going to handle hiring...

<comment><USER15> Out of curiousity, why do you think that your intake from the `minimal salary barely enough for living expenses` job posting will contain any talented candidates at all?

<comment><USER16> They will attract _desperate_ candidates, which some companies often want. Then they carry the person on a leash.

This will differentiate companies looking for true partnership with an engineer vs those who need hamsters in a wheel.

</comment></comment></comment></comment></comment></comment><comment><USER17> Is it really that rare that companies have legitimate hiring processes and realistic interviews?

Take this with a grain of salt, because my experience may differ from many here (never worked at FAANG, I spent a lot of time at smaller startups in Boulder and am currently in Miami) but I have only been put in front of a whiteboard one time during many dozens of interviews and it was a generic logic puzzle to see how I performed under pressure.

Having been on both sides of the hiring table now many times, there is only one approach that makes sense to me:

1\. Speak to them over the phone to make sure they are decent human being, verify again in person.

2\. Be upfront with general compensation ability and expectations so that neither of you waste the others time.

3\. Do a pair-programming exercise where they build a small piece of software that mirrors something that would be working on as a day-to-day there. Make it clear that finishing is not important, you just want to see their thought process and how they communicate. Ask them to refactor parts of it at some point to see how coach-able they are and how they respond to criticism.

This strategy has worked exceedingly well for me, and when I was on the other end of the hiring table the companies whose process generally looked like this were great places to work with good people.

Algorithm questions are a hazing ritual, and so many junior devs get sucked into wasting hundreds of hours practicing them when they could be building real-world skills. This practice has got to stop, IMO.

[https://github.com/poteto/hiring-without- whiteboards](https://github.com/poteto/hiring-without-whiteboards)

<comment><USER8> > Is it really that rare that companies have legitimate hiring processes and > realistic interviews?

In my experience, the gap between the HN comments section and the real world is massive when it comes to hiring practices.

In the world of HN comments, most people tend to identify with the candidate rather the interviewers. The interview candidate is the hero, the underdog, and the person we're supposed to root for. The interviewers are bumbling fools, drunk on power and dead set on abusing their power to find flimsy excuses to reject candidates.

In the real world, most of the senior engineers I know have spent considerable time on both sides of the interviewing table. At different points in their career, they've been the ones asking questions as well as the ones being interviewed. This leads to a lot of cross-pollination of interview techniques as well as different perspectives on what works vs. what doesn't.

We can all agree that interviewing and hiring practices aren't perfect, but it's much harder to suggest better alternatives. At one point, I tried directly asking candidates how they'd prefer to be interviewed in a way that best highlighted their talents. A surprising number of people defaulted back to standard interview practices, but I also had a number of "just trust me when I say that you should give me this job" type answers.

These online discussions inevitably skew one way, because no one wants to be the bad guy defending the current imperfect status quo. Even the author of this article artfully dodges any request to suggest alternatives, instead falling back on the safe and secure "we have a lot of work to do" response.

<comment><USER18> > most of the senior engineers I know have spent considerable time on both > sides of the interviewing table. At different points in their career, > they've been the ones asking questions as well as the ones being > interviewed. This leads to a lot of cross-pollination of interview > techniques as well as different perspectives on what works vs. what doesn't.

I'm one of those engineers. The company I currently work at has no problem finding and hiring competent engineers. I also have no problem suggesting something better than what most companies do. And yet, whenever I interview at other companies[0], the most common interview experience I still have are the horrible ones described time and time again here.

The sort of "cross-pollination" you refer to is not widespread.

[0]: A few times a year, just to keep my feet wet.

</comment></comment></comment><comment><USER19> I don't know, hiring seems inherently broken.

Not just the algorithmic part, even the part leading up to it.

You have to impress a recruiter or an HR drone by listing all the buzzwords that are currently trendy.

Then, even after the algorithmic questions and interviews where you prove you can DO the job, you get rejected.

Every company I've worked for had trouble hiring.

I'm working for a company that also has trouble hiring right now. Last week, the person interviewing our latest candidate told me that despite the candidate doing perfectly fine, he couldn't come up with something that he felt excited about doing in his current job, which was a red flag for him.

I tried explaining that perhaps that's something you shouldn't expect from someone who's at that point switching jobs. We're still discussing how hard it is to find good people.

Most of the companies I've interviewed for also have trouble hiring, yet I've been rejected for the most asinine reasons. These companies have the same positions open years later and not due to growth.

All this rant is to say, we're mostly doing this to ourselves.

I don't have a better way of doing things, but I can't just blame a handful of big corps for this, as if their technical interviews weren't designed by technical folks themselves.

<comment><USER8> > I don't have a better way of doing things

This is my least favorite part about discussing interview techniques.

It's taboo to say anything other than "interviews are broken", as if there is some alternative perfect practice that companies are voluntarily choosing not to use.

If no one, including the author of the linked article, can think of anything better, doesn't that mean that companies are already using optimal practices? At least from our current knowledge of interviewing practices. I always have my eyes open for new research, new suggestions, and new trends, but it's getting old to hear the constant chorus of "interviewing is broken" with zero attempt to suggest improvements.

That doesn't mean current practices are perfect or that we should stop trying to improve them, of course. It does feel a bit like politicians going on record saying that they're "deeply troubled" by something without proposing alternatives, though. It's the safe thing to say.

<comment><USER20> I wonder if a sensible option might be short term contract-to-hire scenarios.

You have three promising candidates? Instead of trying to extract signal from gimmick interview tactics, hire them all and put them on a 3-month contract with the opportunity to renew to full time. Then you're giving them real weork instead of easily crammed questions, and remove some of the anxiety affecting interview performance.

<comment><USER21> That would be fine for new college graduates and other unemployed developers, not so well at attracting talent that already has steady employment.

<comment><USER22> If you have a steady job, then there may not be as much social utility in optimizing things for your situation.

</comment></comment></comment></comment></comment><comment><USER23> Glad to hear he hasn't given up. I agree with his basic thesis that much of software engineering hring is a cargo-cult shitshow. But I haven't given up hope and have worked on developing a hiring process that is human, efficient, and effective.

I've outlined it here before. Been using it and tweaking it for the last 3 or 4 years. I keep bring it up because it's a tested alternative to the usual death marches and dumpster fires and it has been a success for the teams I've led and our applicants.

The principles I've defined to guide our process[0]:

\- Hiring cycles will be structured and as short as possible.

\- When we start a hiring cycle, we will finish it by hiring the most qualified applicant who accepts our offer.

\- Every applicant will receive a response within 48 hours and be updated on the status of their application at each step asap.

\- The hiring process will be as transparent as possible.

\- Objective and fair-minded measures will displace biased and bigoted ones.

\- Every applicant will appreciate their experience, even the rejected ones.

\- The process will be agile and adapt over time to improve and meet the specific needs of the organization.

\- Onboarding will begin with hiring.

One problem I'm confronting at the moment. As our company grows, we've brought on a new HR lead who wants to jam the process we've been refining over the last couple years into a new ATS (Applicant Tracking System) that could significantly screw up our meez. We'll see how that works out. I'm doing everything in my power not to let it fall apart.

If you have the power to improve the situation, please do so.

[0] For an outline of the process, see [https://wiki.klenwell.com/view/Hiring](https://wiki.klenwell.com/view/Hiring)

<comment><USER24> How do you design your coding challenges? Can you give examples?

<comment><USER23> Sure. We start by noting in our job description that there will be a coding challenge -- on a laptop, not a whiteboard.

Most of our work is on web applications, primarily Rails. So, for that role, the challenge is to fix an issue in an implementation of Fizzbuzz on our sandbox Rails app. We give the candidate about an hour to work on it. It's not as trivial as the common Fizzbuzz exercise but it's a pretty representative sample of the kind of work we do.

As part of the phone screening, we check to make sure the candidate understands there will be a code challenge involving Rails and that they're cool with that.

There's a handout we present before we turn over the laptop that explains the issue and clearly defines requirements (e.g. create a branch with this name). We read a brief intro section then give the candidate time to review the requirements on their own and ask them if there are any questions. Candidates are reminded to read the README included with the project and encouraged to use the browser to Google stuff.

One tweak we made was to add check-in stages to the challenge to make sure candidate doesn't get stuck for a half-hour trying to open up the text editor or something. Every 15-20 minutes, a team member will check in with candidate and if they haven't hit a certain milestone (e.g. has started local server or had reproduced issue), we'll assist them in getting to it. At the second or third check-in, it usually turns into more of a pair programming exercise and at the end we'll review the solution with candidate so they understand why the problem is relevant to the job.

There's not a definitive pass or fail for the challenge. The candidate's performance gets scored on a simple 1-5 scale alongside the other competencies we're evaluating as part of the interview. We're pretty thorough about preparing the code challenge and consider it a good example of our "onboarding begins with hiring" principle.

<comment><USER25> I like the milestones/check-in idea - will have to use that next time around.

</comment></comment></comment></comment><comment><USER26> Honestly, I think until FAANG start doing something else, the vast majority of tech/semi-tech companies will just copy them. A few smaller companies might branch out and try some other stuff, but most people hiring at mid and large size companies are just trying to minimize risk more than go grab that great diamond in the rough. If the big guys are doing X, the medium guys are gonna keep doing X also.

<comment><USER27> I'm actually rather unconvinced that these interviews are positively _good_ at minimizing risk (false positives). This whole 'whiteboarding' thing has degenerated into 100% pointless trivia, with many elements of a popularity contest - I just don't see any reason why we should trust this to yield 'safe' candidates.

Even sticking to the pure 'trivia' aspect, there's just so much of it that people are missing altogether. (Sure, maybe you can write out a nifty algorithm on the whiteboard, but can you sketch even a _very_ rough proof that the algorithm is correct? I don't think many people can do anything like this. I'm not even sure that the topic of correctness comes up all that much in a CS/SE curriculum - which is surprising, since we _are_ supposed to be doing engineering. And yet, someone who _is_ familiar with what provably-correct code might look like in practice will likely be a lot more productive as a result.)

<comment><USER28> > This whole 'whiteboarding' thing has degenerated into 100% pointless trivia, > with many elements of a popularity contest - I just don't see any reason why > we should trust this to yield 'safe' candidates.

People blindly and dumbly implementing any practice is going to yield bad results. I've interviewed for Google, for a small company with a crappy pipeline and a low need for talent, and for my current job, which needs Google-level talent across multiple specialties[1]. Whiteboarding has played a critical role in all of these. The goal isn't to have them answer trivia questions in marker, it's a basic test of their ability to think critically and program. Naturally, the exact questions differ based on the role: for the second job, it was basic processing of data structures, while for the third, I got a question that involves some degree of spatial reasoning. But in general, this is a pretty fundamental way to test a pretty fundamental set of skills.

I even was lucky enough to get a negative example: I ran the tech org for the second company, which had two non-technical founders. We hired a candidate with no engineering experience on my recommendation because he did very well in his coding interview: this guy ended up being the most reliable, clutch engineer in the company. I also rejected a candidate on the basis of failing the simple whiteboard problems, and the founders decided to hire him anyway based on his years of experience. The founder ended up having to bounce him around from task to task, leaving a trail of destruction wherever he went. His code would bring production down, he'd create weeks of work for others in a couple of days, he utterly destroyed devops during his brief tenure there, etc. He was very sweet, hardworking, had a great temperament... But the inescapable fact was that he was just kinda dumb. The whiteboard interview handily caught this, _which is what it's supposed to do_, and all the HN sniveling about whiteboard interviews only being useless trivia contests doesn't erase that fact.

[1] You can imagine how hard hiring is for us right now...

<comment><USER27> > I also rejected a candidate on the basis of failing the simple whiteboard > problems

OK, but this topic is not about "simple" whiteboard problems. (People can of course disagree wrt. what's 'simple', but a rule of thumb is that anything where the average dev would _need_ to train and memorize whiteboard trivia for an extended period in order to perform satisfactorily is far from simple.)

<comment><USER28> Sure, I don't disagree that it's possible to do whiteboard interviews badly, but it's possible to do bad interviews of _any_ form. My comment is pretty explicit about the fact that I'm pushing back the popular opinion hereabouts that whiteboarding itself is useless, on the basis of these poor implementations.

</comment></comment></comment></comment></comment><comment><USER29> I have always hated software engineering interviews. This is a popular topic on this site, but nothing ever changes. Not sure as I would call them dystopian, I generally thought they were a chance for a senior dev to parade his ego. I could tell stories... (As I'm sure everybody else...)

I used to take interviews and I always knew the outcome. "Sorry you are self taught, we only want people with CS degrees." "Or you don't know how to reverse a list." "You don't know what a bubble algorithm is" Why did I keep punching myself in the face?

Well I decided to make a change in the last 6 months, I wanted off the hill, the ski lift or what ever ski metaphors your want to use. It's summer and I'm going surfing. (also we both live in Colorado, it's getting little crowded on the hill and the traffic to the slope is bad.)

I changed my attack, why was I interviewing for these horrible jobs that I really didn't want anyway. So I changed my pitch.

I now write algorithms for futures/stocks/options, I work for a company that have a ownership stake in. My code is good, but it might not perfect. No ego or code reviews. Because the true worth of my code is not how many classes I use it whether it returns profits. I didn't get into coding to so I could debate OOP structure or MVC models. I write code so I can make a ridiculous amount of money. Nothing more or nothing less. The code is just means to make more money.

Enjoy the lift ride, but I'm going to Hawaii.

<comment><USER30> Can you explain more? How did you find a trading company that hires non formally trained devs? They seem to be the type to only look at Harvard grads etc.

<comment><USER29> So what I didn't mention in my response for the sake of brevity. I have an MBA in finance and a register investment advisor. With out going into a lot of detail... I became a programmer/coder in 2010-2011 because having an MBA didn't really help your job prospects back then. For some reason stepping away from my financial knowledge and some life events that alter my career path.

About a year or so I decided it was time to get back to my financial knowledge of markets and my ability to program. I need to get out of the trap of a dead end programming job. (I was working in Drupal 8... it doesn't get any worse) I already had one stock algorithm so I started working on an options algo. Then via the internet I ran across a family office that needed assistance with a futures algo. I'm luckily because I have strong academic understanding of financial markets and the ability to build algo and write code to api's.

</comment></comment></comment><comment><USER31> I think that "apparently very few people actually know how to program a computer" part is more about how many people have "fake it till you make it" attitude or how large ego they have. Or how much they dont bother how they look like during interview and keep trying until they get lucky scoring position. And that _actually is_ how many get to start programming. As in, one of common advice is to be self-learner and absent reasonable guidelines on when you know enough, you get a lot of these - and few people who learn enough to get junior position and are lucky enough to find company that happen to have junior positions.

We tend to praise people who take the risk, fake it till they make it are go getters etc. And possibly these are trying for that.

And maybe it would be pretty cool to see a sociological study about who these people are. What demographic they belong to, what background they have, what kind of personalities and value they have.

<comment><USER32> It doesn't seem to be all fakers. The situation as described by advocates of FizzBuzz and the like, is that large minority proportions of people who have already held down jobs in the software development field, actually can barely do things that we think of as basic programming, like implement a very straightforward function. The implication seems to be that there's just too many to all be actual liars; that they're doing some kind of cargo-cult, cut- and-paste, stack-overflow based work to keep themselves in a job, changing things by tweaking them but not actually capable of anything else.

It seems implausible. It's counter-intuitive. But the idea seems pretty persistent.

It's an interesting question for me personally. I'm a mechanical engineer who likes to program a little and I've sometimes wondered whether I could work as a programmer. I haven't got the right qualifications or experience with enough popular technologies, so moving fields would be tough. But I know I can implement basic things from scratch. It doesn't seem like much (and clearly it wouldn't be enough for the prestigious places with really tough computer science interviews) but it would be interesting to know if that actually was enough to clear a certain low bar of competence.

<comment><USER28> > It seems implausible. It's counter-intuitive. But the idea seems pretty > persistent.

Some of us have direct experience with exactly this situation (see my previous comment). Hell, Jeff Atwood wrote a whole piece on it a long time ago.

<comment><USER33> As a programmer who is for-sure well past "fizzbuzz" quality and has been for a while now, I can just about guarantee I've left interviewers with the impression they dodged a can't-actually-program bullet when they rejected me, a couple times.

<comment><USER31> How it happened?

<comment><USER33> I tend to basically forget how to use a computer when people are watching. To prep for interviewing I also have to try to memorize a bunch of stuff about some relevant language because otherwise, without surrounding stuff to crib from, I'll straight-up forget basic shit about it, and that doesn't always stick. I'm talking like "what does method invocation look like in this language?" Under pressure it can and does happen for languages I've been working in 5 days a week for the last year. And I guaranfuckingtee if I write more than a few lines I'll end up using the wrong name for some standard library function I don't use daily—again, I drill these around interview time just in case, but it doesn't always stick. I'll also get really timid about using editor features, if I'm using a real computer and not whiteboarding, because I start second guessing every keystroke.

Further, most interviews I encounter _don 't_ do this and the ones that do tend to be all goddamn cagey about what to expect so I never know in advance, so I don't have a home whiteboard to spend hours and hours practicing on and if I did I wouldn't know which interviews need such prep and which don't so I'd probably end up not bothering, since it's just a few that do it.

I don't even have significant social anxiety or anything, and I have been told I come off as very confident and competent—unless the whiteboarding algo shit comes out, at which point there's a 50/50 chance I'll look like a total dunce (Nb. I can and do get The Actual Work done, no problem, once hired—that part's easy)

Since I only interview every few years and, again, this problem hasn't stopped me from landing jobs at about the same pay rate as the other ones that rake me over the coals (though not FAANG or near it) I've not spent the significant time it'd take to fix this. We'd be talking _lots_ of hours to prep for FAANG tier, and probably a year. Don't care enough to do that. I did spend the time & effort to improve how I come off in more conversational parts, gradually, over the years, but that was relatively easy and doesn't rust as fast (since, you know, _I don 't get to practice interview-type coding on the job_, but I do frequently have opportunities to practice relating to people).

[EDIT] I don't mean to be whiny or call the grapes sour—I simply haven't put the work in to (as I posted elsewhere in the thread) turn my efforts at leetcode from _practice_ to _performance_. And again, for the roles I'm applying for I'm not losing any money by occasionally being rejected because they decided to give me a puzzle expecting a recursive & memoized (DP) solution rather than ask me whether I know WTF recursion and DP are and when they're usually useful, so the worst they do is waste a day of my time (honestly, why the hell are places so secretive about what's going to happen on interview day? Fucking Google's not, Jim Bob's Software Widget factory can afford to tell applicants the _sorts of things_ they'll be talking about and the kinds of exercises that may come up)

<comment><USER34> This is a really common experience. Work samples were supposed to be the answer to this, though I've had really awful experiences with work-sample companies.

<comment><USER33> Luckily I've also been doing this long enough that for every one that asks for a project or wants me to live-code, there are two that chat with me for 2-4 hours and come away eager as hell to get an offer to me before I accept one somewhere else, so it's not _that_ big a deal. I mostly just wish places were more transparent about this stuff so if they're gonna whiteboard me I could either put in some targeted prep work so I (maybe) don't look like an idiot, or else say "thanks but no thanks" and save us both some time if I can't or don't want to cram that week.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> This is surprisingly better than the usual "You won't believe what happened after my article got on Hacker News" post (yes, that's a genre) so I'm going to put it in the second-chance pool [1] after turning the knob down on the title.

[1] described at [https://news.ycombinator.com/item?id=11662380](https://news.ycombinator.com/item?id=11662380) if you don't recognize the term

<comment><USER36> Interesting post for sure. Glad it got a second chance.

Speaking of the second chance, from the link you referenced [https://news.ycombinator.com/item?id=11662380](https://news.ycombinator.com/item?id=11662380)

In that comment you said

> I want to turn this system into something that's open to all users who want > to take time to review stories. We'll make it a form of community service > that will be a new way to earn karma. However, it's still an open question > how to pull this off without simply recreating the current upvoting system > under another guise.

Have you guys looked or thought about this any more since then? I'd love to see such a community service become reality.

<comment><USER35> Still thinking about it, still want to, haven't worked on it yet, will at some point.

Edit: if anyone wants to be a story reviewer, find 3 submissions that got posted to HN but didn't get attention, which you think the community might like and which gratify intellectual curiosity (i.e. aren't interesting just for sensational reasons). Oh, and which you're not personally connected to. Then email them to us at firstname.lastname@example.com.

For examples, you can see a partial list of stories that were picked in this way here: [https://news.ycombinator.com/invited](https://news.ycombinator.com/invited). Those are ones where we invited a repost because the original submission was too old to re-up, but the criteria are the same. We'll publish the full list at some point.

</comment></comment></comment><comment><USER37> I've personally seen no correlation between people who can solve problems and program when watched by another person versus people who can solve problems and program when left alone with a real problem, and ample of time to noodle on and resolve it on their own.

The same is true for writers: most are likely not to be interested and/or able to do their best work when watched over the shoulder by another person.

The /real/ question is this: should software be like a factory job? If so, let's clearly acknowledge it and define it, so that people can set their expectations and self-select accordingly.

<comment><USER8> > I've personally seen no correlation between people who can solve problems > and program when watched by another person versus people who can solve > problems and program when left alone with a real problem, and ample of time > to noodle on and resolve it on their own.

At most of my companies, we tried moving exclusively to take-home interview problems for this reason. Short problems that could be solved in 2-4 hours of time, as benchmarked against current employees during daytime hours.

Inevitably, some candidates hated this so vocally that they'd ghost us, or some times even take to social media to lambaste us for trying to take away from their free time. Or we had people refusing to do the toy problem (not real work, same test for all candidates) unless we paid them hundreds of dollars to compensate their time.

It didn't matter how much we tried to explain that the entire purpose of the take-home problem was to grant flexibility to the candidate. A large number of candidates vocally hated any interview technique that didn't involve company employees giving 1:1 interview time to them.

We just filtered those candidates out of the pipeline, but I walked away with a clear understanding that interview practices will never make everyone happy.

<comment><USER38> > _Or we had people refusing to do the toy problem (not real work, same test > for all candidates) unless we paid them hundreds of dollars to compensate > their time._

It's otherwise billable time, don't see why you'd have a hard time respecting that from a candidate.

<comment><USER39> > " _It 's otherwise billable time, don't see why you'd have a hard time > respecting that from a candidate._"

Sure, as long as the business gets to deduct the cost of the interviewers' time from that. Not gonna work out in favor of the candidate but respect is a two-way street.

After all, once the candidate (or a candidate, anyway) joins the team, it's their billable time being spent reviewing and interviewing other candidates too.

<comment><USER38> > _Sure, as long as the business gets to deduct the cost of the interviewers ' > time from that._

They can at tax time, whereas an employee can't. If an employer requests work from someone, they should pay them.

</comment></comment></comment></comment></comment><comment><USER40> HOW IN THE WORLD is this guy unemployed?!

(A: Well, he won't be much longer!)

He writes extremely well. He summarizes a great deal of feedback and knowledge really well. I don't care if he can code -- though evidently he can. Who would pass him up??

Granted, there's the question of whether he fits any particular job opening. But still, there must be many job offerings out there that he could fill if only the people doing the hiring could see that he's got something very special going on.

If you work in a team, in a large company, you need great communications skills almost more than anything else. He's got that down pat.

Jared Nelsen is going places. Ten years from now, when I see his name in the news, I'll enjoy knowing that I saw this a decade earlier.

</comment><comment><USER41> The "hopeless list", no. 3:

"If you run into an asshole in the morning, you ran into an asshole. If you run into assholes all day, you're the asshole."

This pretty much sums up my impression of these hiring managers that crank the bar sky-high: they are assholes through-and-through, and are full of shit to boot.

If you crank the bar sky-high, all you will get are two kinds of people: those that interview/test well, but fail at the job, or those who can do both but will put a crater a mile wide into your payroll due to their high demand garnering an equally high paycheque.

Anyone who isn't quite at nosebleed levels of competency can grow into their roles and skill sets. Yes, they won't be able to hit the ground running, and yes, they will have a higher than comfortable drag-to-thrust ratio, BUT THAT CLEARS UP IN TIME, WITH SUFFICIENT GUIDANCE AND MENTORSHIP.

<comment><USER42> But while they are getting guidance and mentorship, they are not being a productive member of the team, taking time away from experienced developers and as soon as they level up they will change companies and the next company didn't have to invest training time.

I know everyone has to start somewhere but from the company's perspective, hiring a junior developer doesn't make sense.

<comment><USER43> In my experience a great way to hire and train juniors is to have them do tasks that need to be done but you can't over allocate or reallocate an existing engineer for it. Like refactoring existing code.

Why? The only guidance then a more senior engineer would need to give is during code review and where they may have questions. It's a great way to get them familiar with the code base and train them up. I haven't seen this be a productivity killer.

Also, with the shocking frequency I've seen, code based need more tests. Have them write tests! That's a fast way to get up to speed.

One other point: senior engineers in one code base may have an uptick if a "junior" in another depending on existing quality, circumstances etc.

I think organizations are lying to themselves that they can only hire seniors. It's a myth. Just like 10x developers.

I need hard data to be convinced otherwise not anecdotal evidence. All the hard data I've seen points in the opposite direction of any anecdotal information I've come across.

There are so many volumes of books devoted to these topics alone that I think most ideas around developer productivity without the firm backing of numbers are mostly hand wavy and myths we tell our selves to feel better

<comment><USER42> How would a junior no what to refactor and not make it worse? In my experience it's harder to refactor existing code than to start with green field development.

<comment><USER43> You give them tasks with frames of reference. Not all refactored are monsters. It does require some guidance though that's kind of the point.

These are just some things I've been apart of. I've gladly been apart of this before.

You can as I said also have them write tests or as others noted have them write smaller features or other things in isolation.

Also how green are we talking is another question entirely. Some tasks are better fit for people with maybe practical experience in another tech stack but need to get up to speed in a new language etc.

My overall point which may not have been clear is that there is always a way to get an engineer up to speed without killing velocity. It's a management failure to say you can't hire junior engineers.

It's one thing to need someone that's a domain expert, but often I see "senior engineer" === "No ramp time" and I think that's just a lie management tells themselves to justify not coming up with a good on-ramp plan for new engineers

</comment></comment></comment></comment></comment><comment><USER44> Honestly having an interview process that is highly standardized and teachable + learnable is a good thing, so I'm not sure why people complain. You know exactly what sort of questions you will be asked from company to company, and can spend nights and weekends over a couple weeks studying for it.

Most jobs are not like that, and then you get extreme variance in expectation with little communication on how to prepare, which is a waste of time for both the interviewer and interviewee if the interviewee has no clue what will be asked or expected ahead of time.

<comment><USER45> The problem is twofold:

1\. False positives: you get folks who do really well at DS&A yet who are really bad developers. I mean _really_ bad. I wouldn't have believed it if I had not seen their interviews and then subsequent performance. I'd wildly guess that it's about 20-30%.

2\. False negatives: you get folks who are really good developers, and yet for whatever reason, perform badly on DS&A algorithms despite practicing. I think this number is higher than false positives, probably around 50% or more.

If you're a FAANG company, you can afford to play these odds. If you're not FAANG, then you're killing yourself by requiring DS&A interviews, almost inevitably.

Both are contributing to destroying the profession for huge numbers of people, IMHO. I mean, that's good for me, because I'm almost certainly sticking around and generally do OK on DS&A interviews with adequate practice (which is a waste of time, since anything beyond a broad knowledge of the performance characteristics of various DS&As is totally unneeded for 99% of us). But it's not right, and I really don't like it.

<comment><USER13> Where did you get all of your numbers? My experience dictate otherwise. Plenty of people who don't know DS&A and are bad coders, and call themselves senior.

</comment></comment></comment><comment><USER46> When I interviewed at Google for a front end position they didn't ask me a single CSS question. It was all algorithms and easy JavaScript questions. It was just really weird, like at least ask me how to center something. They bothered to ask me how I'd deal with diversity issues if I was in HR, though. I probably didn't get the job because of my answers there...

<comment><USER47> > They bothered to ask me how I'd deal with diversity issues if I was in HR, > though. I probably didn't get the job because of my answers there...

Strange postscript that suggests you hold some problematic opinions that indicate you can't play nicely with others?

Did you fail to get the job because you didn't have the tech chops or is it because you said something wildly inappropriate on the behavioural questions?

What did you say?

<comment><USER48> This kind of question _can_ be heard as a dogwhistle for

"Are you a leftist? We only hire leftists."

<comment><USER47> That's true, in our industry it seems that only leftists aren't assholes.

So if you don't want to hire assholes who think "diversity" is a dog whistle, you hire leftists.

<comment><USER48> You seem real inclusive :)

<comment><USER47> [https://en.wikipedia.org/wiki/Paradox_of_tolerance](https://en.wikipedia.org/wiki/Paradox_of_tolerance)

Inclusivity does not mean having to include those that would exclude others.

<comment><USER48> I don't mind excluding the odd violent extremist.

But if you exclude all non leftists, that's about 2/3 of all Americans. And that looks very tribal to the rest of us.

The mandatory brilliant essay on this: [https://slatestarcodex.com/2014/09/30/i-can-tolerate- anythin...](https://slatestarcodex.com/2014/09/30/i-can-tolerate-anything- except-the-outgroup/)

<comment><USER47> How much of that 2/3 is college educated in the software industry, and is technically competent enough to pass the bar at Google?

But that's being overly provocative.

Ultimately this started with you saying that a question about diversity could be heard by some as a dog whistle that only leftists are welcome.

I simply don't agree with that premise. I do think there is a percentage of people who think diversity is a left-only issue, but I don't think that's 2/3rd of Americans. Then again, Donald Trump hovers around 50% approval rating regardless of what he does, so maybe I have too high an opinion of Americans.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER49> I wonder how much lost productivity exists in the industry of people who could be spending their time working on side businesses, or actual work, and are instead grinding leetcode. I've caught numerous coworkers grinding LC and working through problems with each other, at work. While obviously unethical, it's gotten to the point where to get a job, you need to be studying 6 months out and spend significant time to do so. To the point where you feel so much pressure that you cut into work and other time to get there.

This is almost certainly to the detriment of employers.

I think if employers understood the true cost of their actions, they might radically change the interview process. Everyone wants the best talent, until you consider that your talent is actively studying to become someone else's "best talent".

</comment><comment><USER50> I think one of the major takeaways here is, _stop asking algorithm questions_ [1]. Everyone. Just stop it.

In my opinion, and modest experience (I've done several dozen interviews, so there are plenty more experienced then me, but I'm at least not new, plus nearly all interviews were for my team so I had to live with the results!) it isn't _that_ hard to come up with small sample questions related to what the job actually is doing. From there, in addition to the mere fact of whether or not they were able to complete the task, you can learn about how they did it, look at their practices, stop them for a moment and discuss the implications of something they just did. You can add a wrinkle to the task ("what about unicode?" "what about cross-site scripting vulnerabilities?"). I also find being this kind of flexible, rather than being stuck on "did they solve this algorithm challenge in the _proper_ manner" also gives me room to be human, to take a moment to try to calm the candidate down in what is inevitably a stressful situation for them (even if it's basically just Tuesday afternoon for me in my current position in the world). I think of an interview as "I want to find all the positive I can", rather than as a process of locating all flaws, and you can't do that if your candidate is frozen in the headlights the whole time.

Interviewees are pouring forth a wealth of information. The idea that the only way to find out how good they are is by asking this one narrow set of questions is absurd.

And the interview _ers_ are pouring forth a wealth of information too. Consider what message you're sending with a rigid adherence to something we _all_ know is broken.

[1]: Unless it _really is_ relevant to the job! I expect that if I'm hiring a senior level machine learning _researcher_ that you better be able to describe gradient descent to me, for instance. We may not implement it literally in the interview but I have a reasonably case for saying the researcher ought to convince me they could get there. But in a lot of cases, what's more relevant to me is that you know the _characteristics_ of algorithms rather than exactly what they are. You can know the runtime and weaknesses of quicksort or RAFT consensus even if you can't spew the actual algorithms on to a board.

Actually, my parenthetical here almost makes me want to rewrite this whole post, although this thought is still fresh and I'm still chewing on it. Is that perhaps the error we are making? Are we conflating _knowing_ the algorithms for knowing the _characteristics_ of the algorithms? The latter is legitimately important and I see screwups based on failing to understand _characteristics_ of algorithms all the time. Knowing the literal, actual algorithm to the point that you could simply open up a terminal and bash it out yourself is rarely important in this era.

<comment><USER51> Full disclosure: I work for Google and like it

I left Google in 2009, quite unhappy about the difference between a startup and corporate politics. After that I worked at 3 startups (5 years), 1 telco (1 year) and at McKinsey (3 years).

I ended up interviewing at Google again in 2018, after deciding that a) I liked programming more than management consulting and b) my comparative advantage was in programming. I definitely could have felt entitled after 1) passing Google interviews once before, 2) having had three somewhat successful startups and 3) proving I can also handle the corporate side.

I was asked multiple questions that could be interpreted as 'algorithmic' (and I have to admit that after 3 years of not coding I was nervous about them). However, they can also be interpreted differently, more charitably. They all followed the structure of: 1) give a reasonable but not completely defined problem - you should be able to clarify enough of this to show you can deal with some ambiguity; 2) turn that into an algorithm - you should be able to articulate an easy algorithm and be able to discuss improvements to it; 3) turn your algorithm into code - you need to show you can actually program. I definitely didn't have to memorize and regurgitate textbook solutions.

I acknowledge that a) the above may optimize for rejecting all negatives at the cost of some false positives and b) it's still a very basic lower bar and doesn't predict who will perform highly vs. ok. However, I did think it tested for the core skills I expect from programmers.

I've also set up interviewing processes at startups. I did end up emphasizing ownership and 'getting things done' more than Google does. I do think startups should test for different attributes than 100k+ FTE corporations.

<comment><USER52> You missed a big one - giving them an idea of how you approach a problem and work through it. That's the biggest take away.

If someone just spits out an optimal solution straight away that's not actually a great sign. It doesn't matter if you struggle a little, or need a few hints, but showing you know how to break a problem down into smaller sub- problems and work your way up is an invaluable signal.

<comment><USER31> This is incomprehensible for me. If someone happen to see your question before it is bad sign? And also, what exactly about my internal process are people trying to learn from "how I approach a problem and work through it"?

I think I tend to make good impression on these ... but I am aware it is interview skill where I somehow picked up social signals I am supposed to send. I am adjusting what I am saying to how interviewer looks like (happy, annoyed, bored, etc). It is social skill, but not same social skill as pretty much anything I do in actual work. In actual work, people are not interested to listen to me work out problems in front of them.

It is even more useless if you know the answer and then proceed pretend to split it into smaller problems and then work your way up or down. That neat thought process is neat precisely because I know the answer and I am performing idealized problem solving process.

In case of actual real problem, you don't do that so nicely. You have at least some bad turns, random guesses, break it multiple times badly and so on.

<comment><USER52> I've been in interviews where I've seen the problem before, and know the solution. I've always said so if that happens and the interviewer either continues and delves into why it's an optimal solution, or switches to a different question.

</comment></comment></comment></comment></comment><comment><USER53> Whether you like leetcode interviews or not, can we all please agree on one thing: no more writing code on anything but a computer.

I think this really explains much of the mystery of the 20 years of experience engineer who can't pass fizzbuzz. Writing code on paper/whiteboard is completely different from a text editor.

Just think about how you write code. You write a few lines. Run it in your head. Notice a mistake, add a newline, remove some brackets and it's all good. Oh wait, you just noticed this can be simplified. Ctrl-A delete all, reduce entire 20 line function into 5 lines.

None of this is possible on paper/whiteboard, especially in a timed interview setting. Paper/whiteboard is effectively immutable. You get one chance to write it down correctly and that's it. There's just no time and it's too difficult to even add a newline somewhere.

So you put a 20 year programming veteran in front of the whiteboard and they can't do fizzbuzz because writing code like that is so foreign to what they do. They can't just write something and fine tune it, which is how software is written. It must be perfect on the first try. they freeze up and fail.

There is zero excuse for companies to not give a laptop for interview coding. Even if it's Linux boot CD with nothing but vim and nano, that's still so much better than whiteboards. And these days companies use hackerrank during the phone screen. Just use the same website on a chromebook during the onsite!

Writing code on whiteboard is just really stupid. Can we all agree on this at least?

</comment><comment><USER54> I never ask, few exceptions aside, any challenges from the developers I interview.

When hiring 40+ people for a neo-bank, I did what you should have experienced: listen to people and get to know them.

The key point of success in a team is of course their skill set, but also the potential synergy.

Lots of developers are very bad if not terrible at presenting themselves, be it on a résumé or during an interview. And this has no relation to their actual skills.

So I always try as hard as I can to actually extract information from them.

First, I let them feel at ease, telling them that this is not a challenge but a time to get to know each other (which is actually true).

Then I ask a lot of questions about their experience, both in the technical sense, but also human one.

I try as much as possible to understand how they think and feel, what do they value, aspire to, try to achieve by joining the company.

I'm not a hiring manager but a 15+ yrs of experience developer. Yet, I find that hiring developers by actually being one goes much smoother than when you're not.

Last but not least, I think that this crazed interviews are becoming more and more common practice because developers agree to pass them.

If you want to change this, then don't go through them. There are thousands of other great companies that do no torture their candidates.

</comment><comment><USER55> > Not a single person out of several thousand emails and messages came out in > defense of the current state of interviewing processes

I thought I was defending it: [https://news.ycombinator.com/item?id=22332336](https://news.ycombinator.com/item?id=22332336)

</comment><comment><USER56> Hiring is broken, but so is all of software as a profession:

1) Terrible Algorithmic interviews, AI-based evaluations, whiteboard coding.

2) Hey you are hired! Now move to $BigCity, with expensive real estate, schools, transit and everything else.

3) So, welcome to the job. You'll be maintaining this shitty old python 2.4 CRUD app that multiple people have tried and failed to upgrade. And one of the web guys wrote his own UI framework for it, kinda based on Backbone but with a lot of custom stuff. Yeah he doesn't work here anymore. Anyway that part is in coffeescript, no we can't change that, too expensive to rewrite.

4) But don't mind that, because you'll spend half of your time in Agile meetings! How are you with story point estimation?

5) Hmm also we're behind on the schedule. You don't have a problem with 10-12 hour days right? And no we can't cut back on the Agile meetings, that would hurt productivity.

6) Open floor plan! We think this will help productivity a lot. But sorry, no noise cancelling headphones, that will hurt interactions. Also the VCs love it when they tour. Nothing like butts in seats.

7) Here are some options! But they are probably worthless, because we'll never be successful. Even if we are, we probably won't go public. Even if we go public, your share is probably worthless because of preferred shares and liquidation preference. Oh yeah, there is a 4 year vesting schedule and its ridiculously expensive to buy the vested shares if you leave the company, which is of course intentional since we don't want people doing that. Anyway maybe you'll make enough money for a new car, eventually. Imagine commuting in some sweet new wheels, 5 years from now!

8) Sorry, only a 1% raise this year. Health insurance costs and all that. But if you like, goto step 1 with a new employer to try to get a real raise.

9) Yes we are aware that the expense ratios on the 401K are 2%, and you are only allowed to invest in target retirement 20(fn($YourAge)). Indeed that sucks, for you.

10) By the way you only have maybe 10-15 years of useful programming life before age discrimination kicks in. So you better get crackin'

<comment><USER28> I hate to break it to you, but I think you've just worked at shitty companies? If you think that other fields don't have the same or worse issues, you're dreaming.

<comment><USER5> Or you've been very lucky. When I was consulting I visited a lot of companies. There were only a couple that didn't suffer from at least half of those problems.

</comment></comment></comment><comment><USER57> There's significant ladder pulling. Tons of engineers work at places with interview processes they could never pass.

<comment><USER8> > There's significant ladder pulling. Tons of engineers work at places with > interview processes they could never pass.

One person's "ladder pulling" is another person's "raising the bar".

Over time, companies should continue to raise the bar for both candidates and existing employees. As your company grows, you can and should become better at attracting more talented and ambitious employees. You tend to have more resources to compensate new hires better, allowing for more selective hiring practices. Growth means you've learned how to more effectively identify the best candidates.

Companies aren't being vindictive or selfish. If they can't hire enough people, they'll dwindle and die. The bar should be set just low enough to keep enough talent coming in the door, but no lower.

Companies aren't obligated to hire talent at the same levels they did in the past. It's not ladder pulling, it's just business.

<comment><USER57> There's a pretty low ceiling on engineering talent, and an even lower ceiling on that talent being an important differentiator for your company. If that's your goal, then it's not hard to see how companies just keep ratcheting up the difficulty with little to negative gains.

</comment></comment></comment><comment><USER58> _Not a single person out of several thousand emails and messages came out in defense of the current state of interviewing processes_

That's largely due to the position taken up in "The dystopian world of software engineering interviews". Had the article been a defense of current interview practices, you would have received sentiments to the opposite effect.

Here's a comment on the original thread doing what you said "not a single person" has done: [https://news.ycombinator.com/item?id=22332023](https://news.ycombinator.com/item?id=22332023)

<comment><USER8> > Not a single person out of several thousand emails and messages came out in > defense of the current state of interviewing processes

I agree that this was a cheap shot from the author.

The current zeitgeist of hiring practices is that we're all obligated to chant "interviews are broken" without ever suggesting alternatives. Suggesting alternatives is dangerous because someone, somewhere will come up with a reason why your suggested practice is bad. Even the author of the article avoids suggesting any alternatives.

It's the equivalent of politicians saying that they're "deeply troubled" by something, and then proceeding to do nothing because they are secretly okay with the status quo.

No one is dumb enough to go out of their way to publicly argue in favor of the current hiring practices in this atmosphere. Yet when we're put in the hot seat on a hiring committee, we all fall back on the tried and true methods of interviewing for a reason.

<comment><USER22> "we're all obligated to chant "interviews are broken" without ever suggesting alternatives"

Nah, there's somebody who hates everything, but there are plenty of things that _somebody_ likes. I'd be happy with both take-home problems at a moderate effort level, and Fermi problems. Clearly many people go out of their way to declaim how much they hate those things, and I don't know where to find companies that hire based on them and pay a lot, but it would make me happy.

</comment></comment></comment><comment><USER59> I'm just a QA but it makes me wonder if perhaps part of it is because software engineering is so young that we don't really know what a good software engineer should be. Or perhaps it's more that we're still trying to figure it out. Compare it to civil engineering or medicine that has had centuries if not millennia of accumulated knowledge, and who's principles haven't changed much since over time. The Hippocratic oath for instance is nearly 2300 years old and yet is still foundational to modern medical ethos. Computers have been around for the last 50 years, in every day use in the last 30. Barely a turn of the head in terms of length of human history.

I wonder if then at some point we see computer engineering becoming more standardized like the others, with a bar that someone must meet before they are able to call themselves a computer engineer with all of the responsibility that entails. I wouldn't say that it should restrict someone from programming professionally without this accreditation, but rather it would be a symbol of proof that someone has at least been judged by their peers to be at a given level of skill and knowledge. What this would look like ultimately or whether it would come to pass, I haven't the foggiest idea though. Like I said, I'm just a QA guy, not an SE.

<comment><USER31> I am pretty sure principles of medicine and engineering changed a lot over years. Even Hippocratic oath does not have all that much in common with ethical expectations in medicine. Most of what is in not is not expected anymore and most of current medical ethos is not in it.

No doctor is expected to share money with his teachers nor is expected to teach sons of his teachers. Abortion is allowed and lately euthanasia too. Current doctors can perform operations and are not required to treat all sick people.

</comment></comment><comment><USER60> This week I had a five hour on-site interview and then few days later be told they won't give a job offer because they think I will get bored within a few months at the job. Thanks for deciding for me :/

<comment><USER22> That means "overqualified"?

</comment></comment><comment><USER61> This is a great article this is _exactly_ where I am at in my life. I have almost 20 years spent at a company doing all kinds of different projects, working on many different systems, and continuing to teach myself new skills all the time on my own time. I'm currently converting a huge legacy Weblogic Java J2EE project to TomEE. I want to leave so I am now studying algorithms. I had an interview at a job I really wanted and blew one part of the technical part because I was a little unprepared. It sucks because I know I could have added value to the company because I'm a grinder and love what I do. They have a killer product that would have been awesome to work on and the people seemed great. I know algorithms are important so I will study on but it sucks in an interview one stupid question you haven't worked on will cost the job.

</comment><comment><USER18> From TFA: ""WHAT HAVE YOU DONE!?!?", my inner monologue screamed. My thoughts spiraled out of control: "YOU'VE JUST RUINED YOUR CAREER! WHY DID YOU HAVE TO COMPLAIN ABOUT IT ALL!? THEY ARE ALL GOING TO JUDGE YOU TO NO END! YOU FORGOT TO DOCUMENT THAT ONE FUNCTION YOU ARE REALLY PROUD OF IN THAT ONE GITHUB REPO AND THEY ARE ALL GOING TO SEEEEE IIIIIITTTTT!!!!""

Haha, that reminds me of the old days of Slashdot, immortalized is this early 00's webcomic:

[https://www.pyrocam.com/files/images/clanbob.dundundun.dontt...](https://www.pyrocam.com/files/images/clanbob.dundundun.dontthiefau/strip_102.jpg)

</comment><comment><USER62> > There were quite a few admissions by hiring managers at surprisingly well > known companies that the ability to pass algorithm challenges does not > correlate with success on the job.

There are a lot of anecdotes like that, but the statistics I've seen has clear correlation between performance on algorithm interviews and performance on the job. I don't think there are any public studies done on this though so if you don't work at a company where you can view it internally you just have to trust that someone has gone through the numbers at these big data-driven companies.

<comment><USER63> Well, I can say from personal experience that there are interviews when I've aced the algorithm question(s), and other interviews when I haven't. Not hugely different in time interviews, either. So I can say from personal experience that it doesn't correlate all that well with my own performance, or it would be constant.

I expect, though, that the issue is that the degree of correlation measured will depend on the population you're screening with it. If you are wanting to screen out fraudulent or otherwise utterly non-programmer persons, it will show a good correlation. However, among those who are actually programmers, it will show much less correlation, and if you're in a condition of developer scarcity, the false negatives could be more costly than the false positives.

<comment><USER62> > Well, I can say from personal experience that there are interviews when I've > aced the algorithm question(s), and other interviews when I haven't. Not > hugely different in time interviews, either. So I can say from personal > experience that it doesn't correlate all that well with my own performance, > or it would be constant.

Do you even understand what correlation means? There is a significant random element to it, yes, but that doesn't mean that there is no correlation, and the random parts from the same individual can be mitigated by doing many interviews after which you have reasonable correlation. Most interview styles has close to zero correlation, so even if we don't reach anything remotely close to 1 it is still pretty good.

Edit: About the points that it is enough to weed out people using simple problems, that isn't true either. There was significant correlation between job performance and interview performance even among those who did well. The statistics showed no signs of it capping out either, so for all we know we could make them even harder, just that there wouldn't be that many left that could pass them then.

</comment></comment></comment><comment><USER64> Shameless self-promotion: I launched hirecontributors[1] yesterday, which lets you search for people who contributed to several of the open source projects you use.

Shameless nonself-promotion: The Discord "Credentials + Meritocracy"[2]

[1] [https://hirecontributors.com](https://hirecontributors.com)

[2] [https://discordapp.com/invite/s7bGAQM](https://discordapp.com/invite/s7bGAQM)

</comment><comment><USER65> In my experience, once you have a _very_ basic sense of 'how to program', your programming skills don't matter a lot anymore. If you work in a team that underdocuments and underspecifies their project (which is practically every team ever), communication and motivation are much more important than knowing how to reverse a linked list in-place.

I have masters in two STEM degrees, which most employers seem to value at exactly nothing. They are very enthusiastic about hiring me. At the same rate they would hire someone without a degree, that is.

The thing they want, is multiple years of professional experience with a very specific set of 4-8 technologies. These are 'must-haves', and then there are probably 4-8 'nice-to-haves', which are even more exotic demands. And then companies complain 'that there are sooo little people skilled people in IT' and 'the IT people have such ridiculous demands!'. In my environment, I see people with a lot less experience make a lot more in other fields.

(This is how it goes in the Netherlands, at least.)

</comment><comment><USER66> > No Software Engineer seeks to become only somewhat proficient and stay there > for the rest of his or her career.

About 80% of them actually, roughly estimated

</comment><comment><USER67> I've worked as a SE for 8y, in 4 different countries and in both product development and consultancies.

As it had been pointed out here by most people interviewing sucks. It sucked in every country for me (some more than others). The process was superficial and usually didn't give the employer a decent picture about my skillsets nor did I get a decent picture of the company's environment/tech/culture, meaning a "we want to implement a new data analysis platform and ML on top of our web app" was only a nice attraction statement.

Both parties tend to tell some fairy tales what they think the opposite would like to hear just not to miss out on a possible opportunity. It's a bad habbit that I've done myself in the past because I don't have employees knocking on my door every day with a contract in their hands.

One of the issues is probably that a company doesn't know the person who is being interviewed. Just because someone got hired by 5 companies before and has 10y experience doesn't mean they know their stuff and therefore everyone has to go through the same tidious process again and again.

Couldn't there be an evaluation of someones problem solving skills and ability to built systems, that has a value for all (or certain years) of upcoming interviews? Lets say I take a test, that evalutates my "can solve problems" and "can built awesome cloud tech" skills and provides a certificate for it which is valid for 5y. Of course you'd also able to update your skills whenever you've learned something new!

So every company looking for a new employee searches in that pool of professionals with pre-evaluated soft and hard skills for a suitable match. Not like LinkedIn where you can claim whatever you like but rather evaluated by other professionals who will vouch for you.

</comment><comment><USER68> Criticism of interview practices is very common. However, I can't imagine that large companies that hire in the hundreds/1000s every year (say, FANG) don't have enough data to have optimized their interview practices.

These companies know in the last 10-20 years who interviewed who and the performance of everyone after hiring. With enough data you can:

\- A/B test which interview questions better predict future performance

\- how much each interviewer's feedback is correlated with future performance of the interviewee. Some interviewer's are likely terrible and they should not interview. Some interviewers at good at predicting future performance and they should interview much more if not full time.

\- which interviewer provides biased feedback (women, minorities, etc)

Either these companies are not analysing this data and the interview practices may indeed be garbage. Or FAANG companies are analysing this data and otpimizing their interview practices accordingly and the process/results are actually as fair and good as it can be.

<comment><USER62> Laszlo Bock found that interview skill is pretty homogeneous, so it doesn't really matter who does it as long as you just do enough of them. But if you do 4 algorithm interviews you have pretty good interviews.

> Four meticulously orchestrated Google interviews could identify successful > hires with 86 percent confidence, and nobody at the company—no matter how > long they had been at the company or how many candidates they had > interviewed—could do any better than the aggregated wisdom of four > interviewers.

[https://www.theatlantic.com/business/archive/2016/04/the- sci...](https://www.theatlantic.com/business/archive/2016/04/the-science-of- smart-hiring/477561/)

</comment></comment><comment><USER69> I found this a thoughtful and sure therapeutic writing. Also moving to help and to encourage!

At the same time, a great deal in this is the level of expectations about the "greats", finding the right job place at once. I believe adjusting these criteria might open up a lot more chances to get to doing the craft, be on the team, well, interview the others too.

Good luck!

</comment><comment><USER70> > I am completely depressed because I can't get a job", "I will never succeed > in this industry

I thought there was a shortage of software engineers right now? Although I just got an email from Glassdoor with estimated salary (in the Bay Area) being 5-10k lower than the last email, so who knows.

<comment><USER71> There is a shortage where I live. It has been like this for last decade.

Perhaps you should stop flocking to one location in the states and go somewhere else?

<comment><USER70> There's been a shortage in the Bay Area, too.

</comment></comment></comment><comment><USER72> I have had one good experience with a technical interview that included a challenge.

It was a two-part interview, each part lasting around one hour. First hour I just talked with a single senior developer. About previous experiences, education, interests, etc.

Second part was a "technical" challenge. I was given a loose specification of a simple fullstack web application, and then asked to produce wireframes for the frontend, an architecture drawing for the entire system, a database schema and a project plan with estimates.

There were no detailed technical questions or exercises. My answers were nowhere near perfect or realistic - but that was also not the point. The point was, they wanted to see my thought process when approaching a real software project.

</comment><comment><USER73> Why the freakishly long post.. Is there any job that doesn't have interview procedures that fail? Isn't half of the system if not more broken? Taxes, education, housing..

Why we engineers whine so much about it?

<comment><USER74> Probably because engineering partly about obsessively getting things right, and so that's the kind of personalities you have opining on this topic in these spheres.

</comment></comment><comment><USER75> My big question is whether doing a specially constructed in-person code review might be more effective than coding some challenge? You could make some sort of application with a limited size code base but various parts altered both obviously and subtly for discussion and deconstruction during an interview. And then after doing a live discussion and review of the codebase instead of coding, at the end you could discuss architecting a new feature of some of kind at a diagram and psuedocode type level. Seems potentially more pleasant.

</comment><comment><USER47> I got to the last thread too late for a comment to make a difference, but I'm exactly the person most of you want to talk to or hate.

I'm an interviewer at a FAANG company with >500 interviews in the last 5 years, I teach multiple internal courses on interviewing, and I think the system makes a lot of sense for companies at our scale.

Ask Me Anything :)

I currently have a toddler on my lap, but I'll edit this post later today to address some common criticisms and misunderstandings, but also point out which concerns I think are valid and where we should do better.

edit:

Okay, let's go through the most important points

1) I'm a Software Developer. I interview other SDEs. I ask them problem solving coding questions, algorithmic coding questions, data structure questions, and whiteboard architectural design (not at the same time, but it could be any of these)

2) Our process is REQUIRED for a company of my size. You would not believe the amount of candidates we get. We have a high bar for hiring, but fundamentally we have to be efficient with our time. That completely removes as an option superior interviewing techniques like "spend a day with the dev team working on a small real task" or "do this take home test over the weekend and then the interviewing team will review it with you". Both of these are better at uncovering good candidates than a whiteboard coding interview, but don't scale, and are themselves controversial in the industry from candidates who are unhappy of the time they require.

3) A common criticism of "algorithmic" questions (leetcode) is that they don't reflect the reality of day to day work. If a lot of people even at FAANG are working on typical 3-tier front-end-back-end-database systems, utilizing the tools and systems other employees built before, why bother evaluating if the candidates could build the next generation of such systems if asked.

Because once these people are inside the company, we'd like to think that everyone passed a similar tech bar. That means that if a new database or distributed system does need to be purpose built for a high scale system, and someone applies internally, you can be flexible with the kind of interviewing process you put an internal transfer through - you already know they passed a high technical bar, and are likely qualified to work on the hard stuff.

4) another common misconception is people underestimate the complexity of "typical" systems inside the FAANGs of the world - compared to their prior job experiences. A payment processing integration at Amazon scale is not a payment processing integration at your company's scale. An internal CRM build at Google scale is not an internal CRM build at your company's scale.

The 10,000 foot view is similar, but the expectation would be that the system would be 1/ built out faster, 2/ built out better, and 3/ scale better than a comparable project on a less technically strong company.

5) Coming back to the interview process. What that means, is that when we ask a candidate to solve a hard algorithmic problem on a whiteboard in 20 minutes, or deep dive into the inner workings of a complex data structure, or show how they could combine multiple data structures to solve one problem, we are not validating "Can this candidate write an algorithm in 20 minutes on the job at their desk"

What we're checking is "Can this candidate do something really hard, ambiguous, and time-sensitive in the Computer Science domain, when prompted to." The real life challenges will be different, but if they CAN do the first one, they'll likely be able to do the second one.

Of course we miss out on candidates who are terrible at these skills, or can't code on a whiteboard, or are overwhemled by the interview stress and can't perform. But we are willing to do that because of Point (2) above. We'd rather say no to a "maybe" candidate than hire someone who can't perform.

Despite what people state that ability with algorithmic performance on a whiteboard does not translate to on the job success, that is not my experience. Remember - I'm not looking to see if a person can spit out A* search algo on a whiteboard from memory.

I'm looking to see how they approach a problem they haven't seen before, how they break it down, what kind of assumptions they make, what ways they simplify it, how they consider ideas and tradeoffs, and finally how their ideas translate to code (fluently or not)

6) The majority of people I see cannot execute that last paragraph well enough to join a team at my company and be productive. Sorry, hackernews readers, but that's just the case. This isn't a "can't solve fizzbuzz" level of incompetence - these are good engineers who are likely stars at their smaller companies, and who can be relied upon to get the job done. But they would not thrive at a FAANG-level company because they lack some ability - <USER2> clarity/coherence of thought, or ability to understand their techncial domain in depth enough, or because they just aren't fluent at translating ideas into code.

edit2:

7) All this to say...if you're not FAANG++(Dropbox, Salesforce, etc I don't know)....stop copying us. You don't need this process.

Your company has fewer candidates, and you both can't afford to be as picky as us, and you don't NEED to.

Each of my previous companies (in the 200-500 person range) had a process of a simple coding question onsite, followed by a take home test that a decent candidate (and I don't mean decent for FAANG, I mean decent across the SDE community) could complete a reasonable solution in ~2-3 hours. We set expectations as "you could do it in a weekend" because certainly some people took closer to 8 and got hired.

<comment><USER76> I'm a former interviewer for a FAANG competitor that had a successful IPO. I had to do over 1,000 interviews in 5 years. The VP of Eng told me I was "highly accurate." We used leetcode-like programming questions.

I don't think the FAANG-style coding puzzles have anything new to add to the conversation here. The reason big companies do that is because the questions are prompts are simple to write explain (hence interviewer has to do very very little), the answer space is generally well-defined (so it's easy to grade, and easy for a Hiring Manager to check if the interviewer screws up), and they almost exclusively select for completion time (which is key in a high-pressure feature house company).

Most of the discussion here seems to be interested in alternatives. Through my experience, I can't agree enough with the article author who posts:

Not a single person out of several thousand emails and messages came out in defense of the current state of interviewing processes - I'll let this one stand on its own.

The only people I've seen to defend the current process in public are ex-FAANG people who were actively monetizing their experience (e.g. Gayle Laakmann).

<comment><USER47> > FAANG-style coding puzzles

These are not "puzzles". That makes it seem like there is some trick or clever concept the candidate needs to grasp that show "lateral thinking".

There isn't.

These are (or supposed to be) fundamental problems of computer science that require good understanding of algorithms, data structures, code performance, and can be solved in <30 mins on a whiteboard.

Yes, these exist, and there are plenty of them. A pretty common and well known one is "HEAD to TAIL" \- where you have a dictionary of 4 letter words, and given an input of 2 words find a connecting path between them changing one letter at a time. This isn't a puzzle. It's a problem to solve and approach from different angles and allowing for a large number of solutions of different performance characteristics

> Not a single person out of several thousand emails and messages came out in > defense of the current state of interviewing processes - I'll let this one > stand on its own.

Means absolutely nothing. Most of us are not interested in ruining the day of someone who is unhappy with the hiring process by revealing the truth that most likely it just means the person was not good enough. That seems cruel. I'm kind of going further here though because this is the second time this OP is coming up on the front page of hackernews

<comment><USER76> The questions are indeed puzzles; that's why Gayle Laakmann and others have made a living publishing books of the questions themselves. And the puzzles are distinctly different from the content in the majority of CSE curricula.

What's more is problematic is that the construction and evaluation of the puzzles is highly subjective and nearly everywhere lacks rigor. Completion time is a key metric while quality of communication is most commonly either ignored or not assessed at all uniformly among interviews.

(Aside: what's frustrating is that companies make candidates sign NDAs for on- sites; these prevent candidates for disclosing or _selling_ the information they might glean in the process, which very rarely happens. In actuality, it's the former interviewers who violate protections for "confidential info" and copyright when they go and monetize their experience post-job, or even on-the- job e.g. Rooftop Slushie).

> Most of us are not interested in ruining the day of someone who is unhappy > with the hiring process

That's only true in so far as you, as an employee, are paid to achieve positive sentiment among candidates, no matter how shallow that sentiment may be. That's indeed cruel, and it's well-established that interviewers are widely unaware of the consequences of the current hiring process. That's why we get articles like those from the OP.

A true interest in improving the hiring process includes: * Making prep materials and courses freely available (helps industry candidates) * Committing time to CSE outreach to better integrate company needs to CSE (helps new grads) * Finding questions that reflect real tasks on the job (helps the evaluation have a chance of being predictive) * Closing the information gap between hiring managers and candidates: disclosure (in aggregate) of hiring rates, salaries, etc.

Playing along and doing hundreds of coding puzzle interviews is a waste of time for all involved.

<comment><USER47> > quality of communication is most commonly either ignored or not assessed at > all uniformly among interviews.

Nothing could be further from the truth at my company

> A true interest in improving the hiring process includes: * Making prep > materials and courses freely available (helps industry candidates)

Recruiters share this with candidates. They ignore it.

> * Committing time to CSE outreach to better integrate company needs to CSE > (helps new grads)

Go to any university career fair and you'll see companies with booths clarifying these positions working against the mis information of negative blog posts

> * Finding questions that reflect real tasks on the job (helps the evaluation > have a chance of being predictive)

They do. You don't have to agree, but they do. The real task on the job is "disambiguate a complex problem autonomously, and come up with a plan to address it." The interview is a 20 minute constrained version of it.

* Closing the information gap between hiring managers and candidates: disclosure (in aggregate) of hiring rates, salaries, etc.

Semi-agreed. I do wish people and companies were more transparent about salaries. But there is already an entitlement complex from a bunch of engineers on this site and many others complaining why some dude at Netflix in California is making 500k, while he is making 80 in Oklahoma writing code for Bank of America.

</comment></comment></comment></comment></comment><comment><USER77> I have learned from an Amazon recruiter that it was a data-driven decision to focus on algorithms during interviews. Apparently, on average, it has worked the best for them than other ways of interviewing.

I think the state of despair is caused by companies copying practices from FAANGs without understanding the intricacies of why those practices are in place. To the point of asking a UX/UI dev to solve a DP problem.

</comment><comment><USER78> Potential alternative to white boarding algorithms: have the candidate do a code review.

I think that would show the candidate's communication style and attention to detail, in addition to their technical knowledge, and probably give a better sense of seniority too. Most code reviews are done in well under an hour anyway, vs actual dev work on a ticket that takes hours or days, so you're doing more realistic swe work.

</comment><comment><USER79> A word of advice. You spent the time writing this post knowing full well it would get a lot of hits but it appears you haven't yet updated your resume. Little details like that go a long way towards winning over a lot of hiring managers.Good luck!

</comment><comment><USER7> We have to recognize the status quo as an opportunity to revolutionize the software industry.

<comment><USER35> Any thoughts about how?

<comment><USER80> It could be like this:

[https://en.wikipedia.org/wiki/Bar_examination](https://en.wikipedia.org/wiki/Bar_examination)

[https://en.wikipedia.org/wiki/Architect_Registration_Examina...](https://en.wikipedia.org/wiki/Architect_Registration_Examination)

[https://en.wikipedia.org/wiki/Principles_and_Practice_of_Eng...](https://en.wikipedia.org/wiki/Principles_and_Practice_of_Engineering_Examination)

We do interviews in this field like casting calls. Come on over and audition for this role. So basically we're saying 'software engineering' is a talent and not a skill.

</comment></comment></comment><comment><USER34> (Gigantic) thread on the previous post: [https://news.ycombinator.com/item?id=22331804](https://news.ycombinator.com/item?id=22331804)

<comment><USER35> An unusually good thread, considering how worn the topic is, and how indignant people tend to get about it. (Indignation makes for boring threads once the coals cool down.)

The top comment is brilliant and sums up the brokenness in the best way I've ever seen.

</comment></comment><comment><USER81> Kinda feel like saying, content aside I think both this and the prior piece are quite well written. So dear author, keep on writing and putting stuff out there :)

</comment><comment><USER60> Sometimes I wonder when you have such a long interview process what the point is of those super long probation periods.

</comment><comment> non-entity Every time this topic comes up, I realize I need to get the hell out of this industry.

</comment><comment><USER82> FAANG won't stop, as they put people through hell on purpose. They want them to dread interviewing and switching jobs, so they can have them for themselves for longer and pay them less.

<comment><USER35> Please don't take threads in this nasty direction. It leads to predictable and tedious discussion. We all know the situation is broken, but the quality needed to discuss it interestingly is curiosity, not bile.

If you wouldn't mind reviewing [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html) and posting more in the intended spirit of the site, we'd be grateful. Note this one: " _Assume good faith._ " That's not because people do always act in good faith (of course that's not so), it's because the assumption of bad faith leads to crappy HN threads and the assumption of good faith leads to better ones.

We detached this comment from [https://news.ycombinator.com/item?id=22393019](https://news.ycombinator.com/item?id=22393019).</comment></comment>