Ask HN: What do I do? I love writing software but hate these interviews?

Software engineering interviews are broken. I have been casually looking and interviewed a few places. All of which have been terrible experiences.

I recently applied for a startup who is active on HN. The first step was a take-home challenge which I spend a decent amount of time completing. My solution executed all provided test cases and I thought it was pretty clever. I received a rejection saying it didn't pass an internal test case, no other details provided.

Not sure what the solution is to a better interview and hiring experience but I commiserate with your sentiment.

all interviews are pretty broken.

both sides fundamentally have a reason to lie, and interviewing for deeply technical knowledge fields is hard.

after a few years in IT and Engineering I'm starting to think the Apprenticeship model used by the trades might be a better approach.

1) Be wary of companies that try and use take-home tests for free labor. According to Glassdoor reviews, ClipboardHealth is one that comes to mind that is allegedly notorious for this.

2) Asking for a "take-home" challenge before even having a 10-15 minute phone conversation and seeing if the position might be a mutual fit is incredibly disrespectful. I understand that getting a good job might involve jumping through some hoops, but asking for that as the initial contact in a recruitment process is incredibly scammy feeling and disrespectful.

I agree and will pass on all take home before initial call, lesson learned I suppose.

I'm not sure what you want to hear. (but I know I want to hear the same thing)

Most software companies are terrible places to work. If I try to have a conversation with an interviewer and they shrug, I probably don't want to work there. And it turns out that's most companies.

What do we do? There's nothing to do. There's no alternative. It's just utterly depressing.

The horror of software employers is relative to their size and revenue. The larger and more money they have the less horrible the employment experience will be. It all comes down to fatal misunderstandings of economics (applies universally) and having sufficient money on hand to cushion that blow.

It seems thoughts on economics are revisited following a major disruption to productivity. Colonization produced mercantilism. Industrialization produced Adam Smith. Modern corporations produced Keynes, Hayden, and Friedman. Software (automation) has not yet had theirs. These thoughts on economics alter the relationships between employees, work, and the things produced.

ehhh maybe. I've been at F500s that are well funded and they were shit-shows, revolving doors of misery.

that said, they paid alright. there is a certain level of misery I'll accept for 150-250/hr TCO

I read your story and the only thing I can think of is: I have no idea how to "properly" interview you, and I don't think anyone knows how to either (except maybe just reading your CV, having a pleasant chat with you for 30 minutes, then handing you the job).

All this ranting seems to be against a one-off event into a (presumably) multi-year gig.

Switching careers just because of a couple bad interview experiences is a really interesting line of thought, but assuming you actually act upon the idea (instead of just dwelling on it because you thought software interviews are bad), maybe in the process you'll gain a bit more perspective of how good or bad the software industry is doing w.r.t. interviews as compared to other industries.

Don't worry about sounding like too much of a baby on HN, it seems everyone else here also wants to be fawned upon by random strangers in the interview process and have a list of a dozen things they would absolutely not tolerate during the process.

Madness, if you ask me.

How about a single 4 hours coding session in which you and another engineer work on a real application solving the real problems the hiring company is working on?

What do you really test when you ask an engineer with a ton of experience to solve a classic Leetcode problem like implementing a trie-based search? The only thing I can think of is that you are confirming they made an effort to brush up their algorithm and data structure knowledge.

I love this idea for an interview. This would give you a good idea of what the company is actually working on the quality of the code base and who you would be working with. Interviewing should always be a two-way street.

You may want to look at this through a hiring manager eyes.

Create a job posting on linked in, then review thousands of those CV's, pick people and have a 4 hour interview with each (meaning repeating the same problem, you don't want to have a different 4 hour coding session with each individual).

Then calculate how much time you wasted on (a) outright scam (b) people lying about their experience (c) people nervous enough so they almost freeze (d) people not motivated as if you already owe them something.

Then, you need to realize that you probably need more than 1 engineer and you'd want to repeat the process.

Things like leetcode at least filter out people who can't code and people not motivated enough to solve a couple of challenges. Yes, this will not prevent scam. And then you can filter out scam on the follow-up call.

If you solve this problem of getting qualified engineers to the companies at market rates (not overcharging like some outstaffing firms), where companies and engineers have a pleasant experience, I guarantee you can scale it to a billion-dollar-sized business.

Appreciate this thought out response. The interview process is terrible on both ends. Like you said, is a billion dollar problem waiting to be solved.

You don't get it. :)

Algorithmic interviews like that test your capacity for bullshit. They're like "I know I'm testing you on irrelevant bullshit, but I want to see you succumb to my unreasonable demands to have studied trie-based search, because that means you are more likely to swallow any other bullshit I'll throw at you on the job".

If you take 10 people, they will give you 20 kinds of interviews they prefer. You can't make a perfect kind of interview.

I can already see people bitching about your proposal:

- it's too long

- coding along with another engineer is unrealistic

- it's close to impossible to scale this out to a number of interviewers as there are no strict scoring guidelines

- it's too different from what other companies do

- it's trying to outsource some of the problems your company has

- it's too technology specific

- candidates who know the domain will have an advantage

- candidates who know your tools will have an advantage

I'm not saying these are sensible arguments, but you will hear them against all and any kind of interview you can come up with.

"The ideal candidate is somebody deeply familiar with the tech stack we are currently using, preferably having spent at least 6 months working on our code base."

Seriously though, the performance of an interviewee in such conditions are mostly a function of how well the interviewer can "onboard" the interviewee within 4 hours, or how much the interviewer is willing to actively guide the interviewee to the solution (as opposed to letting them figure it out).

Even with a single interviewer this easily introduces bias. I've interviewed many many people over the years, and sometimes I wonder whether I'm giving slightly more hints or less hints based on how subjectively I "like" the candidate. I mean, I try hard to be fair, but I don't follow a strict script, and the variability occasionally makes me doubt myself.

For such open ended tasks as 4 hours of essentially pair programming, I don't know how any interviewer could be objective and fair. Especially presuming that you wouldn't be re-using the same task once it's actually been solved/fixed... (otherwise that's just another artificial problem)

> How about a single 4 hours coding session

How about saying no?

My very biased advice is leverage your public work, and just go freelance. You have to develop some other skills like networking if you want to avoid the meat market freelancing job sites… oh and don’t do websites unless there’s something other than the website involved, or they agree up front to a minimum hour per week maintenance deal (like they will pay 1 billable hour per week regardless of if they talk to you at all, to cover your time spent keeping on top of patches and security) there’s so little value add in website building that you quickly find people constantly using up your time asking for trivial changes that without a maintenance deal will start to make the customer resent paying for them and it’s not worth the headaches…

There’s a lot of good money out there for people with experience who are willing to help small businesses who have sufficient IT skills to have reached the point where they want to automate and improve their workflows and management processes, who don’t feel the off the shelf products like excel, Airtable, etc, are a good fit or do the job they need, and who are willing to either pay either hourly for the work or enough per contact that it’s worth the risk you’ve estimated wrong…

This is obviously much harder in the USA due to the symbiotic (being generous about the positive connotations) nature of employment and healthcare.

> This is obviously much harder in the USA due to the symbiotic (being generous about the positive connotations) nature of employment and healthcare.

Bingo. The benefits provided by employment are (unfortunately) a must have for folks in my position. Thanks for this input :)

This problem can be solved with a bit of money. There are freelancing coops and such who have the power to buy good insurance as a group. You just need to be willing to spend $10k or whatever per year on it.

I am probably in the minority but I actually like Leetcode style interviews and to a lesser extent system design interviews. I think they stick to this style, even if it isn't ideal, because

1. Easier to judge general capacity to break down problems/think on a smaller problem that doesn't require as much prior knowledge

2. Easier to distribute the range of people who can conduct interviews, rather than needing a specifically competent senior engineer whose time is more valuable

3. Consistent style and non-leading interviewers make it easier to compare interviewees on a case-by-case basis rather than there being a risk that certain interviewers style lends candidates performing better/worse

As bad as it is, one good interview round and you're set for a very high paying job for the next 5+ years at a company with great benefits. Even with the shittiest interviews I think it's a good trade off.

leetcode does not test for general capacity or whether you are able to build anything

it just tests how fast you can reproduce an optimal solution to some problem that for some non sensical reason became part of a body of coding challenges

you are wrong in thinking that leetcode is a fair interview style. it gives people who happen to do well in the leetcode style an unfair advantage over those who do not or have no time to repetitively memorize the problems and solutions.

When I mean fair I mean less biased based on prior domain-specific knowlede. Of course people who are better at any X-style interview will be advantaged over people less good at X-style interviews. However I feel that if it were really useless then it wouldn't be the status quo for so long for so many billion-dollar companies who easily have enough money to put more finesse into hiring if they wanted.

General capacity over whether you are able to build anything is harder to intuit in interviews, but resume, past experience, systems design style interviews, github/portfolio give a good estimation.

it is the status quo because it allows companies to discard the value of experience because leetcode style interviews do not take that into account. once you are hired they can profit from your experience without really paying for it. it also lets them avoid potential discrimination issues. always ask yourself what the real reasons are behind the “status quo”.

I don’t hire, but if I was, then for finance I’d hire a guy with finance and stock exchange automation bias, who knows e.g. common pitfalls in working with exchanges. So they could avoid losing money or creating an accounting mess.

For business I’d look for a guy who dealt with bigcorp bullshit protocols and e.g. knows up front that “there’s API” may mean anything from exactly that to “we have a half-working semi-email system with rate-limited polling and no idempotency”. So they could make correct predictions and decisions.

For both I’d like to see 5-10kloc past or example project, or at least few pages of code that they assume is both practical and good enough, to get the sense of their development (not CS) skills and habits.

I have no idea what for I’d hire if they excel at leetcode. That position must probably relate to some rocket science in a low-power low-tech environment where external dependencies are forbidden by a sort of a military contract. Because irl when you need btree/redblack/matrix/etc, you need postgresql or import <package_name>. Not to write it from scratch because you smart.

if it were really useless then it wouldn't be the status quo for so long for so many billion-dollar companies who easily have enough money

Their money can what others can not. But that doesn’t mean that all others aren’t just practicing cargo cultism.

Are you going to die practicing? Is this going to make you a worse developer?

There is like literally 3-5 patterns that you can compose together to solve most of the problems.

To clarify: I agree that most of interview processes are shit. I disagree with the tool class like leetcode being called shit.

> Are you going to die practicing?

Probably not, but it's bullshit in the sense that solving leetcode problems on the fly is not typical day-to-day programming work in ~99.9% of jobs. And even when creating a complex algorithm is a part of a job, it's usually for a big project that's the core of some business problem that you will have a considerably longer amount of time to research, think about, test different solutions, and implement than the space of video coding interview.

Would you hire a divorce lawyer by testing them about the intricacies of Constitutional law? Would you hire a heart surgeon by quizzing them on the complications of laser eye surgery? Would you hire a civil engineer to build bridges that support trucks and trains by asking them to solve some underwater pressure equation involving submarines?

> Is this going to make you a worse developer?

In a certain sense, yes, because there's an opportunity cost to every human activity. If you spend 500 solid hours of intense effort grinding out leetcode solutions, that's 500 hours you don't get to put into practical stuff you might use on a day to day basis: learning about servers and web services, deployment, different software architectures, databases, design patterns, security, accessibility, etc.

> There is like literally 3-5 patterns that you can compose together to solve most of the problems.

This is somewhat misleading to me.

You can learn some of the common elements of solutions like trying to break up a problem into smaller parts, using a hash table, sorting an array, recursion, or other common elements to leetcode style solutions. But solving a type of problem you haven't seen before in the span of a video interview is pretty much a crapshoot, particularly when you have somebody just staring at you and typical problem-solving approaches you would take like doing Internet research or trying to diagram a solution out on paper are probably out of the window.

Leet coding is testing two things:

- Intelligence. It's basicall a form of IQ test.

- Willingness to prepare for an interview (by grinding out the leet code in your free time). This is a good proxy for general work ethic, and also for much hard you actually want the job.

it does not test intelligence, just whether you memorized a solution to a problem

hiring someone who is really desperate for a job is a poor strategy for those hiring unless the goal is simply to get cheap labour.

Without the pressure/context of a job interview, I find Leetcode to be immensely fun :)

However, within the context of a job interview I do unfortunately find it to be a little insulting. I think, like other commenters have mentioned, these Leetcode style questions are only to see "will you tapdance" - which is totally fine.

You're basically halfway there, perspective wise. Just leave your attitude at the door and do the interview.

For better or worse there really isn't a lot a company can do to fairly evaluate if someone can code other than actually do a little coding. And any coding problem that can be reduced to a 30-45 minute block is going to be somewhat arbitrary and leetcode-ish.

Good luck on your search!

Offer to streamline the recruitment/interviewing pipeline for the company(s) in question. Tell them you will give them a technical introduction to your public projects (choosing just the 1 or 2 projects that present your skills in the best light). Additionally, tell them you are happy to analyze and evaluate any code they might be interested in presenting to you.

Be prepared to discuss the good, the bad and the ugly concerning the evolution of your projects over time.

A company willing to sideline their generic process or at least adapt it in light of these suggestions, is a cut above as an employer, and they should understand that an approach like this makes it easier for you and them both.

A company unwilling to at least tweak their process a little bit is a company you probably don't want to work for.

It sounds like you don't really understand how companies and recruitment work.

Companies are machines, and the employees are cogs. When recruiting for a new cog, they will cast a net, get a few hundred applicants, then whittle it down using their process (which probably includes a bunch of interview rounds and some dumb exercises).

They are not looking for unique snowflakes, so your thoughtful application just creates extra reading and work for them.

Of course, they are not looking for robots either, so if you have some extra abilities on top of the basics that will make you stand out, but you cannot side-step the usual process and have to jump through the basic hoops and to get that far.

The exceptions are at smaller companies / regional locations, or if you have some connections or unique and deep skills (e.g. you invented X, wrote the book on Y, etc.)

I have been interviewing intermittently for a few months and I can completely empathize with what you are experiencing. It has been around 10 years since I had to do any real interviews. What is expected and accepted now is way over the top, and really feels disrespectful how much time some of these companies expect you to spend interviewing with them. Some companies are definitely better than others though.

For the worst ones, the interviewers act like you should know what they want you to do already. I'm guessing because there is so much information about tech interviews out there. One of my first interviews they opened an online IDE with 15 minutes left in the interview, showed me how to write code it in and use the command line there, then told me to build a GitHub clone with such and such features. That left me completely flustered because I took what he was asking quite literally.

The best interviews I've had so far they send information about the interview beforehand that explains what it will cover, what they are looking for, who I will be speaking to, etc. I don't know if we are allowed to name names here, but I would like to give a shout out to Cisco Meraki. They definitely had the best interviewing process I've been through so far.

Mainly, the problem is that things are so competitive right now as far as getting jobs. If things were normal I would just focus on the companies that had a sane process and ignore the rest. My strategy right now is to take any interview right now and treat it as practice since I am really bad at interviews, and hope I do well with the companies that actually seem like a good fit. I don't think I would accept an offer from a company that put me through the ringer though.

I run my own business right now, and I really like having to tackle all aspects of it, which has led me to also consider trying a different field of work. The problem is that none of them seem to pay nearly as well as being a software engineer. In your case, I would just keep doing whatever interviews you can. Do the terrible interview loops with the knowledge in the back of your mind that you would never actually accept the job offer. Then when a good interview loop comes along, it will seem all the sweeter and you'll be ready to ace it.

I have attended some cool interviews for niche openings in business and academia, where there were one or two stages only, no LeetCode, and no other strings attached. These were all EU-based or remote. Basically, I had to discuss some my prior work, including architectural and implementation decisions, with particular pointers to code.

For example, one was at a new Haskell group in a Swedish SME based in Skåne. Another one was for a permanent scientist position in a prominent UK university.

Questions were constructive, interviewers had clearly gone through my CV in detail, and they were also interested in selling me the advantages of the job opening. Since I also have quite a lot of experience and some public code, they had neither time nor interest in testing what I know through coding problems.

Pay at EU is a bit lower than what you are used to, but these might have other kinds of benefits.

Do you like working as a programmer and being (presumably) very well compensated for it more than you dislike the interviews you’re doing?

Either way, there’s your answer.

Or you can always start a company and interview/hire people The Right Way.

>I don't take the "kill spray" approach to interviewing

Sadly this is the only option nowadays if you seriously want a job. Instead of the interviewee being picky and only selecting the jobs they think nicely fit their personality, the right approach is to just apply to all jobs that fit your skill set. Interviewing is a skill that you have to practice, and the best practice is by just doing a lot of real interviews. A good strategy is to front-load the companies you are not very excited about, practice on them and if you get turned down it doesn't matter. Then when you get to the companies you are actually interested in you will have had lots of practice interviewing and have better odds.

At the end you'll hopefully be left with a few offers and you can decide if you want to actually work at any of those companies. If you don't then just politely turn them down and keep interviewing at more companies. It also helps to have offers in hand from other companies when applying at new companies, you'll get better/faster treatment because they know you have a deadline.

I run two software companies and we don't do any of these interviews there. I see no need — any normal discussion and probably a code review done together can cover it. When you apply for jobs, look out for these companies. And write that you won't participate in any of these gone-mad interviews.

Maybe it is time you start a company where anyone that has written OSS or worked at a company you’ve heard of gets a free pass to join the company? If you can be successful I’m sure many people will adopt this as their hiring process.

I've had the same thing happened to me, were the interviewer was asking arbitrary and sometimes very general questions without much care to discuss anything, which looked quite strange to me. He didn't want to be there, that was my impression.

I believe the reason is that he/they don't really want to hire, they just have to do the interview for some reason. It's this kind of company were the job ad stays up for like 6 months straight, it becomes obvious at some point that they don't want to hire anyone.

If you're good, freelance/contract.

The companies don't need to vet you as thoroughly as a permanent hire.

Once they know you're good, and you know they know, the power balance changes because they don't want to loose you.

After the end of the first contract cycle, line up competing options and be prepared to walk away, but you may not need to, because from there on you dictate what it will cost to keep you.

> - Mind you, the worst interviews I'm referring to above tend to be from medium to large size companies. For smaller companies/startups I've noticed the interviews are still pretty fair and decent.

Why don't you, instead of changing fields, just apply to those smaller companies?

i have 20 years of experience and probably 100k lines of code across 40 repos and i have found no way around the leetcode BS so i have decided to no longer apply for anything and focus on my business.

I am in the same boat. I have been casually looking for a new job (while still employed) and found that even companies that say they don't do Leetcode interviews still ask questions that have no direct relevancy to the job, i.e. they test very specific known puzzle solving algorithms (even though they don't call this an algo/data structure interview). Yes, sure, I would be able to brush up those skills again (1-2 months of my free time?..) and become sharper at puzzles, but it just feels so forced.

I've decided to start my own business next year cause I don't want to go through all the leetcode bs too.

Work for yourself. It is easier to create a product that makes money nowadays than find a job so create products.