Hacker News Reader

Comment by reacharavindh | Hacker News Reader

I am still feel pissed about an interview for a job I think I'd have fit in superbly. It would have been fun, and productive. If not for the hackerrank quiz they threw in the front filled with irrelevant puzzles that needed solving under time pressure. I don't have time to spend or willingness to "train" on such puzzles for the purpose of getting a job. I am sure if I had a chance to talk to the team or the engineers, it would have been effective. This bitter experience only amplified my hate for such tests even more. The job I'm at currently, gave me a practical task(similar to the ones I would be doing on the job) and a few days to submit the results/notes of. It was so much more pleasant to walk into a tech interview with such work and have a nice chat about practical technical stuff instead of stupid puzzles.

View on HN

Yeah this is the super unfortunate state of engineering today. I literally cannot bring myself to study puzzles when I could spend my time pursuing some interesting open source work.

Consequently, I have a lot of successful open source work, but most companies still don’t care and fail me for lack of fake puzzle quiz skills.

It’s utterly baffling to me that companies don’t want creative employees that build successful products out in front of everyone. Where you have a clear view of all their interactions and code.

I’ve tried to change this thinking at my current company and the consensus was it would be biased. Biased?! Code quizzes are highly biased! I’m producing useful functionality to the world!

I believe this and transparency are the new remote work. Some companies will get it early and for others it will take a major upheaval to get them to a place of reasonableness.

How many people are in your company?

I actually enjoy those puzzles, but agree that they are irrelevant to the work. In fact, the very few times they are relevant is something of a special occasion! "Hey look, I have to design a slightly novel algorithm!" Most of the job is, of course, figuring out why things went wrong, based on imperfect evidence, which requires a good mental model of the entire system plus the ability to make changes to test and eliminate hypotheses. Very few, if any, technical interviews capture the essence of this act.

Even more rare "Hey look, I have to design a slightly novel algorithm in 30 minutes while babbling the whole time!"

For someone who can't even get an interview, but loves working on oss, this is highly discouraging...

I already have to be so focused with what little time I have in my life, and sacrifice a lot, to just make the things I want to make, I just can't imagine finding all the time to do this meta work/training.

Every day I grow more comfortable with the idea that my love of software dev and oss will forever be avocational. Perhaps though, financial instability aside, I'll be happier this way anyway

I'm not sure why you aren't getting interviews, but I've had multiple coding jobs in the past where the interviews had little to no technical quizzing at all. Don't get too discouraged, there's probably a match out there for you, maybe just not at a FAANG or one of those super competitive companies (which, quite honestly, I wouldn't want to work for anyway--but it's personal preference).

You can always move onto a more competitive company later once your resume has some solid experience on it, if that's your cup of tea.

I am not sure either, but its been a few years at this point. I have no desire to work for a FAANG company, or to make even relatively good money, I do try to apply to the smaller places. No need to recite all the hiring tips though, I know them all! Think it's just a combination of bad luck and lack of relevant education (I have an MA, but it's in humanities).

That is encouraging though that not all interviews are like this! I have projected so much into the fantasy of getting a tech interview without ever having one, its easy for me to be swayed one way or another.

I have over 20 years experience, and I've worked for some major companies. I went through a year of interviews with those stupid quizzes.

Needless to say, I got nothing from it. A couple places I was perfect for the job, but I couldn't spit out elegant quiz code on demand from memory. Sorry folks, head injuries f with your memory. I'll always look shit up so I get it right.

I think the big relevation would be that these are not “puzzles”… there’s about 10 algorithms that if you learn you can solve the problems pretty easily. Make sure you keep reviewing the 10ish main algorithms.

Example:

Breadth first search

Recursion

Binary Tree

Etc.

Then it’s more a classification problem.

if you ever did an interview a at one of (Facebook,Apple,Google, Microsoft..) you know this is not true.

They definitely are asking puzzle question that an university teacher teaching algorithm would fail. And the only way to is practice stupid question on leetcode

He's partially right. There's a lot of pattern matching involved. Like he describes, there are several broad patterns. But then there are sub-patterns upon sub-patterns. You need to be able to recognize these when the interviewer throws a problem at you.

You grind leetcode problems over and over so that you can better recognize these patterns and know when to apply their associated solutions.

The most idealistic scenario is you get a problem you've recently practiced verbatim. Then you just put on an act like you've never seen it before in your life.

But if you get a problem that you can match to a pattern you've practiced, then you're still mostly in a good place.

I work at FAANG - my take is, all questions can be solved based on these 10-15 data structures / algorithms. They are just gift wrapped with a lot of fluff, but underlying each of them is one or a combination of one of these data structures / algos.

As an aside, to everyone who has asked me how to get into FAANG - I always say you should be able to code DFS/BFS in your sleep like your life depends on it. 1/5 questions is surely going to be a tree/graph search.

> The job I'm at currently, gave me a practical task(similar to the ones I would be doing on the job) and a few days to submit the results/notes of.

Take-homes get a lot of criticism on HN, but in my experience they're superior for all the reasons you mentioned.

I don't actually see pushback against take-home problems in the real world, mostly just online. When given the choice, most people would prefer a practical take-home over a whiteboard style interview.

HN people seem to line up 20 interviews and spend a week doing them. Take homes are untenable in that situation as half the interviews would still be a full workweek. I soured heavily on take homes during an active job search phase as I was already interviewing 4 hours a day with 3-6 people. I had a pile of companies, would accept any of them on the surface, and it was just a matter of grabbing one.

Many interview at a much less aggressive pace than that and I would prefer a take home when I am out of leetcode practice.

> HN people seem to line up 20 interviews and spend a week doing them.

Having mentored a lot of college grads and also interviewed a lot of candidates, it's actually extremely rare for people to line up a huge number of interviews in a single week. It can be done if you really, really treat it as a numbers game, but it's not how most people do it.

> Take homes are untenable in that situation as half the interviews would still be a full workweek

Take homes shouldn't be taking a full workweek.

If anything, take-homes make it easier to stack a lot of interviews because you can do them at your leisure in your own time.

> I was already interviewing 4 hours a day with 3-6 people

I think this is the disconnect: You're taking time off of work for live interviews, but take-homes come out of "extra" time. If you're interviewing full time, a take-home is still more flexible than a live interview.

Oh, take homes are fine without the interviewing numbers game. They just break when you do that.

Many of the take homes I encountered also had rapid turnarounds. I would have 48 hours from Tuesday afternoon. A couple of times I was up at 3 in the morning as I had two of them due and had to abandon one of them as I just couldn't stay awake longer.

In hindsight, I should have realized the folly of that earlier, but I was eager to get as many paths going as possible.

My favorite (and only) take home interview assignment. >> here is the problem, research as much as you want however you want, and take as long as you want... when you are done please format it as a 'xyz-ide' project on github and we'll get back to you in a day.

I hate this and find this just as academic and problematic as the whiteboard and quiz styles. Success in software development is about making the right trade offs to deliver while saving cost (ie your time). When you leave it so open an abstract, the dev looses the ability to discern this. "Production" standards are entirely based on context of the project and very specific requirements. Do you need structure logging, or rate limiting, or error handling, or notifications, or system status ect.. With do you already have systems in place to integrate these. Do you need a custom solution (like your own lambda engine) or do the off the shelve solutions (like aws lambda) meet the requirements.

Here's the thing: take home assignments typically come near the beginning of an interview process, even before one progresses to an on-site (or equivalent). Understandably, very few companies give a take home in place of the entire on-site. But, a take home generally doesn't get you out of any part of the 4-6 hour dog and pony show. Which would you rather do: 30 minute recruiter chat + 60 minute technical phone screen with a human + 4-6 hour on-site, or the same process with a "1 hour" take home that actually ends up taking 4 hours in place of the technical phone screen?

Incidentally, I have the same criticism of TripleByte. Sure, they get you on-site with companies faster, but their process takes a significant number of hours (essentially equivalent to its own on-site), and it doesn't get you out of any part of the prospective employer's on-site.

This too. I have been ghosted on way too many take home assignments.

Same here. I did a take home that took 6 hours. Sent it in and then a few minutes later received a rejection. I'll never do that again. I now reject any take homes that will take more than 90 minutes. That's by my estimation - not the company's - I've seen many companies way underestimate the time it should take which is a sign that they've never had their own employees try it.

Take homes are bad because the time investment is asymmetrical. A company can just say to everyone who applies to do the take home test because there's really no investment on their part. At least with an interview, you know the company is investing an equal amount of time into the process.

Triplebyte used to be helpful because it did allow you to skip the initial phone screen but that doesn't seem to be the case much anymore.

> Having mentored a lot of college grads and also interviewed a lot of candidates, it's actually extremely rare for people to line up a huge number of interviews in a single week. It can be done if you really, really treat it as a numbers game, but it's not how most people do it.

What people need to remember is that there's a very real pecking order. Everyone will do Google's take-home but the local business paying local CoL/Prevailing wages? By the time some get to their take home, the A players are already landing in SFO for their final rounds.

The people that are the most hirable won't have time to do 20 interviews, they'll get offers almost right away.

> I think this is the disconnect: You're taking time off of work for live interviews, but take-homes come out of "extra" time. If you're interviewing full time, a take-home is still more flexible than a live interview.

The thing is, with a live interview it's one hour of their time for one hour of mine. With a take-home, it could be 4 hours of mine and... ten minute for them to look at the code and run a test suite on it. So as a rule of thumb, I always suggest favoring live interviews (they are investing more time therefore they place a higher value on the potential hire).

> HN people seem to line up 20 interviews and spend a week doing them.

Somehow they also seem to get all their offers around the same time to leverage them against each other.

Well, this is a function of lining up so many. Apply for 50, get interviews at 30, you end up with maybe 1 in 3 have aligning timelines, pass 1 in 3 of those, and you have 3 offers to choose from at the same time before they explode.

Lol. Offers don't really explode on timelines less than a few weeks. If you get pressure from a company to accept their offer in less than a week or 2, that's a red flag, especially if they want you to start right now.

Ah, interesting. I admit that I am often a schmuck that takes contracts at face value. I have always had it be 24-72 hours. I have even been asked if I would accept an offer immediately (without knowing the salary range or whether I would get permanent remote).

The last time I did more than 2 interviews during a job search was 1999.

I assume you are typically hired through network?

Actually, the opposite. Always cold.

Edit: Oops, sorry, that's not true. 2002 was network. Everything since has been cold.

> HN people seem to line up 20 interviews and spend a week doing them

source?

It really depends on what you are given.

A take home that is 1-2 hours (what might be the length of an in person) is fine.

A take home that is 10 hours of work on the other hand

Yeah, even when you are unemployed a 10 hour take-home is a bit abusive. I had to bow out on one take home that would have cost me actual money to set up a development environment with all the ancillary software, plus the three separate programs in three different languages. LOL, no, I'm not going to spend cash on AWS to set up a dev cluster with paid software.

I have to chime in with an anedoctal. Chainalaysis, a unicorn blockchain company, was giving take home assignments a few months ago for new grad positions. Seems like enough people refused and they have now switched to a 45 min timed camera on HireVue

It depends on the procedure, somewhat.

For example, it's very tempting for a company to send out tests before doing much resume screening. Why should I spend 30 seconds looking at a resume when I could have the candidate spend an hour on a test, and save myself 30 seconds?

Or what if I set a take-home test which is supposed to take 1 hour, but also supposed to really to stretch candidates' ability and give the best candidates a chance to shine? Probably a lot of average candidates will give themselves a bit of extra time - and before you know it, I'm sending a "1 hour" test that takes an average of 4 hours.

Take-home tests are a lot less objectionable if you can properly guard against these problems.

I definitely agree that the second issue is tricky to get right.

But for your first point, that wouldn't seem to make much sense given the time investment from the company as well. It takes time to review take home tests, much more time than it takes to review a resume or even for a recruiter to have a quick phone call with the candidate. So why would they send out a test to someone first?

I've usually seen something more like this, which I think generally works fairly well:

1. Initial resume screening 2. Quick phone call with the recruiter 3. Usually some kind of technical call/interview with developer(s), engineering manager or similar, at the very least some discussion of experience and background 4. Send out the test, review it, call the candidate back in to discuss if they want to 5. Probably some other stage at the end

Home tests can be scored automatically with test cases.

time limits put an upper bound on how long youre spending on it which is good for a lot of people. ive given take home tests and some people clearly put more time on it than we expected.

as an applicant, ive refused takehomes that were auto-sent on receiving the application, but if its after a phone call with the hiring manager or engineer its not so bad. but then, i did end up having to defend why i didnt do a bunch of parts ancillary to the assignment - 'why didnt you build a config loading system?' 'uh cause i timeboxed it and that gives you fairly little signal compared to the business logic'

The best process I went through was for a job I didn't get, but had me do a take home project that took about 4 hrs and they gave me a $300 USD amazon gift card. The biggest problem is it has really limited my tolerance for a lot of BS interview requests that previously I might have considered.

Yes. There is no silver bullet for this problem. However, interview goes both ways. Hiring team to judge a candidate and the candidate judging whether to go through the process and want to work there.

When I went through the job search, I did close out a few applications because I found out I wasn't too interested in their description of the role (after a conversation with more details than that was in the job posting), or simply if their screening process wasn't worth my time. The one I lamented about pass through those interest tests as the job genuinely fascinated me.

The two biggest problems with takehomes:

1. They do not scale horizontally. You do a takehome and get rejected, then your effort has become worthless when applying to other companies. Versus grinding leetcode - it scales across a huge breadth of many different companies.

2. Often times a takehome is not. instead of an leetcode interview. It's in addition to the leetcode interview. So you end up needing to practice leetcode anyways. Now you just have more work to do - work that doesn't horizontally scale.

There is evidence that traditional software engineering interviews[1] assess a candidate's ability to perform under pressure better than their ability to do the job. I find it crazy that you need to spend weeks studying leetcode-style problems after doing the job all day in order to prepare for an interview.

Coincidentally, I've started working on a product to help this[2]. The general idea is that tasks like pull-requests, bug fixes and realistic take home projects are a better way to test candidates. Everything is done using Github, the tasks are all realistic and candidates can use their own laptop and development environment. It's not fully ready yet, but if anybody wants to chat about it just use the info@ address for the site.

[1] https://www.sciencedaily.com/releases/2020/07/200714101228.h... [2] https://devscreen.io/

If you can capture the candidates ability to setup a BTD (build-test-debug) loop, their ability to find and fix bugs, and that they know enough tooling to get it into production (and troubleshoot deployment), then you have successfully checked 80% of the job requirements for...almost every programming job out there.

I'm lost on the "tooling to get it to deployment" test idea. Deployment seems both company (and industry) specific and trivially easy to learn compared to programming skills.

Great! Today you learned something new: sometimes software deployment is complicated! Get more experience, and you'll find less trivial deployments. "Trivial deployment" is the goal of many systems, and is rarely met.

I never said deployments were trivial. I said they were trivial compared to programming skills. And I also said they are both industry and company specific.

Expecting a random hire to already be familiar with your deployment process and tools seems very strange. I've done deployments in many situations and, well, I wish there was an industry standard. But as you point out there are many conflicting tools and using them is never turnkey.

They are industry and company specific, but so is any concrete problem you'd ask anyone to work on. They don't t need to be familiar your specific tools, but they need to be familiar with why they exist and be able to do something similar on their own if needed. Even at a place like Google, where deployment is extremely mature, it's still important to know what's needed to roll your own. As you say, these things are never turnkey.

That paper has been widely misunderstood in these discussions. Both groups were given the same whiteboarding questions. The only difference was whether the interviewer was in the room.

Having the interviewer in the room clearly creates a higher pressure situation.

Sure. But the study does not conclude that coding-challenge interviews are what tests for anxiety management. It only speaks to the effect of having the interviewer be present. But people cite this paper as though it makes an argument against coding-challenge interviews as a whole.

Is the interviewer typically in the room or no when doing a Leetcode whiteboard interview?

Typically yes.

But if a company did leetcode questions without the interviewer in the room, I find it exceedingly unlikely that people would shout "Interviewing has been saved! It now tests skill rather than anxiety!" As such, the conclusions of this paper don't seem especially relevant to the discussion about interviewing processes.

Well, it seems like either you don't understand the concept of incremental improvement, or you're being deliberately obtuse. Taking a good portion of the anxiety out of the situation can only help, right? I don't think anybody is pointing at this paper and saying "if we do this one thing, then interviewing is fixed," except people who are looking for a straw man, do you?

This is cool!

Having been on both sides of interviewing, I find that the majority of complaints about the status quo seems to come from people that haven't been involved in the interviewer side that much and consequently simply put forward their personal preference (e.g. some people downthread saying they prefer take home, and then subsequently being countered that take homes aren't ideal for various types of candidates)

No offense to anyone, but it strikes me a little bit as armchair expert hot takes saying "why not just X". Personally I think that rather than complaining about leetcode-style loops, it'd be more productive to think in terms of what the problem domain is: namely, many of these companies are typically large and want some level of standardization in the hiring process: you have to contend with things like some ethnicities being culturally prone to "hiring down" to inflate subordinate count, talk-the-talk-but-dont-walk-the-walk types, thinly disguised sexism/ageism/other biases that are excused under the "cultural fit" umbrella, mismatch in terms of desire to provide technical interviewing skills vs volume of candidates, etc. It's easy to attack any one methodology simply because if such a thing as a silver bullet existed, we'd all already be using it. All interview methodologies are flawed, and for better or worse, leetcode-style happens to predominate interview loops because it has a semblance of standardization (though ironically, IMHO a good interviewer ought to be looking between the lines more than seeking specific answers, and a lot of leetcode-style interviewers don't get that nuance)

If anything, my two cents is that leetcode ain't going anywhere, so the next best thing we should be focusing on is making it more widespread that memorization culture isn't and shouldn't be the evaluation criteria (this goes both for the interviewer and interviewee sides)

> some ethnicities being culturally prone to "hiring down" to inflate subordinate count

Sorry, what? Which ethnicities are these?

You know... those ethnicities. The ones with the culture apparently focused around selfishness and power-seeking...

I think answers like the parent are why Google started doing "googliness" interviews.

Memoization > Memorization

Perhaps personal memoization is a topology on personal memorization?

I made a bad dynamic programming joke.

As a counter-example, I've been on the hiring side many, many, many, many times, more times than I can count, and I despise leetcode-style tests as much as or more than anyone.

I've been doing this long enough to know that the things that matter in every job at every company are almost never technical ability. It's skill in managing deadlines, collecting requirements and dealing with changes, divvying up work with teammates, things like that. Things that are difficult to test for, even on a whiteboard.

Asking questions about experiences and posing hypotheticals to see what gets candidates interested, or what stories they have to tell, these have been a better predictor of eventual success in my experience than any sort of technical test.

> Things that are difficult to test for, even on a whiteboard

Agreed 100%! I'd love to explore scalable ways to test for these. I've heard of people in smaller companies who get lots of success with non-leetcode style interviews because they can either have full control over the interview cycle (e.g. a hands-on CTO) or a still tight-knit "rock star" team that "gets it", but the challenge is that you end up getting a huge amount of variability as a company scales to hundreds or thousands of software engineers and things like rush hiring to meet deadlines start to enter the picture.

I like to start my interviews asking people about recent work experience and surprisingly that has been a pretty good indicator of how well they'll do in the technical portion. It's still a bit challenging to evaluate because experience doesn't necessarily correlate with potential. I've had a number of candidates whose description of past day-to-day work was nothing to write home about, but you can see their growth potential by really reading between the lines.

Posing hypotheticals is actually relatively standard practice at big tech: it's called the system design session. IMHO, you can get a lot of good signal from these if you do it right.

The approach we took at my aforementioned $BIG_CO_EMPLOYER was to have multiple interview teams, each focused on particular aspects. e.g.,

- generic HR chit-chat. Our HR rep was really good at uncovering personality problems (and she was used to dealing with devs :-). Every single person she raised a red flag about also had issues somewhere else in the process and we learned to trust her instincts.

- What did you do at your last job and what did you like/hate about it? What code were you most proud of? If I asked you to design a system to do X, what would you need to know, what would you be concerned about?

- Basic SE theory: what do you know about SOLID?, what are some concerns when dealing with shared data in a multithreaded design, etc.?

- Programming/design exercise with the interviewer as a co-worker/resource. Done on whiteboard, or sheets of paper or whatever candidate is comfortable with. Code does not have to compile, no online access allowed.

There were scripted questions at each level (except HR) and the interviewer keeps notes on the candidate response. OK to dive deeper or go off on tangents as needed. At the end of the day, or worst case first thing the next day (so the interview is still fresh in everyone's mind) we'd meet to compare notes & vote thumbs up/down.

Most, if not all, software engineering roles are highly specialized above and beyond general computer science. I think a lot of complaints about interviewing practices stem from candidates feeling their prior experience, which is directly relevant to the position they applied for, is being ignored and replaced with questions about arcane puzzles.

I think even those on the interviewer side acknowledge that leetcode style questions aren't perfect. I think the biggest misconception is the idea that memorizing the puzzle itself is the hiring criteria, when in reality it's supposed to be thought of as a more elaborate version of fizz buzz. For example, inverting a binary tree isn't about binary trees or data structures, it's more meant to be about whether you understand recursion. It can tie into signals about ability to break down problems into smaller pieces, understanding of memory layout (a proxy for understanding of low level concerns), etc.

Ideally one should not need to check an entire barrage of checkboxes perfectly, but enough in some dimension to "prove" they aren't completely clueless about programming, and also not raise a bunch of red flags (e.g. if you tell me you have 10 years Java experience and then struggle with class syntax, that's obviously going to look bad).

Ideally there are peripheral questions where one gets the opportunity to display well-roundedness (I like to ask about testing in an open ended fashion, for example).

Ideally, an interviewer org ought to take a bit of effort to cater questions to roles/stacks more appropriately. Web folks tends to do this well IME.

Unfortunately, many interviewers take coding/algo sessions as an opportunity to do a pissing contest either because they haven't been trained/prepared well or because of some dumb sense that company brand is somehow related to their personal worth or whatever, hence the bad rep.

This is why the last large organization I worked (at least my group!) settled on pair exercises.

We had a known problem set that all candidates had to work and this consistency kept HR happy (although it was an uphill battle to convince HR that it wasn't a "test"). The problem was sized so it would be just barely possible to complete the entire thing in 45 minutes. In fact, I think in all the years we did it, only two people every completed the exercise, and one of those we suspect knew about it ahead of time.

However, the problem wasn't a blind "do this on a whiteboard" exercise. We didn't really care whether or not they finished: rather we wanted to see the process they took, the clarifying questions they asked, where they got stuck, how they asked for help, etc.

The candidate could choose to work in complete silence, or work with the interviewer as a team exercise, or a mix of both. The point of the exercise was to see if they could (a) program their way out of a wet paper bag and (b) do so in a way that didn't completely alienate the people they would have to work with. Leetcode? Obscure algorithms? We couldn't care less.

It was surprisingly effective.

Been on the hiring side a lot actually! I prefer to have conversations with people and hire primarily off OSS, it works really great

I got one of these as the second step for a senior engineering manager position. I had the luxury of telling them there was an obvious disconnect in terms of what we felt was valuable and required to be a good leader, and cancelled the process. No response from them until 3 months later I got an email saying they were moving forward with a different candidate and asking me to rate their interview process!

This is the redacted exchange:

Hi [PeopleOps], I started the assessment and was very disappointed to the point where I didn't complete it. I've been an Engineering Manager for about three years and still have a lot to learn, but I've never encountered anything that looks like a set of brain teaser puzzles & psychometric analysis similar to this test. I have to interpret this a huge mismatch between how [Company Name] defines the best skills and aptitudes for the role and my own, so I'm going to withdraw from the process. I can't imagine a lot of candidates are prepared to jump through these sort of hoops but that's just my single perspective.

MONTHS LATER

Thanks for the time earlier this week.

I wanted to give you a heads up as to where we are at in our Sr. Engineering Manager hiring. We had an Engineering manager join us earlier this week and as of right now, we're ok on the hiring front.

I'd love it if you could provide us some feedback on the process as we're always looking to improve. Here's a link to a very brief survey that would really help us out. Thanks!

One of the things I've come to enjoy about becoming a more senior engineer is how the interview flow has changed over time. Now that I've interviewed lots of people myself, I understand the person on the other side of the desk a lot better and I feel it's a far more balanced relationship.

The issues that candidate employers are concerned about are (should be) more along higher level constructs such as ensuring quality or how to decide on a new technology or platform. What's a really interesting bug you found -- where really interesting probably means it was a system level issue, not just some bad code.

The interview becomes a detailed discussion between peers who are each trying to understand if they want to work with the other.

If someone started out with leetcode crap I'd probably react exactly as you did.

I've only done one of those nasty psychometric tests once. I didn't get a call back . This wasn't a surprise since they screen out non-neurotypical people with tests that are biased against dyslexia, colorblindnesss, dyscalculia, dysgraphia, ADHD, autism, and sequelae of brain trauma like short term memory faults.

This. I've slung code in (now) 16 different languages from macros, to scripting to compiled over the last mumbleseveraldecadesmumble. But they throw btree sort hackerrank puzzles at me when I've been a working sysadmin for over 20 years, and never had algorithm courses for a BS degree? How about no. If I have to sort stuff, I use a built in function, and let the CS hardcore software engineers do the puzzle games.

I'm a script hack and sysadmin/SRE, not a software puzzle guru. I look up the syntax I need for the language I'm writing today. I may end up programming a different language next week, month or year. It's not worth the trouble memorizing the triviata of every language I ever used.

There are only so many ways to cast variables and write loops. Everything else is nomenclature and punctuation.

Ask me to address a system problem, don't give me a BS puzzle.

FWIW, every data structure / algo interview I've done allowed me to use built in functions for sorting (I work at FAANG).

In general, I dislike the interview process too, but there just isn't a better way to do these, as is clear from this large thread. If you look at it from the company's perspective, you have to conduct interviews at scale, and it can't hand off the same system problem to everyone.

You're being tested on your problem solving ability. It doesn't correlate directly to your job, but the general assumption is, if you can solve puzzles after studying for them, the chance that you can solve any random problem thrown at you is high.

> It would have been fun, and productive

How do you know this? The signal of them dumping you with some leetcode should be an indication that it wasn't meant to be?

Not necessarily. It just means that they weren't good at recruiting, they could still have a great team to work with.

How do you recruit a great team if they’re bad at recruiting?

If they put together most of the team another way, then it would be fine.

My prior company would have interns do leetcode and system design. Intermediates and up had some paired code writing and a far less formal system design discussion.

Most of the team might have been hired through a network and you only get leetcoded as an external unknown.

Where I work our team gets to review applications (pre-filtered) for candidates we are interested in. Those candidates are then given a general technical exercise. We get to review the results and ask follow up questions, but we basically get zero input into what kinds of questions are asked. I could 100% see a scenario where the people who manage the recruitment process replace that general exercise with some third-party online solution like hacker rank or whatever.

This. I interviewed with a company that I really wanted to work with, was overqualified for the job, and would have thrived in it...

The HR person was a complete dolt though, and didnt even understand how to interview me properly...

Sucks - I still respect the company, but their recruiting method was piss-poor..

It does tell you that the people working there practiced leetcode and puzzles in their free time (assuming they went through the same filter)

Hilariously not in many cases. One of my old jobs introduced leetcode, particularly trees for interviewing. Nobody currently there could solve those.

But a new engineer was assigned to handle interviewing and it was all about a couple of leetcode problems he found on the internet.

Parent commenter.

The job description was top notch. It was a clear description of what they needed this engineering role to do. Inspire of it being a bit of a niche, I had almost perfect set of experiences from my prior jobs that made it very interesting.

Fun because it would have given me an opportunity to _improve_ upon my already bootstrapped skills. Productive because, I already have a head start than another engineer getting into the groove of things. This is HN, I can be tech specific :-) I have worked a lot on performance from HPC perspective. The job was at a High Frequency Trading platform that needed a sys.engineer who would work on extracting performance with things like pinning a CPU core to a process and several optimisations at the OS and kernel that would shave off a few milliseconds in an already fast application.

It's even worse when you crush every other part of the process, including take homes, and then get blown out due to one idiotic contrived puzzle.

Keep in mind that even if the job would have been perfect for you, the company probably interviewed multiple people, and selected one that they thought would be more perfect for them.

I recently did a round of hiring for my team, and we had several excellent candidates, but could only hire one, so we made a choice.

It’s always sad (for me) because I tend to see the potential in almost everybody, and wish we could hire all the people.

Where on the planet are you and can you send the dropouts my way? This feels like alternative reality - we have jobs available but no takers.

pay more

Not getting the job at a company that hands out irrelevant discriminatory interview tasks seems like a positive outcome to me!

Or you dodged a bullet as they probably also fill their day with useless crap that adds zero business value,but checks all the boxes. You might have ended up equally annoyed at your co-workers and management.

I agree with your overall message, however there's a subtle implication that some malevolent entity is putting up this awful process. In many companies, it is the engineers themselves that are creating these roadblocks. Most of them with good intentions even. I do wish that internal dissent was higher, but it's more common for new hires to be dragged along by inertia, especially since being hired often feels validating and equated with a fair process.

It’s a numbers game really depending on the role and the hierarchy level, though? I mean, we should know in advance what to expect by going into that process, and the cohort we are willing to join. It’s just a preliminary fit, at any level. If employers want prospective employees to bark and you enter that race, you bark.

You can’t really fight the system. We have to realize that those that got into these positions used that opportunity to put these gates in place. The only way to change the system is to get into the system and then break the cycle and advocate for alternatives.

But the enemy has the high ground at the moment.

Reply on news.ycombinator.com