It’s a small “api service” that represents a POC with some bugs and bad practices. I tell them to look over it, write down notes on how to make it production ready, setup a time to discuss their thoughts in a second call. No code writing necessary.

It ends up being an excellent Rorschach test where folks can really show/express their unique skill sets and experience. I ultimately let them drive the conversation and it gives me great insights into what experiences have shaped their career and what it might be like to collaborate with them. Best of all it does resemble what some of their day to day might look like better than hand crafting some tree algorithm.

It was a very pleasant experience from this side too and allowed me to express all of my domain knowledge without making a significant investment. This is such a great approach IMO.

Ffs is that never going to go away?

So it needs to be asked for in interviews, and if you find it and discuss it you're apparently one of the "better" programmers. The bar for being a passable programmer is literally on the floor.

It’s a well-rounded examination of how someone can contribute to the development of a product. That such a well-rounded assessment happens to include examining your likability or “other emotional response” is just a byproduct of testing how well someone interfaces with other humans - part of the job almost always.

Everyone has had to do a terrible group project in school where the group dynamic was just not there and the whole thing suffered, despite all the smarts being at the table. This is to attempt to avoid that exact same thing from happening, because often you just don't have the time to flub around telling someone how to document something properly for the 10th time.

That doesn't mean you got to fit some tight social profile, far from it.

But since we're a small team each person has a lot of responsibility, and so we need to trust the right decisions are made for the right reasons, that communication won't be an issue, that you can handle dealing with customers for projects and troubleshooting etc.

We don't need the best skilled coders. We need developers who're good at finding solutions to our customers problems, within the constraints of us being a small team with limited resources (time most of all). We need someone who's capable of learning new technologies as the needs arise, and we need someone who can communicate well within the team and with our customers.

When I got hired, my actual coding skill wasn't really a topic. I didn't get a single programming quiz or similar question. They were far more interested in my background, what sort of projects I had been working on, what motivated me etc.

A good example: I had an interview earlier this week for a full-stack role and the inteviewee had recently come off a two year project that was heavy on react. The project he'd be on has a jquery frontend. I told him candidly that the project would likely never make a "modern" refactor a priority, and asked him if he could still be happy in a role that used jquery.

Our full-time team is small and ensuring we can all collaborate and work together is very important for us to be effective. On the flip side we try to be transparent about what our team looks like too and give you a chance to decide if you could be locked in a room, hashing out which circle talks to which on a whiteboard, with us.

It's probably a better use of your time than studying leetcode.

I found that to quickly tell you if someone can write programs. Surprisingly (and maybe not surprisingly), a lot of people can do difficult leetcode questions, but can't write a small app, or can't do it well.

It'll quickly show you about how the candidate can come up with some level of UX, handle OSish level stuff, how they structure and think about their code and readability, how they model data, and depending on the app you ask them to write, it could include a little algorithm in it as well.

There is an abundance of people more than “good enough” for roles at FAANGs. They may simply not be stellar at the examination process used by FAANGs to assess candidates.

As much as many folks at those companies might want to partake in some fart-huffing and call that a predictor of engineering excellence, it’s not. It’s an optimization to shovel candidates at scale, and intentionally throws out ton of exceptional and even over-qualified individuals to instead hire a predictable style of engineer with as little investment as possible.

Saying that a certain $PREDICTOR is bad in itself doesn't say much, in particular it doesn't say whether there's a better one available under the same constraints. Widespread leetcode interviews is just an indication that large companies have not found a better predictor yet (again, under the same constraints with respect to time, budget, etc.).

Eh... maybe some do. My experience is that they hire people they already know. In fact that's how I got hired at a FAANG company. I had applied there many times and been rejected. Then I saw that a team where I was a great fit had hired someone I knew and had an opening. So rather than submit my resume through their job board, I sent it to him and he passed it on to the hiring manager. Most of the rest of the team got hired because they were all a team at another company that got cut. One of them got an interview and said, "Hey, I have about 20 coworkers who just lost their jobs and already know all the stuff you need for that new product you want to write. Why not hire them all?" And they did.

Sure, there are a few who went through the regular recruiting path. But many did not. I'd say on my team, most did not. (And they're all good engineers, too.)

And look, I get it, it's frustrating. I share in that frustration as someone that wants to switch companies but knows that I will have to put in the effort outside of work to prepare for that. But I still think the process is much more meritocratic and predictable than virtually every other industry.

Forgive my curiosity and desire to make things better.

> If it wasn't working well, it would be changed, just like the brain teaser questions of the early 2000s pioneered by Google.

This is a gigantic assumption, though. Tech has been exploding for a long time and basically all companies are ravenous for engineering talent. It’s not at all clear to me that this interviewing process is the cause of this growth or in spite of it. If I had to guess I would bet they’re wholly unrelated.

> And look, I get it, it's frustrating. I share in that frustration as someone that wants to switch companies but knows that I will have to put in the effort outside of work to prepare for that.

I have no problem passing these interviews, I just think they’re silly. Their prevalence in the industry frustrates me because I think they give an unrealistic portrayal of what’s important in software engineering. But then again my greatest area of expertise is legacy software maintenance, which is the work that nobody else wants to do.

> But I still think the process is much more meritocratic and predictable than virtually every other industry.

That’s an extremely low bar.

My favorite approach that I’ve seen is Latacora’s hiring process, in which they give you a work sample problem that can be graded quantitatively in stages as well as any prep materials that you need for it.

There's not much evidence that they are doing the best at hiring for those wth 7+ years experience by using said interview styles.

The point is to remove wiggle room. It's a domain-specific solution. Note e.g. DeepMind don't hire the same way.

Their number one problem is automating the beurocracy at scale with people who are fundamentally not that good at evaluating other candidates, or more likely don't care if they make a mistake. Everything else is downstream from that. Copying them without understanding their objectives is a mistake.

Because of covid-19 there are overwhelmed programmers, newbie and veteran on the job market to compete with fewer programming openings. Companies have reasons to be extremely picky, and job seekers either to comply with the game rule (Leetcode) or consider to change career.

And those who have job also need to consider to regularly practice Leetcode (one or two questions per day or every other day) to stay employable.

You really need to have some basis for confidence that the candidate is a good fit before you put yourself and them through that. Even for entry level jobs where what they know coming in isn't too important, you want smart people who can get along with the team and learn.

This is admittedly still biased towards people who have available time, paid or unpaid, but I think it's a step in the right direction.

This is basically what all engineering disciplines do and it's why I take "software engineer" with a massive grain of salt.

On a side note, of all the choices I prefer a take-home, as long as it is timeboxed to no more than 1-2 hours.

I have yet to see a 1–2h take home test actually be doable in that amount of time. It’s more like 8–10h to get going, have something meaningful, and code that isn’t inscrutable.

One company gave out sample code and asked me to optimize it so it ran under 5 seconds. The exercise was in parallelizing or caching/reusing what you could per the requirements.

it was great because:

- problem statement clearly defined

- skeleton code provided

- about 2 hours to complete

- solved an actual, real-world problem

The pressure problem can be solved by giving more time than what would be expected in a work setting. If you expect a task to be completed in 1h, just give 2h. Of course that implies that you don't give a task which would take an expected 6h to complete.

Of course these are things to consider from the company side, if they think they want to hire people who can program under high pressure, they should probably keep that as part of the interview, for both the company's and interviewee's sake.

Interview pressures and job pressures are completely different.

But like with AMA, they would (and does) gatekeep. What kind of policy can the organization be instituted with so that gatekeeping is impossible?

Doctors _should_ be a dime a dozen. They should not cost so much - because their services are valuable and therefore, more of them should be produced to make medical costs lower.

Software engineers, if they followed the AMA model, would cost $500k in student loans to train, and there's be barely any graduates to fill the demand.

Physician salaries make up about 8% of medical costs. And even if you doubled medical school class size, you wouldn’t get 2x the doctors because there aren’t enough resident slots available.

And even if you had enough slots available, you’d still need to guarantee high salaries afterwards. Most people who are smart/driven enough to be doctors aren’t going to work 80-100 hours in a high stress position for 3 years if they are only going to come out making $80k.

So the only way to drastically increases (3x,4x) the supply of doctors is to drastically decrease the standard of training.

So you reduce residency down to 1 year and you triple the number of doctors. Now you’ve reduced the quality of doctors, and you save people less 5% in healthcare costs, but no one even notices because that number gets drowned out by the continued rise in the other 92% of healthcare costs.

Of course companies are going to do anything they can to reduce prices. And of course the industry is going to put out flattering white papers in support of their cost cost cutting measures. Yet those reduced costs haven't been passed on to consumers or measurably improved medical care, so the argument merely that the industry is doing something is a poor argument in favor of it from a consumer/public health/societal standpoint.

Some companies love to outsource labor to countries with relaxed labor laws. That isn't a convincing argument against the need for labor regulations.

It may make sense to do this for certain disciplines, like software tailored for other engineering disciplines (think medical grade software, airplane/car control software, etc.).

However for the broad mass of software projects, certification makes no sense and is in fact much worse than what we have now. Do you think certification can't be gamed? It will usually be much easier to game that one since certification by definition is meant to be achievable by a broad mass of people. You don't build a certification program for elites.

Professional leetcode programmer? Sure. So let's count the facts we have at the end of the interview:

* You can code yourself through a number of problems, answer follow-up questions that dig into random specifics of your problem, slightly modify the problem, etc. You can demonstrate structured problem solving, ad-hoc clean code and you make an overall good impression in that performance.

* You are able to demonstrate the necessary experience through targeted behavioural questions that probe deeply into specific aspects of your job history and alignment with the company values

* You are able to design a complex software system and are able to answer unknown follow ups and able to follow drill-downs into random aspects of your design.

Congrats, you are a professional software developer. Can you game the leetcode part? Potentially, however I met several "leetcoders", some of which were even kind enough to put that on their CV... They usually fail quite spectacularly at random follow ups and modification to the problem statement. But even if you are able to somehow "wing it" convincingly, you need to succeed several times and you need to still demonstrate the adequate proficiency in the other two pillars (behaviour and software design).

What we might need is an "interviewer" certification.

Shouldn't the process itself be biased towards people who can enunciate their thoughts anyway?

Take home projects just make the hours overt.

Contrast to whiteboard interviews where I've been assessed on how to calculate the number of moves of a knight on a chessboard given position X to position Y on a whiteboard in front of three people as a front-end developer. Contrast to take-home interviews which basically function as a way for the interviewing company to save on time and money by putting the whole time-investment on the interviewee.

Could you explain this a bit? I'd have thought this is the only real way to judge someone. People will lie but figuring that out is part of the process.

Other orgs don't have recruiting problems that FAANGs do. They can do better than imitating FAANG processes. They can afford to go wrong and self correct more. They can find a strategy that works for them which can combine whiteboarding, pairing, casual conversations, references, real life problems, letting the candidate showcase their work.

The problem isn't that they don't work and they gave up, problem is they aren't trying.

But I know from college applicants that take-home end up at the bottom of the pile in terms of priority vs in-person interview with a real engineer. Unless it's FAANG of course.