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.

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

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.

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.

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.

Example:

Breadth first search

Recursion

Binary Tree

Etc.

Then it’s more a classification problem.

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

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.

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.

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.

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.

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

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

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.

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.

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.

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).

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.

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

source?

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

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'

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.

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

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.

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/

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.

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.

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)

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.

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.

- 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.

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.

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.

Sorry, what? Which ethnicities are these?

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

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!

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'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.

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?

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

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..

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.

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.

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.

But the enemy has the high ground at the moment.

An implication of this is that the optimial interview process -- from the employer perspective -- will have a lot more false negatives (good candidates rejected) than false positives (bad candidates accepted).

So it could correctly be optimal for the interview process to be so onerous that most job-holders would fail their own interview!

A process where you optimize for avoiding false positives makes sense.

Most companies are not Google though, and if they are <50 employee - it's absolutely the opposite. 1. It's fast to fire people 2. Missing out on a great programmer for an average one makes a huge difference!

So, it follows that they should optimize for avoiding false negatives (rejecting a great candidate), without worrying too much if they got a bad apple snuck in.

This is true also for places like Germany (and Europe in general afaik) where the cost of firing someone past their probation (6 months) is very very costly, especially for small companies.

IMO, at-will employment should be something the employer and the employee should negotiate and not imposed by the state or the employer. Unfortunately, it's usually the employer who has the upper hand.

"I'll work for you but only if you can't fire me" is something only the most desperate companies would accept unless they are forced to.

Yeah this would be a red flag on the candidate immediately. What I meant was that the negotiation should be on the notice period not on being unfirable. I see it's a huge burden on the company to not be able to fire someone and what ends up happening when you have a bad apple is other team members start leaving.

Sure, but the really bad hires usually aren't bad because they lack technical skills. They're bad for reasons that end up in HR. You can always reassign someone with people skills but short on algorithms.

Firing an asshole who is incompetent is one of the easiest things to do and it can be done well within the probationary period, heck even an asshole who is fairly competent isn't a big deal and can be a complete morale booster and likely will not have resulted in much lost productivity.

I'd say most of the people I fire are not so called "HR liabilities", and in general most people are good people. But most software developers are not competent and in some cases that realization can take a year or longer in domains that require a lot of ramp up time, training, and investment. It's often a lot better to avoid hiring people who have even a 20% chance of not working out.

My advice for these sorts of tests is to make it as short as possible, and use the test to give you something to talk about in the follow up in person interview. Replace "Invert a binary tree/solve this riddle" with "Why did you do this in the take home? What would you do differently if $FOO was now a requirement".

I find it effective.

To answer the OG question, I'm sure I would do well. Depends on the other candidates on whether I would get the job though.

I've gotten data science ones where you could spend anywhere from an hour to an entire career working on that one particular problem. If it's meant to be a simple pass-fail exercise, say so up front and reserve the interview for discussing how the solution could be improved.

I really liked this since it gives plenty of room for discussion, leaves you a lot of freedom to chose your tech stack and make a case for it.

The thing that I find the most useful are the responses I get when I point something out and ask "why did you take this approach" or "what would you do to go faster" or if there's a bug, "I don't think this is doing what you want it to".

I absolutely grade this on a curve -- Entry level and data science backgrounds almost always go to pandas right off, front end people will be focused more on the UI side of it. But if you're senior and come at me with an O(N) or O(N^2) solution then I'm going to really want to know what you have to say about the performance question.

... and?

I wasn't suggesting that we had existing devs do the take home, realize it took 30 hours, and then thought that was a reasonable request :D

The worst case scenario for us is someone who has clearly spent a long time on it, against our wishes, and done a poor job. Optimizing to not have the happen is a comms challenge.

Something relevant to the work I do all the time? yes, I'd probably pass.

Something about some data structure or algorithm I haven't needed to use in four years that i now have 30 minutes to implement in code? I'd likely fail.

When something comes up in my actual job where i need to solve a problem i'm not familiar with, i first do some research on the problem and learn/remember what i need to know about it and related algorithms/data structures before doing any actual coding.

i certainly do not "immediately write code as fast as possible" when presented w an unfamiliar problem.

if you must ask candidates to work on coding problems, i believe that you should give them 3 or more problems and let them pick which one to work on for the actual "coding test" part of it.

Then maybe have a conversation about the other problems to get a sense of how they would think about/approach them w/o actually making them write code.

At this point though I just stop the interview if they’re asking Big-O or data structure questions. If the company can’t come up with meaningful real world examples that actually explores my experience, I don’t want to work there.

I do the following in JS:

- General graph algorithms (shortest path, backtracking based)

- Traversals for graphs / trees (depth first, breadth first, iteratively, recursively)

- Heaps (min, max)

- Tries

- Matrix manipulation / traversal. This is a very error prone for a lot of folks even though it looks simple when they need to write it by hand, and I always need to putz around with 5-10 problems.

I have enough exposure to common interview questions that the above is generally enough.

If you want to talk privately you can reach me via twitter DM at https://twitter.com/@jitl or jake@makenotion.com

Thus, if you interview those promoted employees, they are not going to match external candidates unless they have been in the role for a while and are now excelling.

Additionally, you evaluate external candidates much more heavily on raw skills b/c they have no internal knowledge/experience, but you include that internal knowledge/experience when evaluating employees.

Finally, interviewing skills != working skills. I've been writing software for 20yrs, and interviewing SDEs for almost as long, and I'd still do interview practice to prepare. In a normal job I can go search the details of what a red-black tree is, and find a library to use it (or spend a few days implementing it). In an interview I need to already know it and be able to implement it myself in less than an hour. (yes, that sucks, but it's the reality of interviewing today)

Other close people I've asked before:

A, at Google, got in 10+ years ago. Told me she would not pass the current interviews.

B, at Google, an aquihire, 5+ years ago. Told me he would never have gotten in the front door (leetcode) way.

C, at Netflix, got in 5+ years ago. Told me odds are he would not pass if he were interviewing today. He says he is in a very interview un-ready state, and none of his realworld experience working at Netflix would help him pass his team's interviews.

The technical interview is broken and has been for a long time. I'm sad that as a society we accept leetcode or unrelated system design questions as a means to measure proficiency.

The standard continues to rise in certain companies and lowers in others.

I'm sure if I was in "interview mode", I could pass, but my position is not about knowing how to invert binary trees.

The Big Tech companies have standardized their interview process around hiring new grads. They fight with each other to hire them. These noobs get hired en masse and perpetuate the process, ultimately creating a monoculture of noobs hiring and mentoring noobs. It is the blind leading the blind.

So Big Tech companies end up consisting of armies of highly uniform noobs that throw massive amounts of code/money/people/time at every problem. And not because they're stupid, but just because they never had the benefit of real mentorship and training from a diverse pool of experienced experts. And because they've never learned to build without the resources of a Big Tech company.

On the other hand, good startups seek out experienced experts with diverse technical skills because they really need the most effective people possible. They're not just trying to meet recruiting quotas. They have to do great work and have to do it efficiently or they fail. This is why good startups can very often do much better work than even much larger Big Tech teams.

If you're an experienced expert, and actually enjoy your work, you probably want to work for company with less than ~300 people. And you probably want to quit when it gets to ~1000 people.

The other alternative is to be a founder, but not everyone is up for that.

Yup. I didn't get blasted by algorithms problems and data-structure trivia for my current job. The interview I got was to answer a handful of questions by querying some data from a CSV file. I was supposed to use the programming language of choice by the company but I just loaded the data into a SQL table and did the queries in SQL... which was fine because the application I'd be working on is a web application and the majority if our work is querying databases.

Could I get through the usual interview process at other companies? Sure. I'm used to it by now and came up with a training regimen to keep my skills sharp. It really comes down to being able to categorize word problems into a handful of common data structures and algorithms: breadth-first search, depth-first search, two-pointer, binary search, dynamic programming... linked list, vector, hash map, or tree. Once you can match the description to the data structure and algorithm the solution is usually within reach with practice.

It's not my favourite skill and I don't find competitive programming entertaining. But that's the way the world works right now.

My company recently switched from a code submission to a hackerrank type thing. As part of that switch, several engineers of different ranks (junior, contributor, senior, staff, etc.) took the quiz to benchmark the platform. My score was second-to-last, despite being the highest ranking engineer.

Otherwise, it basically lined up, so we made the switch. It’s certainly possible that I’m under qualified for my position, but I also suspect that these assessments have significant false-positives and false-negatives, the consequences of which will be hard to measure, and therefore ignored or mis-diagnosed.

For myself I can say a definitive yes for 2 reasons - the first is at my current job all the interviewers test run new interview questions as a filter. If a preponderance of don't pass the question we don't use it. the other way I know for sure is that I have been actively interviewing for new roles in a lateral+ capacity. With an n<10 I have 100% pass rate into the interview process and a 75% rate of offer. My prep for interviews is Linkedin sleuthing of the companies and interviewers. If I ended up in an interview process that was asking for me to balance a tree I would likely fail, but I would also not want a job at a company that uses that question. For reference I am a top end IC (principal/architect/lead/etc.) with 20 years in complex web app dev.

I only got in because I happened to do the exact LeetCode questions asked the night before, and the questions relied on knowing special tricks

I really doubt when people say they got in to LC heavy companies without studying much, its more likely they just lucked out and got a question they happened to be able to solve

For any candidate you can create an arbitrarily hard/tricky LC question they won't get

I suspect the new grad FAANG recruits are at an advantage here (dubious though it may be), in that they are ready to grind from the get go. Those of us that started out in a different place are running into the hazing later in our careers and there's this existential crisis of "this isn't fair" and "am I a terrible engineer" and "screw them". It took me a number of years to move from denial to acceptance. I still posit that being able to pass these interviews have not made me a better employee, just a better interviewee.

I have been working in the same job for 10+ years. I was hired as a somewhat lower position than my current one and promoted over time. I am not sure my organization likes to hire "senior" developers - so I don't think "my" position would be available. They would probably split the work I do now into two junior positions.

This hiring pattern doesn't seem uncommon in my area. You see lots of junior-level positions kind of rolling around the typical job listing sites with very few senior roles.

Over those 10+ years I have done two or three more serious job searches. I tend to get offers but they are usually lateral moves. Meaning, roughly the same salary and work. I have some uncommon benefits at my current role so when I go on the job hunt I am typically looking for either a significant bump in pay or in work specifics (inspiring peers, programming languages, etc) or it isn't worth changing positions.

I would say that if you see interesting positions, have a go at it! Don't wait. And this is especially true if your vision for your career isn't on track to being fulfilled at your current job.

P.S. I'm not defending the current situation, I am merely trying to summarize it from the a practical point of view (i.e. action X increases the chance of outcome Y).

But yes, I've definitely encountered interview questions posed by a company I worked for that I probably would have flunked. And I've tried my best to push back on those, when it was clear that they were designed more as an ego booster for the person who designed it than as a tool for accurately assessing skills necessary to perform well in the open role.

One thing I would recommend, for companies that have similar issues, is to lean more on your most junior and most senior engineers, rather than mid-level and early senior engineers, when crafting things like coding challenges and architecture/design sessions. They're often the ones who will approach the task with the most humility.

IMO, being under pressure in an interview stunts a person's cognitive ability somewhat, between the pressure, the unfamiliar environment, lack of working relationships with the team, etc. I think that would need to be factored in somehow.

UK based, financial sector, FWIW.

That said if I was looking to move, my confidence about other places being so sane would be low to medium, there seems to remain a lot of deterring approaches out there still.

Would i pass my own interview though? Not sure. The depth of knowledge is reasonable, since i craft my own questions i know the answers, but they are not standardized. They are tailored per resume. So depending on how i read my own resume, i might come up with questions that i don't answer adequately.

Many years ago however, I got into a FAANG via a "side channel", working as a a support engineer for ~1 year before I managed to impress a manager in the proper product engineer org (whom I and my team worked with closely), and didn't have to suffer through a traditional FAANG style interview as a result. Best opportunity of my life on accident, turns out. Pretty sure that on my resume opened more doors for me than anything else.

I'd never pass that interview process, yet proof is in the pudding that I did well, I rose the ranks over 5 years before leaving due to not wanting to relocate for a bigger promotion.

And we are hiring: https://www.mcg.com/about/careers/search-jobs/?gh_src=266419... (Feel free to email me at the address in my HN profile to ask about the company)

It isn't that people are more pragmatic when hiring a contractor. But in fact contractors are hired to do specific tasks. These days, your traditional software engineers are asked to all sorts of things and asked to learn all sort of things as the company grow. I think that there was a probably a time where the scope was limited and recruiter knew what are the problems a candidate might need to fix. Tech stack wise I would guess we are in an era of ambiguity.

Disclaimer: Haven't worked a day as an employee anywhere.

But only because the vast majority of our focus is on the person - their character, attitude, what drives them, what motivates them, how do they treat others, what are their communication skills, etc. Very little is spent on technical capabilities.

This has served us well, but hiring takes longer and is more involved. A lot of people fall out of the process early on, but it is totally worth it.

I understand the need to narrow down candidates but this kind of screening is about as useful as throwing darts at a dartboard.

There’s a risk that leetcode heros might turn out to be the type that throws up their hands at the sign if smallest of team friction points. As a Pm these devs are the most annoying. “That other team didn’t respond so I’m blocked”

Leetcode questions don’t help with this important criteria.

I would. I wouldn't ask hackerrank, leetcode or google-interview-type questions though, requiring knowledge of specific algorithms. I would ask questions about the programming knowledge that is relevant for my role. Since I'm in frontend, I would focus on finding out how well the candidate understands javascript (and these days, probably typescript as well), css, and browser apis. This and talking through the problems, I believe, will give me a pretty good signal about where the candidate is at.

However, I would not get the job because I wouldn't pass our in-house recruiter's phone screen. We recently did interview training, and got an explanation of what kinds of questions HR uses to filter out candidates, and when I pointed out that I would be thrown out after the first two questions, despite widely being considered a great culture fit, all I got was a shrug. :(

My question scales. It has 5 parts, such that a bootcamper can solve 1 and 2, and completing part 5 would require a whiz to spend several hours. That is, however good you are, I'll be able go get a good signal, see your thought process and you'll come away feeling mostly good.

You don't need to find the best people for a position, you need to find the ones that meet the requirements that you should have already set. If you're changing those requirements during the interview then you're doing it very, very wrong. It's fine to ask additional questions to get a better understanding of how well someone will fit, but that's completely different than moving the goalposts as the interview progresses.

Wait for "the best people" and you could be interviewing for years.

New interviewers are required to calibrate their expectations for the question by practicing conducting the interview on 3-4 existing employees.

By evaluating on dimensions you don't have to study for & calibrating based on active employees I like to think this does a better job of making sure we don't miss out on hiring good engineers who haven't spent hours doing LeetCode.

I've interviewed many senior engineers who can't code, and worked with principal engineers who can't design/lead. It's painful and hurts the whole group.

The solution is to make the process of hiring/firing "cheaper" so that companies are willing to take more risk, but I've not seen a process yet that is fair to the candidates.

If we had UBI, it would help a lot - people could quit jobs that suck, and companies could more easily hire/fire people without destroying their lives.

I don't believe they're any harder than the interviews I had to perform 12-13 years ago. If anything I think they're easier, because I remember a lot of weird trick-logic "Google" questions during the late 2000s that didn't even touch programming or software.

Algorithimic/coding? _maybe_, not confident in the least and would lean towards "no", simply in that my preparation was significant. I also push back in current company (FAANG) against the strong algorithimic/coding pushes as I don't think they are a good signal for skill/employees.

That being sad, where I am (Netherlands), interviews haven't gotten noticeably harder. 20 years ago I had an interview where I was asked to implement polymorphism in C on a whiteboard. The other year I had an interview where I had to implement some kind of graph sorting system related to blockchains. I failed them both, and went on to find a load of other companies that were a bit less silly.

My overall impression is that it's big tech companies in the US that have become obsessed with coding tests, hankerrank and leetcode and the like. I don't know why, when half of them are complaining about acute talent shortages... (Facebook?)

The take-home project followed by discussion is great, but can it scale up to Facebook and Google? Are you going to have engineers doing several of those per week? It's already difficult to come up with algorithm questions that are novel enough that candidates haven't already practiced the exact question, as found in some aggregation site. How do you avoid that with project work?

I agree the system is terrible, but I see how we ended up here too.

As I have been applying a lot lately, I was told by several recruiters that they are getting ~250 applicants to each seat... and most times, thats the only seat in a company - and the applicants are coming from all over the place now that WFH / remote is so much less stigma'd...

I've long come to terms with how much randomness plays in the interview game.

Interviewing is a numbers game, so play the game and fail/succeed quickly! I usually put out 25-30 applications a week, accept maybe 10-15 initial calls, and get an offer or so every other week.

It's a candidates market and companies know it. If I receive a request in an interview that I don't agree with I just say so. Leetcode for a Senior role? No, get rid of it or I walk and take another offer I can pick up in a few days. Just refuse to do anything you consider below your pay grade.

They leetcoded and had interns do system design diagrams. Intermediate and higher had paired code writing and a design discussion.

Joking aside, I would definitely pass the interviews for my previous job (I left 4 weeks ago). They were very JS and React focused, and they were pretty easy. I know that domain well, so I tend to interview well in it.

Where does it end?

Most "system design" interview material online seems to focus on web stuff where you setup multiple servers but my experience and my interviews usually involve designing an app or some other mostly offline system that would be implemented in C++.

The average software we build is more complex than before too. I guess that's why interviews have become harder.

I think I have done around 100 interviews as interviewer too and the biggest problem I see is that many of people that advocate different training programs for passing interviews have wrong idea about the interview process.

You shouldn't practice for puzzles. The whole purpose of live coding interview is to see how you communicate and how you approach to solve a new problem. Nobody expects you to implement algorithm in less than an hour and without studying it first. Nobody actually expects you to complete the assignment, even though it's definitely a plus point if you do it. That's the only part of the interview process that doesn't require practice in my opinion (if you know how to code). Instead you should practice your communication skills, debugging skills, best practices, and focus the actual requirements for the job. If they are building distributed systems, they are obviously looking for talents that at least understand distributed systems.

That's how it was done at my previous employer, too.

2. Wouldn't copying FAANG hiring practices (if you are not FAANG) ensure that you will always get their "rejects"? Where you will always have an inferior talent?

I've always found such questions lame, because (1) you rarely need this kind of thing, (2) when you actually do, you can find the information within 5 minutes, and (3) if you don't know it, well... you're not gonna suddenly come up with somebody's PhD thesis during a stressful job interview.

And you may say "yeah, they don't expect you to, they just want to see how you think". That's bullshit, because people know this questions come up often and will sit down and study them in order to game the interview process.

And companies explicitly send prep material now. When I interviewed for Amazon, I got a whole pile of links to study.

I realized that when given to a candidate, we don't just throw the question out and come back an hour later asking if they've solved it. Part of the job of the interviewer is to keep the candidate on track, and gently guide them in the right direction if necessary.

All of the questions were much more reasonable (and approachable) when there is someone who is motivated to help you reach a solution within the allotted time.

I'd still prefer the whiteboard interviews, over what are sometimes knowledge-based questions that are a search away. Not the common stuff that you should anyways, but something obscure that if you spent 5-10 mins on its man page, you will get it.

In my current position I constantly improve my skills to fit a variety of projects and facets of a single project.

Unused skills atrophy all the time.

My skill set is dynamic, adjusting to a variety of conditions and needs.

My core skills are qualities - curiosity, enthusiasm, quick adaptation, quick learning, communication, understanding logic, attention to detail, ability to visualize software as factorio-like machinery, skepticism and paranoia/trusting that people will try to do things wrong.

If I am asked to write a sorting algorithm I shall not pass. Therefore, I will never ask anyone to do so in an interview.

I prepped on that and some other material recommended by the guy that referred me.

That’s all been changed now so I’d be going in blind.

I bet the same is true of lots of engineers, too (that’s not my field, either.)

Just for point of reference.

I’ve never seen anyone hate their product and love their process quite like that, before or since. It was breathtaking.

No, absolutely not. I am a senior front-end engineer with 24 total years experience and about 15 years of full time employment in the corporate space.

I have enough experience that I can build most any kind of application that will execute in the browser. Given my level of experience I can execute pretty quickly. For my current side project I wrote a complete OS-like GUI in the browser, including file system display, in about 15 days. Its mostly WGAC 2.0 AA compliant and performs awesome even when scaling to an absurd number of GUI windows in the display.

Of course, if I approach any problem space that I have no experience with there will be some required learning time. For example I have no experience with graphics processing, so if I were tasked with rewriting Photoshop for the browser I would slow down figuring out how to write the tools specific to that class of application. If I were tasked with writing an accounting application I would have to learn how some basic accounting things work, and so forth.

Experience and competence will not get you hired writing JavaScript. In fact I will argue, as I have observed from interviewing this year, that you can be neither competent or experienced in this language/platform and be hired for an incredibly high salary, even at stable established big companies, if the other conditions are correct. I was having no trouble pitching $170k in a low cost of living area and requesting full time remote.

Hands down the most important consideration for employment writing JavaScript is appreciating the most popular tools. The most popular of them all at this time is React. To prove this visit this month's Who is hiring thread and do a CTRL+F for TypeScript. Around 90-95% of those positions require ReactJS.

https://news.ycombinator.com/item?id=29782099

Hiring aside, why would somebody with my level of experience spend any time with a large framework like that? It will dramatically slow down the performance of my applications, thanks VDOM, and inflate the size of my code by several times. It will also slow down my speed of delivery by an order of magnitude because there are addition technical concerns and more to test for. Then there are all the dependencies and additional build steps and plugins and all the other luggage that I don't want or need and that I certainly don't want to force onto my users. Worse, is that without all the nonsense the front-end is only a tiny part of any major application. Like insignificant trivially tiny compared to the rest of the application code even after accounting for accessibility, security, and cross-browser concerns. All the code swell is tech debt that increases maintenance concerns by orders of magnitude.

At this point I am already immediately disqualified from continuing employment in this field, but there are other more subtle secondary concerns resulting from tooling that add up to widen that gap.

Its interesting, because I went on a bunch of interviews, this past summer/fall. Never, in those discussions, almost never did anything knowledge related about the technologies/platforms come up in discussion, which I found very strange. There would be some knowledge questions about how the language works from a very broad level and how to asynchronously transmit data, but that's it. You would think if you were hiring a Node.js engineer there might be some Node related questions or if you were hiring for a browser related engineer there might be some browser related questions. Weird.

I still loathe IDEs, because they appear to me to be pure bloatware that wants to even help you pee. (Command line linters work just fine, IMO. I don't need to run bloatware to find typos and syntax errors.)

> If you were the one doing the interview, would you be strict and request more things so as to filter out candidates? It’s understandable because somehow you need to find the best ones for a given position, but there are some soft skills that C/Java/Python interview problems can’t identify.

I have interviewed many candidates. I generally gave three rankings to the hiring manager - pass, minimally acceptable and very good should follow up. Candidates tend to be a Gaussian curve with a normal distribution - if their resume looks good and they have been doing the job for at least two years and they pass a simple phone screen, the bulk (two thirds) follow into the minimally acceptable category. They know the basics and obviously have been doing it, but their knowledge can be spotty, and probing in depth almost never has results. Maybe one in six slip through the initial filters of resume and phone screen and show up at an interview knowing next to nothing. On the other end is the other side of the standard deviation - someone whose knowledge has few if any blank spots, and who can answer questions in depth.

I've found I can usually tell if they don't fit into the successful group in the first three questions. I have never had someone who flubbed the first three questions come back and answer subsequent questions correctly and in depth.

Of course having a recommendation internally helps. People I have deemed minimally acceptable who have been vouched for by a teammate have been hired. If they're coming in cold, they have to be in that one in six, one standard deviation above group who have some grasp of almost every subject you should know, and can go into depth on a lot of things.

So from your view being interviewed, it is pass/fail. From my view, I am looking at six people, one obviously bad, four interchangeable who have slightly spotty and not in-depth knowledge, and one who shoots the lights out and can go in-depth on a number of subjects. The last one I pass I bring to the attention of the hiring manager, the others I say they're minimally OK, with the occasional pass. Sometimes they're doing great technically but I know the manager will pass on them because they won't like they're attitude, but I pass on them anyway. Once me and someone else interviewed someone who passed the tech interview, but their behavior in the interview was odd and we both agreed to not pass them on.

Secondly:

> Is it my idea or are interviews more harder nowadays?

Interviewing can be hard.

I've been asked to show Github projects (as my IP assignment agreement might assign copyright of off-hours work to the company, I don't have a lot of motivation to do these), do work samples over a few nights, do 30-60 minutes Leetcode interviews in different languages, with a framework or without, to look at code, fix bugs, and check the code in to git, to whiteboard high level class design, to answer programming questions, language questions, framework questions, popular 3rd party framework extension questions, questions about how I deal with product managers etc. I hear FAANG grills you on graph theory depth first search and things like that which I haven't implemented from scratch since college (at work I'm usually doing CRUD or sometimes UI stuff, anything more complicated I am usually doing on my own time).

It's a lot to work a job and keep on top of these things.

I have been diving into learning some language-specific things in the past two years, and things which you can find across languages to some extent. I have done a little bit in learning the newer framework things coming out, or going more into depth on things I needed to know. If I was gearing up to interview I would probably put these things aside and learn how to Leetcode better and that sort of thing. Most of what I study can probably help me find work, but if I shifted what I was doing into learning how to do Leetcode quickly, correctly and compactly, that would probably help more. Things like that.

I'm curious what you mean by this. Software has a _lot_ rabbit holes. What kinds of topics are you looking at, could you perhaps share a small list?

For instance if you ask what generics in Java are from people who have been programming Java for two or more years, one in six will have no idea at all what they are.

Four in six might say "well Java generics...that is when a class or method uses angle brackets in its definition". OK, what is in those angle brackets? "If you're initializing a list of strings, you send String as a type argument to List - so when you're initializing a list, what is between those angle brackets is String - the type argument for the list. If you have Integer as a type argument the list will contain integers". So they have this level of knowledge of being able to utilize existing generic classes, but they don't define their own generic classes, and can't go in-depth on generics.

The standard deviation above one in six can clearly define what Java generics are, knows about type erasure and that generics are a front-end conversion at the front of a Java compiler, can give a decent explanation of what an upper-bound wildcard is etc.

A long time ago I was interviewing proto-SREs, and one question I asked everyone was what are the facilities of syslog, and what are the priorities of syslog, in order if possible. I must have interviewed at least two dozen people who were working for big and small companies running Unix servers for years, none of them ever came anywhere close to being able to answer that question. You would think they might have to edit the syslog configuration file to log different facilities at different levels to different places (files or otherwise), but I never got anywhere near an answer to this. These were people all making $80k-$120k TC (eroded by inflation since then) for a position with similar TC.

It's a hard thing to see if you haven't interviewed dozens of people, it's why it's so enlightening, especially if I go out and interview. Generally, one in six is a complete dud, one in six is a standard deviation above the others, and four of six are muddled. It's kind of like a classroom where some kids sit in the back and fail or get bad grades, a few sit near the front and always seem to know the answer to the teacher's question, and most of the class is kind of muddling along, getting Bs and B-'s, with a few A's and C's sprinkled in. For pretty much any question in the rabbit hole of topics - one person knows very little, one can answer most things in some depth, four have a surface knowledge of many things but can't go into depth on them much.

First off, I hate the "FAANG" acronym, its become a status symbol of some sort and is used so frequently in d*ck measuring contests on social media. I am cognizant of the fact that there are SDEs and great SDEs even outside of BigTech.

The reason Algorithmic challenges are used so frequently in FAANG companies is that when done properly they can be standardized pretty well with minimal source of biases. When done properly, you can observe candidates thinking out loud, communicate properly under time pressure which is what is required at most tech companies. Also, LC style problems cannot be memorized, you have to be incredibly lucky to see a problem you solved recently or the company's hiring process is so broken that their questions are already known to public.

Algorithm challenges are basically testing what you learnt in your undergrad CS curriculum, the topics are limited to fairly standard stuff you learn at university, regular DS like Stacks, Queues, LL etc and algorithmic techniques like DFS, BFS, Sorting, DP etc. Once you have done enough of these problems and understand them well enough, the LC interview isn't that tough. This is coming from someone who has been giving at-least 2 interviews a day for the past 2-3 weeks. I won't say my hit rate is 100% but I am fairly confident that given a problem I haven't seen before, I could solve it in an interview setting under time pressure. You face this situation quite frequently at most tech companies as part of your job.

At the same time, I would whole-heartedly agree that 90% of the work at tech companies doesn't involve applying Algorithms in real life. Never have I faced a situation where I have read an algorithm in textbook and applied it at work. Although, having worked at one tech company, I did see quite a few DS/Algorithms being used in real-life in Large scale services. I remember seeing Tries being used to speed up string search in some services in Exchange at MSFT, I did see clever applications of Bloom Filters, if you peek into the source for .NET Dictionary and you see how hashing is implemented in the real world. Say that the Keys you use in your real-world application are for some reason unevenly distributed and you store them in .NET dictionary, your read queries would considerably slow down and that might not be optimal for your customers. I wish that this were a contrived example but it isn't, I have seen many such situations occur at MSFT where Engineers didn't properly think of trade-offs when designing large scale systems. Algorithmic interviews can be a good filter to test these skills.

Also most tech companies don't necessarily want to hire domain experts. That does happen but only rarely and most teams are fairly generic, they aren't working in specific areas like Databases, Networks, OSs etc. I see folks saying that they are really great with specific frameworks but truth be told, Tech companies would rather hire someone who can learn specific frameworks on the job under extreme time constraints. I know that this is the exact opposite of Startups and smaller companies who need "domain experts" to ship stuff sooner. Amazon doesn't require new folks to know Spring MVC, MSFT doesn't require new hires to know .NET MVC etc, they all want developers who can pick up any XYZ skill whenever the job demands it. I know that quite a few of HN users might look down upon that and you have every right to, but that really is the job at BigTech. Most engineers are fungible, even though you cannot like for like replace engineers you lose. But at the scale that they are operating that is the only way.

Algo challenges test for raw intelligence, period. Now, even Algo challenges have varied levels of difficulties. I have heard horror stories of interviewees being asked questions that require particular tricks or complicated DS like Segment Trees etc. Unfortunately that does happen.

Also, most companies have rounds where they do test "domain knowledge", skills like OOD, System Design etc. Although I admit, these two are also beginning to be gamed. There are websites that sell "courses" for these and its getting to a point where interviewees just regurgitate info from these courses even if they haven't used them in real life at work but that is what happens when you deviate to something that is difficult to standardize. Additionally, from the interviewers perspective its difficult to judge what contributions interviewees have made to an organization when they haven't closely worked with them and the work might be in a domain they aren't familiar with, that is unless you have made major contributions to OSS, which can be verified easily.

Finally, I have to admit that in all this frenzy I just seem to have gotten lucky. I finished university four years ago. Algo challenges were wildly popular during my time and I still like solving them, although I am not as prolific as some of the folks I know in Bigtech. I did a lot of it in University and that helped me tremendously in interviewing at Bigtech. I realise that HN folks come from a diverse set of backgrounds. Some of you are much older and have familial commitments which certainly makes it tough to "practice LC" along with your work and spending time with family. In that, LC is really a young man's (or woman's) game and I have to admit that I have been a beneficiary of that. I can only soothe you by saying something cliched, Life isn't always fair.

That's because I met the principals directly and we spoke over the nanoscale particulars of a certain problem space we had both worked on and that was their basis for hiring me.

After that, there was a change in ownership and they hired the usual crop of cargo-culters and buzzword droppers and fake-it-till-you-make-it types. Who I'm dead certain would not hired me at all. Or even looked at my resume.

Even if you concede my position (and I know a lot of folks think all these questions are impossible / unfair), at the end of the day they're just a terrible signal of whether someone will be good at their actual job.

The folks that I've interviewed who really ace these puzzles often (but not always) end up writing terrible code, e.g. cryptic variable names, lots of use of indices into vector / array data structures instead of something more idiomatic like iterators and std::algorithm stuff.

My current approach is to show some subtle C++ gotchas and ask the candidate what will go wrong (e.g. where is the undefined behavior?). I don't even expect candidates to get all of them, as many of them are hard even outside of the interview set and setting. Then I ask them to write a hash table for values with large data (i.e. where using std::vector as a bucket would be a bad choice due to the 2x'ing of size on resizing) and just see what they write. The main thing I expect is for them to demonstrate that they know the stdlib stuff (e.g. std::list, std::forward_list, std::hash, templates, etc) and can explain the tradeoffs.

Surprisingly, far fewer people pass my interview despite it not being some obtuse mental brain teaser, but those that do have been great colleagues.