Whiteboard interviews are a test of obedience, not intelligence | Hacker News Reader

Whiteboard interviews are a test of obedience, not intelligence

ashgw.me

100 pointsvitaminCPP167 comments

While (live) code challenges have a lot of problems, I don't see it as a possibility to get entirely rid of them. As someone who hires engineers, I do want to verify that people can actually code. While most people who are "merely talk" can be already filtered without a code challenge, there are plenty who make a good impression, but lack fundamentals in coding or do not have the skill level I'm hiring for.

Live codings especially are a very good insight in how someone thinks and approaches a problem, never thought about obedience in any aspect.

If someone has contributed to an open source project or has some themselves, talking about those instead is enough for me as well, but that's even more to ask for imo, as not everyone has the time to create a project that is worth talking about and demonstrates their skill.

When I went to my first job interview after years building my own software product, I brought all kinds of examples of code I wrote which I felt showcased my talent (including an effective API I created for one of their services that lacked one, and code examples of mine that had been published in a textbook). The interviewers had zero interest, and just wanted to discuss superficial / artificial whiteboard-type problems and (in retrospect) how to hose more ad revenue out of users by upending expected browser behavior.

I can appreciate how some of it offered a glimpse into how I approach problem solving, but the process (not just that aspect) left a sour taste, and over a decade later I'm so glad I didn't wind up in a career position there.

If you want to attract top tier talent, as an employer you should also work to make your interview process fun and challenging, and showcase what sets you apart from you competitors. Too often firms loose sight of the fact that in the interview, they are being evaluated too.

I'm absolutely terrible at interviews, especially whiteboarding, and the best ones either involve taking a tour of my own code, or them showing parts of their codebase and me asking questions around it; or, take homes and I have a chance to explain what I built.

I don't have the memory capacity that others do to just stuff leetcode challenge algorithms that I'll never use in my head.

In my experience leetcode is not really memory heavy (except in the competitive programming scene). It’s about being able to think of a naive solution to a problem, recognize why it is inefficient, and figure out how to make it efficient, usually with DP or graph approaches.

> DP or graph approaches

I don't use either in my day-to-day. I also have memory issues around just memorizing these things. I can probably do it if I can look up how it works and then translate it.

I have a really bad memory and I don't know if it's related to being aphantasic or not (no mental imaging capacity).

Again, it’s not really about “just” memorizing them, it’s about internalizing how they work to the point where they are second nature. Like being able to apply calculus to everyday life, once you have internalized it, it changes how you think about things and analyze problems. Learning calculus through memorization will not help with that.

> internalizing how they work

And how long do you expect that to take? Do you think I haven't tried doing that before? It just doesn't register unless i'm literally doing it every day. And with so many algorithms out there there's not enough time to internalize all that.

I don't have that kind of memory everyone else seems to have.

> And with so many algorithms out there

Their point is that this is wrong. They're saying there's a few underlying principles that apply to most of these, and those are what you have to internalize.

Yeah, a few concepts like hashing, "divide and conquer" and dynamic programming is enough to solve most problems. If you understand and know how to use those and a few more well you easily ace interview questions because those are the building blocks for almost all useful simple algorithms that you get asked about in interviews.

If you think these things are about rote memorization, you’re doing them very wrong.

I see two problems with bringing in your code for an interview:

- I don’t know how long it took you to do it, and being able to do things in a reasonable amount of time is part of all jobs. Also, I don’t even know if you’re the one who wrote it or if you are passing off somebody else’s work

- it’s unstandardized across interviewees, so how do you compare? Person A wrote a more elegant solution, Person B solved a more challenging problem, and Person C did all their best work on propriety stuff they couldn’t share so they had to share show you a throwaway side project they did in one weekend

Absolutely agree, I'm always afraid of loosing out on someone great. Even the screening of CVs themselves is an incredible hard task as the best engineers are often humble and maybe not portray their strengths enough.

What I do to make the live coding challenge a bit nicer:

* I use codesandbox.io (not affiliated) as a live coding environment which is a VSCode editor that executes your code whenever you save. This makes it much more realistic how one would solve it real life. * I have them share their screen and make it clear that they can google whenever needed and that it's expected (who remembers the exact incarnations for reading a file or some API) * I only do one challenge, which most candidates finish in less than 30min. We then talk about refactoring it, building an API design around it etc. * The challenge itself is building a solver for a text based game, which imho is a fun task and is literally reading a file and filtering the content with some ifs.

Any recommendations for improvement are welcome.

I think executing code makes things too strict, and can lock up/shut people down, since forgetting a library function name means you're completely stuck, which causes a feedback loop of nervous. Interviews are high stress. Absolute precision, required to run code, is not a good fit for high stress, in my opinion. You'll filter people that haven't don't a lot of interviews more than anything.

I keep the problem relatively simple. I tell them that they can use whatever language, don't worry about silly typos, or exact syntax, and if you forget a library name just make one up. It's trivial to see if someone can code without executing the code.

If I notice obvious problems, I'll describe the incorrect behavior, like if there's an infinite loop: "I see a problem. When you run the code, you see that it never ends".

> forgetting a library function name means you're completely stuck

Just let them use Google to find documentation, as they would in a real job setting.

No need. I explicitely tell them that I don't care if they remember exact library/function names, and to just make them up and tell me what they do, if they don't remember. If you require specifics like that, you'll filter out anyone who hasn't worked on that specific very recently. Those sorts of things aren't something you should need to worry about keeping in your head for long.

When bootcamps were first becoming popular, I started inviting graduates of a nearby bootcamp to interview.

The first candidate had a few small but impressive sample projects in their GitHub, including some API development and other things that surprised me for someone with under a year of experience. I was impressed!

Then the second one came in, who also had a GitHub portfolio with the same sample projects and the same API design (with minor differences). I felt dumb when I realized that those sample "side projects" were actually something that the bootcamp trained them to develop and put into their GitHub profiles. Obvious in hindsight, but remember this was when bootcamps were supposed to be the next educational revolution and everyone was on the "college bad" train.

In a different interview, I mentioned one of my hobbies. The candidate boldly explained that he wrote a certain package for the programming language we used. I asked some more questions before realizing he was literally describing a project I had published! He immediately changed his story and claimed to have misspoken when he realized that we were on to something.

These aren't equivalent to your story, obviously. However, these are some of the reasons why interviewers still want candidates to go through the standardized testing that every candidate receives.

Comparing candidates on equal testing is also pushed very hard on us by HR. If you start judging different candidates based on entirely different standards, people get extremely fussy

> The interviewers had zero interest

I used to think the same when I started interviewing. Now I'm into the hundreds, and in my experience, that is the correct approach for a peripheral interviewer (not the direct hiring manager), and it's for your benefit.

We have 45 minutes to prove to ourselves, and our managers, and their managers, that you are the right hire. No "feelings" or "hunches" allowed: clear tangible demonstration of competence for the requirements listed, that everyone can read, and be convinced. Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected.

If I spend 30 minutes going over what you did, there are two problems:

1. Figuring out if they actually did the work, or maybe played some small part in a team, takes considerable time. It's not easy, because people are often running with inflated resumes, with the most interesting things usually being the inflation. People can have a good understanding of a project, without doing anything in that project, claiming the whole project for themselves. The path to being convinced that they actually did it ends up being very different for every candidate, and any exaggeration/lie you catch them in makes you question all of it.

2. It only gives a short amount of time to get some deterministic proof that represents the work: typing actual code to solve a problem. If something questionable comes up during then, in the little time left, you're not going to get a chance to prove it's not an issue. If that same issue shows up in anyone else's interview, without me being able to defend you, then that's it.

So, I immediately jump into my "standard" interview. It's easy. An average person will finish on time. A great person will fly through it. It checks all the boxes, gives me the proof, and even expands out into a few things that I know are sometimes questionable for others. It gives a clear yes or no for the job requirements. THEN we go into the projects with the remaining time. If you're competent, you'll have a bunch of time left, but you'll also be a strong "yes" anyways. Any cool stuff you show me will change it from a "yes" to "we need this guy, throw money at him".

If you don't like interviews, you have to blame the liars that make them the way they are. There are so many liars.

> Where I am, unsure terms like "team fit", "feel" and "think" will get your feedback rejected.

This is a very good thing because it helps to prevent bias from sneaking in, either positive or negative. Too many interviews are vulnerable to rapport and charm. "I really like and want to work with that cool bro" should not be enough justification to hire someone.

Also, (at least at larger companies), when you provide feedback, you need to also reference evidence from the interview. You can't just say "Candidate X can definitely code." You have to say "Candidate X showed, through their implementation of the Linked List Reversal problem and the Towers of Hanoi problem, that they could think through a problem and express it effectively in code. Here are some examples from the code itself that show this...."

I once gave an interview to a PhD with 15 years of experience. He couldn't write a for loop at the end of the interview, but had great knowledge otherwise. We needed someone who could actually code. I had my boss join late, because it was so unbelievable. I was the only "no" for him. I was the only person that tried to make him type something.

I keep my question very light and completely work related. They're allowed to ask as many questions as they want. They don't even have to remember any algorithms (I have a review slide for the relevant ones they might pick). They just have to be able to think and be "seeking" in their mindset, asking questions to fully understand the context, then convert that to code. That's it.

What's more likely?

(1) The candidate was a criminal mastermind who somehow managed to fool everyone for 15 years.

(2) The candidate was just super nervous during the interview and experienced a kind of test anxiety.

I've personally been (2) several times.

This totally happens, but keeping the questions simple and the atmosphere friendly goes a long way to mitigating it. One thing my previous company did was to have a short take-home replace the live coding, then the candidates simply answered questions about it. A surprisingly large number of candidates plagiarised their submission from various blog posts online. Others were unable to answer any substantial questions about their work. All these people were senior and employed in big firms. These kinds of candidates outnumbered the obviously anxious candidates by maybe 10 to 1.

> All these people were senior and employed in big firms.

Which big firms?

I find it curious that a BigCo on one's résumé brings cachet, because BigCos are able to hide incompetence, even at the executive level, to a vastly greater extent than a small company. If you find someone who for example has around a decade of experience at a company of around ten people, it's going to be almost impossible for that person to have done nothing of value.

> These kinds of candidates outnumbered the obviously anxious candidates by maybe 10 to 1.

Anxiousness is not necessarily obvious. My stomach could be churning and my mind racing, but a stranger probably wouldn't be able to tell.

Indeed, but then I can’t measure the true positive rate. :) I suppose we’re really talking about having an anxiety disorder that impedes the ability to deliver vs feeling anxious on the day. The former should manifest noticeably somehow, by definition.

As for which companies? Basically any large enterprise except absolute top-tier tech. I wouldn’t necessarily call such people incomponent though - I’m sure they were perfectly good button-pushers within the corporate machine. Low-skill high-specificity.

> I suppose we’re really talking about having an anxiety disorder that impedes the ability to deliver vs feeling anxious on the day. The former should manifest noticeably somehow, by definition.

I'm not really sure what you mean. First, anxiety is on a continuum, so I wouldn't propose a dichotomy here. Second, lots of people have situational anxiety, which I wouldn't call a "disorder". For example, a great fear of public speaking is pretty common.

Of course poor performance at some specific task, e.g., an interview or a speech, is manifestly noticeable, but the cause of that poor performance isn't necessarily manifestly noticeable. In other words, you can't necessarily tell whether it was caused by a lack of skill or competence or just temporary anxiety. Or maybe lack of sleep the night before.

I’ve personally seen (1) and that hire wreaked havoc in the org with his silver tongue, without being able to deliver any real value. (Not a criminal mastermind obviously. But damaging enough, was unable to implement our version of fizzbuzz and was brought on board as an “architect” anyways.)

I understand not being able to deliver any real value, but I don't understand how a new hire can wreak havoc in an org, unless the org itself is already quite dysfunctional.

A person is assigned work, and they need to be able to do it, without being a deadweight on their peers. At the very best, you're just dumping a SWE salary's worth of dollars into a ghost. I've never worked anywhere that didn't have plenty of work, and so that's an eng we could have had, but effectively did not.

IME these people talk a lot of talk, but they don't deliver contributions. Like the simplest script could take a quarter? I don't endorse code metrics, but, e.g., 1 PR / quarter (of really simple stuff), unless that PR is blowing my socks off or had some complex amount of research or some reason behind it, is underperforming.

You expect negative returns for a new employee like the first 6–12 months. This is well after that, where it's clear that they're not putting in the effort to understand the systems around them, or they lack fundamental skills (like experience writing actual code), or more often, both.

> A person is assigned work, and they need to be able to do it, without being a deadweight on their peers.

I wouldn't call this "wreaking havoc", but I think only wisemang can explain what exactly they meant by that.

> You expect negative returns for a new employee like the first 6–12 months.

Wow, I wouldn't expect that. In my opinion, an experienced programmer should be able to start contributing something within weeks. If they can't, then "can" them.

Think about open source projects: nobody takes 6-12 months to "get up to speed" before contributing to a project. That would be ridiculous.

I agree negative return for that long is not necessarily expected. Definitely fair for some period of onboarding though.

The havoc I was referring to was more due to the person’s political skills and ability to shift the blame for his own shortcomings to people on his team, while those on the team were unaware of how he’d throw them under the bus while managing up. The failure at “fizzbuzz” was a red flag that got ignored by management (yes there was some existing dysfunction in the org).

And so — figuratively speaking — someone who couldn’t even build a doghouse ended up being tasked with architecting a shopping mall, then attempted to deliver a skyscraper (and failed miserably at it).

> Wow, I wouldn't expect that. In my opinion, an experienced programmer should be able to start contributing something within weeks. If they can't, then "can" them.

> Think about open source projects: nobody takes 6-12 months to "get up to speed" before contributing to a project. That would be ridiculous.

I'm trying to be generous, and to say that the people under discussion in the comment are past the 6-12 mo timeframe to avoid needing to fend off "but maybe they just need more time/experience/etc."

But I also do think 6 mo is about the "productive" point. This doesn't contradict "start contributing something within weeks" — you should contribute something within your first week, ideally, if the company has their stuff together. But it's 6 mo, IMO, until one has got a good grasp on the architecture, and more importantly, the theory of the system at hand, and can make their own salient decisions about how to grow it that are going to fit well into the existing theory of it.

But again, I'm just putting it out that that we're well past the "initial onboarding" phase of an employee, and tried to pad the amount to avoid commentary.

Asking someone to code, even simple problems, should be the absolute minimum standard. Why should it be unexpected to not code when applying to a software development job?

I'm sure we all have stories about falling on our faces during a technical evaluation, it sucks but I wouldn't personally fault the interviewers passing on them.

> Why should it be unexpected to not code when applying to a software development job?

Software developer hiring is very different from most other hiring, but it seems that many software developers don't even realize how eccentric they are, because they've never been outside their own industry.

I suppose but until this industry adopts something like an engineering license like PE I don't think it's out of the question to ask people to code. It's the highest signal you can get from a candidate. It doesn't matter what their credentials are or what their experience is, if they're able to code you have some sort of baseline to go off of.

Please note I'm not saying ask leetcode questions, I can't even solve LC. I've failed many interviews at Facebook and Amazon because of LC; but other jobs I've accepted all asked some basic coding questions.

Professional licenses are local government requirements.

If you want the government to start regulating all programming, then the shit's really going to hit the fan. ;-)

I mean regulation isn't a bad thing, so I don't understand your comment.

If anything big tech needs to not only be regulated more, they should be broken up.

> If anything big tech needs to not only be regulated more, they should be broken up.

You're thinking of the wrong thing. We're not talking about breaking up big tech, we're talking about every little hair stylist needing a cosmetology license.

We're actually talking about software but okay.

Yes, we are. If you don't see the analogy, I'm not sure that I can help you.

Professional licenses and breaking up monopoly are totally unrelated regulations.

> (1) The candidate was a criminal mastermind who somehow managed to fool everyone for 15 years.

Not "criminal mastermind", but do enough hiring and you will run into a lot of people who are convincing conversationalists but clearly haven't written much code in a very long time.

In a couple cases I gave these people benefit of the doubt and gave them a backup take-home problem (super trivial, 5 minutes for experienced engineers). They always came back with a solution, but when you asked them to walk you through it they couldn't really tell you what they wrote.

I understand that test anxiety is real, but having to discuss your code with others on the spot is also part of the job. If someone can't discuss even the most basic fundamentals of programming in a conversation, you can't dismiss it all as anxiety every time.

Well, interviews are mostly noise, whether they're conversations or coding. I wouldn't put much faith in them either way. Interviews are just a tiny snapshot and unlike real work in many important ways.

IMO the key is really to investigate the candidates as much as possible before they even walk in the door. Nowadays, many candidates have a large public footprint.

(I also think employers interview way too many people. That's mostly a waste of time, better spent focusing on a relatively small number of the top candidates.)

I have seen #1 many times (in non-interview settings).

- It's definitely possible to hold a tech job for 12-18 months without writing any working code and changing jobs that often isn't that big of a red flag. Also, people lie about their experience.

- The pool of people applying for a job has a very low intersection with the pool of people currently working at a job. In that intersection there is a very high subset of people who believe they may lose their job soon. Therefore the people applying to a job is largely people who either are not currently working, or will shortly be out of work. See also[1]

1: http://weblog.raganwald.com/2007/03/thank-you-for-writing-su...

Yes, I've also seen 2 several times. I've also requested second rounds for each time I noticed it. I'd rather the interview not be about the interview. My judgement could be wrong, but being someone who ALSO has a problem with 2, and just being nervous in general, I feel my perception of this is at least reasonable.

This person had a very very niche job, at two orgs, with no work/growth outside of that very specific thing. This lack of doing anything else was a flag one of the high level managers saw.

Yep, I’ve had exactly the same experience. Super-simple questions, qualified candidates from large companies - almost total disaster on “hello world”.

That's a common trope I hear a lot, and of course sample size of one so take it with a grain of salt, but I've done tons of interviews with varying levels of engineers, and I've never seen any of the senior people fail FizzBuzz or anything like that (I never thought about testing Hello World), and most even do fine on the simpler data structures problems.

Maybe I've just gotten lucky, but I really haven't observed it. I've interviewed plenty of bad engineers, even senior level, but they usually knew the basics and had trouble with the lateral thinking required to solve the problem.

I suspect you're late in the screening process, or there's some effective filter before you. I've seen hire rates of 1 in 100, in big orgs!

Obviously I don't know you or this guy so I'm not trying to dispute your story, but I'd like to point out people get nervous with these things, or misunderstand the question.

I got a friend of mine an interview at a BigCo I used to work at. Since he was already a friend, I wasn't allowed to be part of the interview as that might be a conflict of interest, but I did see the review that the interviewer wrote, which said that he didn't know what a for loop was.

Now I had done several projects with this friend, he was someone that I knew was quite competent at coding (and I had seen him write multiple for loops in the process). After he was already declined I did kind of ask about it and he explained that he was asking a clarifying question about how many times something needed to be repeated, they didn't directly answer, so he assumed that that meant "potentially forever" so he did a while loop with a break condition. The interviewer had taken this to mean that he didn't know how to do a for loop.

Now it's possible that my friend was lying to me, but again I had previously seen him write lots of code and I knew he was smart and able to do that, so I'm inclined to believe him.

If you still need to use for loops on a regular basis then there's something wrong with your chosen programming language. The rest of us have moved on to languages with higher level constructs that eliminate the need for explicit iteration.

I'm being a bit facetious of course. For loops (or the equivalent) are still needed in low-level code. But lately I'm very reluctant to use them as there's usually a better design if you step back and think about the problem a little.

A for loop with more than four lines of internal logic probably does need to be refactored. A for loop with less lines can usually be turned into a list comprehension or invocation of the map function. But a four loop with just a few lines is often clean and easy enough to understand, and will pass my review.

I'm assuming we're working in Python here, which are already much more elegant and pythonic than C/C++ style loops:

for i in my_iterable: ...

I'm all for hiring people who can figure things out and know how to figure things out. I'm not blind to the fact people will google and copy-paste-modify stackoverflow example code and don't have strong issue against hiring someone who would work that way.

So my simple whiteboard interview question started as "Print the numbers from 1 to 10" but then I had a few candidates that would just write the numbers out on the board.

Since it happened more than once I figured it was a me problem so I became more specific with "Write code to print the numbers from 1 to 10". But then one one candidate would out dumb me and write 10 lines of print statements.

So I thought it would be clever to force a loop of with a really large number: "Write code to print the numbers from 1 to 1 million." but I had one candidate who started to write out a bunch print statements and I had to stop him.

The latest iteration is "Using a for loop to print the numbers from 1 to 1 million putting one number per line." I usually get blank stares. It's either they think it's some sort of trick question or they don't know how to do it. One time I saw an implementation using an if statement to skip 0 and an extra print for the last 1000000.

The solution to that was to tell HR to let me phone interview them for 10 minutes before brining them onsite.

For the candidates that write 10 print statements, why not simply reject them? They're either ignorant or smartasses... Now if they do the right thing when told to write a loop, you just let them in the door, lol!

Does HR really think it benefits the company to hire folks who need to be told when to use a for loop? That sounds like a painful organization to work for!

> I do want to verify that people can actually code.

My best advice here is allow them to bring their own laptop and use their preferred editing environment.

If their way of working is to run small pieces of code through the compiler/interpreter to spot errors, they should be able to do that, rather than pointing fingers at a whiteboard and saying "oooh that's not the right way to initialize a std::vector".

If their way of working is to write inside out, outside in, top to bottom, bottom to top, that's all easy in an editor, but not on a whiteboard.

They should be allowed to search for references or even cut-and-paste the boilerplate part of whatever it is, and edit it to complete the task. That is more representative of how people actually code.

Dealing with unfamiliar hardware, let alone a whiteboard, hugely, hugely gets in the way of thinking about coding and is not inclusive of all coding styles.

> never thought about obedience in any aspect.

What demonstrates obedience more than having to solve a problem against the expectations of someone holding something of value over your head? "If you don't do as we say in the way we tell you to say it, you don't get this <thing>." No matter you may have a different perspective on solving the problem, even going so far as to dismiss it outright, it's all about the rubric. No subtlety, no interpretation allowed. Make it easier for your interviewer masters.

this is an alien way of looking at the world to me

Who said anything about not being allowed to have a different perspective?

The nature of an interview...

Just because some interviewers are bad, it doesn’t mean that it’s an inherent property of interviews.

when the majority of interviewers are bad it does become an apparent property of interviews

The whole meme of “coding interviews” can illuminate how a person thinks is based on an entirely false theory of mind.

When people are experienced in a particular skill, they often have reduced inner voice and experience inner quiet as the work just comes to them. Asking people in these circumstances to vocalize their thought process is to take people out of flow conditions into hyper conscious states and perform a metacognitive task, reducing their ability to focus cognitively.

When you ask someone to do something they’ve never done in an interview before, you’re creating a contrived environment that doesn’t exist at all on the job. When I’m creatively working through a problem I often take big breaks after framing the problem so my subconscious can work on it. I often solve hard problems from the prior day first thing in the morning, often with the solution immediately on my mind as I awaken. You can’t do that in a coding interview: if someone doesn’t have the answer in mind readily it’s unlikely the pressured environment is going to encourage its production.

In my experience interviews do read code whether on a whiteboard or in a github repo. Instead they gloss over the details for than vanity of it. It’s an exercise in fashion for the sake of conformity. That is incredibly unappealing.

I would rather be in a hostile deposition because then at least I would understand the opposing party’s motives and intent.

The trouble with open source is that it can be faked. You could pay someone to write a contribution in your name or else to accept some BS contribution. Also if you contribute to a solo project, that could be pure garbage or a ripoff of something else. Open source also favors students who have time for it. Once you're working a regular job, time tends to dry up.

Had a pier group interview at a company once where I was asked how to form a grouping SQL statement. I rattled it off and then was told that I needed to write it out on the board.

Wrote it out, turned and asked how they would like it sorted (they hadn’t specified) since you should almost always have a sort on a query.

The entire room busted up laughing except for the guy that asked the question. He just stood up and left.

Figured that I had pissed off the wrong person. After I was hired, I was paired with him. I later asked him about it over drinks, he said that he walked out because he didn’t need to waste any more time interviewing me, that he went to the manager and said that they better hire me. He was definitively one of the smartest people I’ve ever worked with and a good friend now.

The author falls into the trap of every "technical interviews such, just talk to them about their experience!" argument - it's easy to sound like you know what you're talking about but not be able to actually write code.

I've had so many interviews that started strong, great conversation, amazing resume, and then they couldn't write a basic function to implement a straightforward algorithm.

Like, they literally could not write a nested for-loop that worked (in a language of their choice!).

IMO, the solution is apprenticeships/probationary offers. "Try before you buy" goes both ways - it gives the candidate and opportunity to try out the company (how many companies like about their culture, tools, quality, and work/life balance?!).

Alas, it requires the industry to shift to support that model, it's very difficult for companies and candidates to support that model on their own without most other companies doing the same.

I absolutely love the idea of both sides being able to "try before you buy". Some jobs just suck for the employee and they wont know until they're a month or so in and it's a waste of effort for both parties to continue cordially expecting it to magically get better.

I think about half of the dev jobs I've had started with a 3 month probationary period, during which either myself or the employer can decide "never mind" without serious consequences.

As the new hire, I strongly prefer it for the exact reason you state: it's pretty hard to know if I'm a good fit in a company prior to actually working there. I've used the probationary period twice to get out of such mistakes.

As the hiring company, it's also a great thing for exactly the same reason but from the other side of the equation.

Lots of companies do this. I think more companies should join the bandwagon.

What kind of consequences would a dev have for quitting early? I think you can do that at any job.

The consequences are always about your next job and whether you can explain leaving a position quickly

The idea is that you haven't really quit early, you've opted not to take the position. It's really more of an expectations thing than anything else. Nobody's going to be mad that you decided not to stay.

For the two times that I've opted not to stay, I just don't list those companies in my work history at all. I've never been asked about them in an interview and have never had to explain.

If I were to be asked, though, I'd just say something like "I decided that I wasn't a great fit and left during the trial period so that the company had the best chance of finding a more suitable candidate in a timely way."

that sounds great and i wish i could've done something like that in the past.

however i'm used to not quitting one job until i have the next one lined up (especially now that the interview process can take months to go from application to start date).

> i'm used to not quitting one job until i have the next one lined up

Well, that certainly affects your flexibility with this sort of thing. Many years ago, I learned that this stance is too limiting for me and sometimes encouraged me to take jobs that I shouldn't have taken.

Everyone is different, of course, but what works for me is to keep enough of a bankroll on hand that I can go at least 6 months without an income (Although these days I keep 1-2 years worth). That gives me the breathing room to be pickier about where I work.

if this is how your company hires, you're basically giving up on hiring most senior eng

Or just fire fast in general.

How does “try before you buy” really help the candidate though? Many (most?) things that suck about a company can be (or are naturally) hidden in a two-week trial period.

I would love a view of the code and architecture and backlog I'd actually be working on to see if it's a huge ball of mud.

I have been fooled by companies selling other perks of the company, but the actual day-to-day was terrible because of terrible code.

I've also been sold on intentions to improve the code, but which never panned out after 6 months because shipping features was still the foreseeable priority. You can sometimes find honesty up front like "we know it sucks but we're going to improve it" but that goes back to selling intentions with no real solid date for that effort. It might work out, but it's a gamble for a candidate.

Plus you also get to see incidents, how they write tickets, and sprint volatility and how much stuff gets pulled in/pushed out because priorities change rapidly (there's probably a proper PM term but I can't be arsed).

It would stop a lot of people joining, realizing it sucks, then doing their year and getting something else. Then they might actually have to improve their shit instead of burying the facts.

Same, I've joined a number of orgs that seem to fit well with what I was looking for, but even the answers to my (rather pointed) questions during the interview and offer negotiation turned out to be outright lies that caused both of us to suffer a ton of wasted time and effort. TBYB would save a bunch of time, but so would people dropping the bullshit acts.

But you can join and then quit. What does an “official” period get you that you don’t already have?

The "standard" probation period is 90 days. Outside of the modern silicon valley bubble, lots of companies hire with a probation period. Inside the bubble, the equivalent is contract-to-hire. But I really wish companies would just go back to the old days of probation.

My current job was contract-to-hire. Officially an 18 month period, but they converted me to employee after 3 months.

How it helps the candidate is exactly the same as how it helps the company: The interview process was a half hour phone screen, a 1-2 hour onsite with two people from the team, and a half hour followup call with the hiring manager who hadn't been able to join the onsite.

You know those week-long all-day interview processes many of us hate? Not necessary at all if the company is willing to give people a try and just move on if it doesn't work out.

You know how companies complain that they can't find good hires because their ridiculous interview process filters out the good ones and keeps the great ones from even applying? Having a sane short interview with probationary hire costs way less productive time and gets people onboard fast. And if someone doesn't work out, you can have another candidate take their place next week. It doesn't need to take months.

The candidate is still “buying” when they resign their current role to take the new one.

This is “try before you buy” for the employer but much, much less so for the employee.

> Having a sane short interview with probationary hire costs way less productive time and gets people onboard fast.

That sounds like a ridiculous interview process which would filter me out from even applying. I'm not going to give up the job I already have and go through all the hassle that comes with a job change for the possibility of a new position.

Because you are afraid of being dropped out there into a months-long grind to find anything. I'm saying that if tech companies hired like normal, sane companies, that would not be a fear. Sure, they might not keep you through probation (and YOU have a lot of influence over that). But if not, you go start at another company. That's the benefit I'm talking about with not having stupid long, arduous interview processes: Not having stupid long, arduous interview processes.

I obviously can't speak toward your experiences, but on the flip side I've never been surprised to find out someone can't code their way out of a paper bag after having a technical conversation with them.

I have of course met candidates who don't know even the most basic constructs in a language they're supposedly expert in. But none of them were able to "talk the talk", especially when probed directly about problems they've run into and how they've solved them.

I want to be clear I'm not discounting your experiences and I'm also not trying to say you suck at interviewing or anything like that. What I am trying to say is that my own experience tells me there must exist questions that reliably expose this kind of candidate.

Do you happen to score as "intuitive" on Myers-Briggs?

I'm idly wondering whether that's why I believe I'm pretty good at interviewing people just by talking with them.

Maybe, many of the people who are capable programmers or software engineers, but who insist that they can't tell anything about a person's ability to code without, say, a Leetcode hazing, are just wired a little differently, and not picking up on all the signals the same way?

no, i think people can be very good at talking and technical depth without being able to code very well at all

perhaps you just overestimate your interviewing skill

Myers-Briggs is pseudoscience. I would not base anything substantial off of it, you might as well use TeenVogue personality quizzes since they're just as effective (shorter too).

I will say learning to interview is a skill like any other, I have no doubt the person you replied to was not born into the world understanding the nuances of technical questions and what heuristics to use to determine validity. Just like yourself.

> Myers-Briggs is pseudoscience.

The inventors' theories were unscientific. But MBTI traits correlate moderately to strongly with Big 5 traits. And reliability is comparable to Big 5 when the traits are treated as scales like nearly all MBTI tests. Claims reliability is low come from treating the traits as dichotomies and any variation as failure. The same methodology would make Big 5 look unreliable.

But I agree interviewing skill is learned.

Maybe it's me, but I'm not sure someone who interprets coding interview as "hazing" can make an authoritative judgment on other people's skills and motivations.

Au contraire, I think those that recognize the farce for what it is are better suited to evaluating objectively, rather than cargo culting the process cribbed from more bullshit artists from faang and others.

Anecdotally, I was in a fraternity many years ago and we were warned that forcing new recruits to perform tasks that aren’t the responsibilities of being a full-member could be viewed as “subtle” hazing.

Not that I necessarily agree but I could see how someone might argue that a coding interview that doesn’t test the actual duties of the position might also be “subtle” hazing.

well, then don't do a coding interview for someone who won't be coding. am i missing something? if the job is java, then any coding test on java should be ok. if they are going to be learning a new language, then testing in an already known language should also be ok.

Studies has shown that unstructured conversations has 0 correlation with on the job skills, if you just ask questions and go with the flow of the conversation it is extremely unlikely that you actually learned something important.

More likely is that you got biased from that conversation and that bias colors your later evaluations of them. A lot of people are biased like that, studies shows that, maybe you are one of the very few that would be the exception of these studies, but it is unlikely, much more likely you are among the large majority who overestimate how well they can read people in free form conversations.

And interview is generally the opposite of unstructured conversation.

The person talked about unstructured interviews though, those used to be very common until they studied it and realized unstructured interviews just finds people you like and not good people.

If you haven't prepared a set of questions and focus on those questions instead of letting the conversation flow then the interview is just a "do I like this guy" test.

I guess we read that completely differently. I don't see anything about an unstructured interview in his comment. He points out that he's good at interviewing by just talking to them. I read that as opposed to making them jump through hoops doing leetcode or exercises.

The problem is supporting the 'try before you buy' model would basically require most companies to be happy with someone taking a month off to go try working somewhere else for a bit and then come back if nothing happens. I don't see any particular motivation for them to encourage that at all. Otherwise, the probationary period is basically just a quicker escape from a match that's bad enough that you're rather be unemployed (or at least take the risk of such). Either way it's enough of an investment that both sides are gonna want to spend a least a little effort on figuring out if it will work beforehand, like with interviews.

> The problem is supporting the 'try before you buy' model would basically require most companies to be happy with someone taking a month off to go try working somewhere else for a bit and then come back if nothing happens.

I wouldn't think that this is how you would hire a known performer. I can still see the problem, but I can also see how it wouldn't be a problem if it were a more common and more standardized process. And if the applicant were being paid contractor's wages (higher) during the tryout period, not salary-level wages.

The whole issue is to identify a "known performer" in the first place.

Otherwise, that practice being more common means people can leave their job for weeks here and there no questions asked ("I'm going to work for our main competitor for 3 weeks" won't fly if it needs approval), and come back without impact or penalties on their performance.

That would be ideal, but we're so so far from that. Even getting people to properly take their parental leave is still a fight.

I’m sure some people would accept being paid to try out without the company having any commitment to hiring, but those are probably not the people you’d actually want to hire. If a company can’t commit to hiring then why would a confident professional bother with the company? A probationary period seems like a reasonable compromise where the company commits to the expense of onboarding while still having an escape if it goes poorly.

those are probably not the people you’d actually want to hire

why not?

That'd probably spawn a class of workers that are happy making a living off of trying out at places. Aside from that, why would someone that has a job quit their job for a company that won't commit to hiring them. The worker can already quit the new job if they don't like it early on. This only benefits companies.

> IMO, the solution is apprenticeships/probationary offers. "Try before you buy" goes both ways - it gives the candidate and opportunity to try out the company (how many companies like about their culture, tools, quality, and work/life balance?!).

I had an ideal experience with the job that did this with me. It wasn't a probationary offer, they just offered me a seat as a contractor for a month as a tryout. At the end of the first week I found a buggy, unoptimized query that was slowing down a critical part of their site and frustrating them for a while, fixed it, and they made me an offer at the end of the day. Everybody was happy.

I don't know why this isn't done more often.

There's a risk with that in more sensitive areas, sometimes its months before you're allowed to see something serious because they don't want their secrets exposed.

> IMO, the solution is apprenticeships/probationary offers

Most companies would love this, especially startups. The problem is that desirable candidates do not love this arrangement - there's an opportunity cost and risk for the candidate here and if you're in demand you can get a solid offer from a company who isn't trying to hedge.

Here's the thing:

There is a massive asymmetry between what a company that can afford to do 1000's of trials at a time to get what they want, and an individual who really can't afford to be culled and lose 2-4 months looking for another position.

Also if you've ever dealt with temp->perm situations, people can change when they go perm. It is a real issue.

---

As an employee: I usually can tell if a company is bad, I don't need to work there 2-3 months to learn that.

So for me there's little to no benefit, and massive downsides in that I don't have ANY real safety net to jump to the next "internship".

Maybe in Europe where they have stronger employee protection, and also better healthcare I'd consider it. But in the US, I'll take every protection you give me.

The norm in Sweden is that every position is "probationary" for the first six months, which then automatically converts to a permanent position. What it means is that the employer can terminate the employment without cause during the probationary period.

It's kind of a necessity in places with strong employee protection, otherwise companies would have an even harder time hiring. Now, companies can take a chance on someone without risking very much, so I think it's a good thing. Obviously, the companies have to pay new employees the same as the permanent ones and give them the same benefits, sick pay, PTO, etc.

The flipside is that some unscrupulous companies churn employees every six months to avoid having too many permanent full-time employees. Not common in the IT industry though.

I understand a similar system is in place in other places in Western Europe.

I have no issue with it. But in a situation where my healthcare, etc is all riding on my job, the stakes are a bit higher.

That's the issue in the US, IMHO. I suspect there would be more businesses started if the risk was lower. Yeah, YOLOing is hard, but it is harder when you know your healthcare, and everything else is on the line.

> IMO, the solution is apprenticeships/probationary offers.

"Contract to hire" is a popular way of doing that.

> it's easy to sound like you know what you're talking about but not be able to actually write code.

Indeed. I'm gonna vent about my anecdote: we hired someone who talked a good game. Turns out they have worse ADHD than I do, will take a few weeks to do what I expect a couple days, and can't follow a deep technical discussion for more than 10 minutes.

They're trying, I'll grant them that. But their growth curve has been... low logarithmic.

I wish we had been more aggressive with the interview coding tests.

edit

yeah, it's almost like the hiring process is a gamble with no solid heuristic :(

This will be shocking, but honestly, the point of asking someone to code up fizzbuzz on the whiteboard is not sifting for obedient slaves. Hand to god, chop down the cherry tree, no lie.

At some point the test stopped being fizz buzz and started being "reproduce Brent's cycle detection algorithm from memory or from first principles if you have forgotten what it is", which isn't testing your ability to program in any meaningful way.

i used to ask cycles in a graph. we were building a database, used graphs alot.

if we cant talk about the problem together from first principles and make some progress, and you cant demonstrate that you're tracking the discussion at all then we cant work together on that database.

sure, for devops, who cares.

It isn't if the problem is FizzBuzz or a slightly more challenging and realistic problem. When its 1-2 leetcode hards in 45 minutes that can only be solved by having done hundreds of those problems, it does seem the purpose is more to just gauge how many such problems you've spent time grinding on before even though they have very little relevance to programming.

I've interviewed at various "prestigious" companies widely considered to be rigorous in their interviewing, and no one has ever asked me to solve 2 leetcode hards in 45 minutes. I think I might have gotten one leetcode hard question ever. Most companies seem to ask relatively straightforward questions, although they do sometimes expect you to solve them quite quickly.

Doing a bunch of leetcode problems (something like 20-30 hours over a few weeks) certainly made it easier to answer questions quickly, largely by becoming more fluent in the language and libraries.

Leetcode questions are definitely step 1 in Meta interviews, at least as of the round I went through earlier this year.

I did Meta in about 2020 and they did not ask anything like that in step 1. They asked a single question that I had about 20 minutes to figure out. Nothing particularly leet codey about it; just a question that was basically asking for a dictionary implementation that also had a list for most recent access. The point wasn't the advanced algorithm; it was comprehension and a bit of code.

I do get lots of leetcode-style questions, just not leetcode hard questions.

Whenever someone tells me they've been asked a leetcode hard in an interview, I always ask them "which one". I don't think I've ever gotten a response that was an actual LC hard.

This is the only LC hard I've ever been asked in an actual interview https://leetcode.com/problems/shortest-path-in-a-grid-with-o...

I once got asked something like this (at Google): https://leetcode.com/problems/expression-add-operators/descr...

Pretty sure all the others were easy or medium.

I'm curious why the rated that one hard.

They say the maximum length of the input digit string is 10, so there are at most 9 places where an operator can be inserted. At each possible insertion point there are 4 possibilities: insert one of the 3 allowed operators or do not insert anything.

That's only 262144 possible expressions. Just brute force evaluating all of them, filtering out the ones that do not equal the target, and then filtering out those that violate the no leading zeros requirement should be fast enough even on a slow computer.

The other hard ones I've seen have all allowed inputs large enough that brute forcing would be way too slow, and so cleverness is required. E.g., that shortest path in a grid problem that was posted a comment or two above. My first thoughts on that one were to just generate all possible paths with the obstacles ignored, and then find the shortest path(s) that do not cross more than the number of obstacles we are allowed to eliminate.

But the grid can be up to 40x40. By 10x10 we're already up to 41044208702632496804 possible paths [1], so brute force is not an option.

[1] https://oeis.org/A007764

When I got this in an interview they definitely wanted better than brute force.

really? it says it’s a backtracking solution. i imagine you could speed it up a bit by memoizing, but it would still be pretty brute force

Oh hey that's the question I got for my recent amazon onsite (slightly different constraints). I couldn't find the exact question online and I thought it was a "fair" medium question. IMO this is a pretty good question there's a really easy suboptimal solution so people don't get completely stuck, the optimizations are pretty straightforward and there's a lot of room to demonstrate you can write clean code.

*Fair meaning there's no crazy tricks to it or any obscure algorithms just applying DSA fundamentals.

Right - I think it's fair to expect somebody to come up with some kind of approach to solving this, even if they've never encountered the problem or drilled Leetcode before. At least to be able to conceptualize the problem and make a decent attempt.

I wouldn't expect more than brute force. But being able to reason about this, having some working familiarity with graphs etc, is not an unfair bar.

I haven't done any Leetcode so I have no idea of what "medium"/"hard"/etc are, but the last time I interviewed, the two problems I failed were very fiddly dynamic programming problems—the hard part was not even the dynamic programming, but rather the problem-specific setup (based on chess rules and geometry, respectively).

I am sure I would have done better at those with practice, entirely because I would have seen lots more fiddly dynamic programming problems and not because I would have picked up any general-purpose skills or knowledge I don't have as-is.

I was in a Slack dedicated to interviewing for a while. People reported their experience back.

Lot of people claimed they got "Leetcode Hards" after failing an interview, but none of them could ever point to the actual question they failed, or even remember it!

I'm sure some interviewers somewhere like to mix LC Hards into the interview loop, but it doesn't appear to be as common as internet comments make it sound.

2 leetcode hards is just absolutely an exaggeration, i've done tons of these interviews and i've only been asked a formal "LC hard" once and that one I believe was a misclassification and was probably more of a medium

I've seen Leetcode problems that Leetcode classifies as "Hard" where it is actually not at all hard to come up with an algorithm that would solve them in O(n^2) time and/or space, and this would be fast enough in almost all cases, but the problem specification specifically asks for something faster and it is achieving that that makes the problem difficult.

When companies use such a problem do they usually include the time and/or space constraints from Leetcode or are they usually fine with O(n^2)?

Whiteboard questions are great, if the question is like two orders of magnitude simpler than the day to day. At that point you’re answering “has this person seen a computer before, and are they able to do the simplest possible task?”. Which I think your experience has also shown, can be a live question for far more candidates than one would expect.

The problems come when a company overestimates that threshold, either by selecting too hard a task, or believing their work requires more than it does. Then the question selects for (a) savants and (b) people who study for interviews. Unsurprisingly (b)s outnumber (a)s, and then get pissed when they realize how disconnected the material they studied is from the job, and write things like TFA.

The purpose of a system is what it does. And what Leetcode-style whiteboarding tests—very much not fizzbuzz!—substantially do is select for people who have specifically prepared for Leetcode-style problems.

Describing that as selecting for "obedience" is rather dramatic and provocative, but it's directionally right.

That's what the article is about, it isn't about the sort of basic programming test that anybody should be able to pass without explicit preparation.

I mostly see them as a way to filter out people who are out of the loop, which turns out to be a pretty decent proxy for a lot of things.

Motte and bailey, and the comments here show it. Half of people arguing "reasonable whiteboard tests rule out candidates who cannot code" and the other half arguing "but leet code!" which is a different goal-post.

But this stems from the article's thesis itself being unclear: both positions are superimposed in TFA, so it's no wonder half the readers came away with one goal post, and half the other.

Motte: Leet-code interviews requiring memorization of problems unlikely to ever be actually encountered during one's career are bad.

Bailey: "[All] Whiteboard interviews are a test of obedience, not intelligence" and the entire "How (Most) Interviews Should Be Conducted" which implicitly rules out any whiteboard/coding questions by not including it.

To the author, if they're here: which position are you actually arguing?

I agree with the motte, as one might guess. If it's truly is the bailey, why should a Senior SWE not be able to implement min()? (… like, realistically, in their sleep?) Perhaps I'm returning false negative in 1/10,000 people, but I'll take that for the true negatives of "cannot, apparently, implement min()". "min()" has pass rates of like 50% in my interviews.

The problem with the suggested interview style is that it does not yield reliable information. People bullshit, people lie. People exaggerate their contributions to something. Worse, the people who you probably do want to hire are going to be modest and honest as to their role.

I'll also add that "whiteboard coding" should ideally not be literal. I really want the candidate to have a good IDE / dev env to work in. I am often hamstrung by what HR/the corp. is willing to provide; if all I've got is a whiteboard, I'm sorry. Everyone being remote should have made this easier, but I still encounter many candidates who struggle to bring an IDE of their choosing in a language they're most comfortable with, to the VC, with advanced notice. (And this is generally a nudge towards "no hire"…)

I like this comment a lot because it identifies an extremely common pattern in online discourse. Write an article describing the motte, and give it a title that is an inflammatory bailey.

A whiteboard test asks the question: do I have anxiety about whiteboard tests.

The answer is “yes”.

one advantage to the whiteboard interview is that it allows a person to get the job regardless of their past experience, which can be determined by what they were "allowed" to do at previous companies. in some cases, people are pigeonholed into various genre of engineering based on assumptions about them (e.g., assign african americans or women certain types of work even though that isn't what they prefer). if you can only speak to what you've been allowed to do compared with what you can prove you've learned to do (via the interview), you could be at a disadvantage.

what if we could pick the type of interview we wanted? whiteboard coding challenge or work experience based?

Agree wholly. Especially for early career people, going by past experience is just a test of luck more than anything else. I've meet truly world-class people who've worked on "nothing more" than maintaining some old single-VM C# monolith or some university's LMS system, and a lot of idiots who have impressive resumes with a lot of fancy numbers to show impact.

One thing a whiteboard interview does is confirm that you resemble the person described in your application. This is ever more important as many people have an LLM write their application for them.

Here's a prediction: as it becomes ever easier to fake details remotely, there will be an ever greater emphasis placed on in-person interviews in the hiring process, with the result being that even remote work is less remote: you have to being the physical presence of an interviewer at some point. If the job is in Kalamazoo, most of the people making the final cut will be near Kalamazoo.

I've worked at companies that required very heavy whiteboard interviews and companies that banned them. The caliber of engineers at the whiteboard heavy companies was higher at each. At this point I see them as a needed filter.

Actual coding has always been like 20% of my job.

The rest is spent co-ordinating, planning, troubleshooting, etc.

If youre going to test me on coding then actually let me code. lol

Can't it be both?

In the same way a college degree tests your willingness to jump through hoops authority figures set for you, but it also demonstrates a basic level of mental competence.

A while ago I interviewed at Scale AI. After reading about them online I was fairly certain I didn’t want to work there, but I decided to do the interview as practice anyways.

The interview had nothing to do with the role I would be doing, and worse yet, the interviewer seemed pretty tired and uninterested. So when I was rejected I wasn’t too upset.

Yes and interviews are about who interviews the best. Not the best fit or smartest

I think coding tests can be done in a way that’s useful, but on the other hand I’ve never been fooled by a candidate who was an “impostor” during a non-technical screening. Everyone I’ve judged to be a competent engineer after 30 min of semi-structured technical discussion has indeed been a competent engineer.

They are a test for people who are very strongly identified with being highly intelligent/skilled where their definition of "intelligence/skill" includes solving programming and computer science problems (and have the capability to achieve a good level).

If that's your identity, then not being able to solve hard Leetcode problems (which, to my knowledge, are not even actually hard, since they seem to be easier than the problems in actual top competitions like the IOI, ICPC, etc.) is completely unacceptable and thus you will study and practice relentlessly until you manage (if you can); conversely, if that's not your identity, it's probably going to be hard to find the motivation to do so.

All good until the part of you need them working, not interviewing. That’s not true at all. If someone has to enter a team, should be screened by the team lead

Same goes for [unpaid] take-homes and leetcode grind.

I don’t get the hate for unpaid take-homes. It’s not like you are getting paid for multiple hours of interviews.

It's the asymmetry of time invested that gets me. You (the interviewee) are expected to put in your personal time preparing a hastily thought out and assigned example problem that usually has, in my experience, nothing to do with the position, on top of investing even more time talking to interviewers beyond that. The interviewers are already getting paid to do that on their side so you're suffering opportunity cost not being able to take other interviews that may be more relevant. It's just a completely whack system and all about the power imbalance. But then again, whack is describing this stupid industry more and more these days so I guess it fits.

Personally, I think the main post hits it right on.

Ok the asymmetry complaint makes sense. I’m confused that you’d cite the opportunity cost of interviews as an issue - the cost to the employer is substantial. It costs thousands of dollars in engineering time to put a candidate through a full round of interviews and pulls employees away from their “real work” that has deadlines.

When I spend an hour at an interview, someone at the company spends an hour at an interview. So they've got every reason to read my damn resume first and not waste both of our time.

A take-home test, though? They can waste 3 hours of my time to save 5 minutes of their time. Send me a take-home test, I spend a few hours and pass it with flying colours, then they reject me for being "too expensive".

No thanks.

How’s that different from sitting through 3 hours of interviews to be rejected for being “too expensive”? I just don’t get the logic.

Besides other replies, for the take-homes, unlike an hour-long interview, you are often expected to spend 8+ hours, several evenings, the whole weekend...

i still got a job and a family to take care of. i don't have time for additional take home tests. any interview/testing needs to be time bound so i can plan ahead.

I just assumed the interviewers were incompetent.

Here is a list if things to NOT say when interviewing for a job:

* I can not talk to you anymore. I need to talk to someone who is competent.

* Are you in drugs?

* Is there a technical person here that I can speak with?

* I need a list of the drugs you have taken in the last 48 hours.

* Are you serious?

* Are you hallucinating? Nobody said that. I think you need help.

* No. This job is not worth being humiliated by someone who is so innumerate that they have to put things back at the grocery store checkout.

here we go, we came full circle. now the code tests are oppression tool.

> We don't need free thinkers or leaders, we need obedient slaves, individuals who'll unquestioningly follow orders and work overtime. Their expertise? Irrelevant. We'll train them, we can afford it, our customers will pay for that.

I mean, yes that's actually what most large companies want. "Free thinkers" can often be outright terrible employees because they're just not interested in building whatever boring thing a company needs. They put a small number of these people in a box and make the majority of the company build what seem like the most profitable ideas to come out of the box.

Yeah clearly. Most companies only want engineers to implement the companies ideas, but don’t actually care about high level ideas from those engineers.

Imagine you are interviewing senior levels of engineer, like Guido van Rossum: in an ideal interview, you don’t want to hear him regurgitate textbook problems taken from an exam book.

You want to hear about his vision of where he sees the field in 15 years.

But this is not what companies want.

A real life example of this is Kyle Simpson, the You Don't Know JS author. He's recently been public with his issues finding employment.

Do you have any sources you recommend?

I’ve hired a book author, worked side by side with internet-famous lead devs of two different popular open source projects, and followed the lead dev of another semi-popular open source project that shows up on the HN front page frequently.

The key thing I learned is that they were all very talented at what brought them success in their endeavors, but none of them actually made great developers within a company. In two cases, it became immediately obvious that they wanted to treat their job as a side project (that pays the bills) while they further expanded their book/course/open-source empire.

Being the author of popular educational material doesn’t necessarily make someone a great employee. It can actually present a significant distraction, which unfortunately can make it difficult for them to get jobs.

> a side project (that pays the bills)

as it should be

This is exactly what Staff Engineer roles are supposed to be, and they exist all over the place.

> Imagine you are interviewing senior levels of engineer, like Guido van Rossum:

The average engineer applicant is not Guido van Rossum. The 99.8% percentile engineer is not Guido van Rossum. Using such a publicly accomplished and prolific person as your example isn’t doing the conversation any justice because it’s not relevant in any way to how actually hiring works.

Hi, I wrote the article. I see a lot of opinions here and I want to thank everyone for taking time out of their day to read it.

I'm not the OP though; I was informed that the article was shared here, so let me explain some things that I think weren't clear.

Nope. I've never applied to FAANG and never will. And yes, I do know how to revert a binary tree and run zigzag level order traversal from memory using bare C without seg faults, not using JS/Python. But I don't remember other things, and if I have to invest time to train my brain, I better get a good ROI.

I did not call everyone slaves, and I'm not calling anyone a slave, including people working at FAANG. I'm just saying that from the perspective of big corporations, that's how they see us—not just tech corporations, but all corporations.

FAANG companies need to conduct whiteboard interviews because, as I mentioned in the Google section, they have no choice. You're mostly going to be using some tech you've never used before, so they just want to see how you solve problems. I still don't approve of this as it's lacking; it's still a pattern recognition game. I can solve the hardest questions without training, but it would take me time. Expecting me to solve a new riddle my brain hasn't seen before in 45 minutes is just a numbers game. It's pattern recognition, not problem-solving, which needs a more creative aspect.

It's like knowing how to play a song on a piano by memorizing the keys versus composing your own music. Memorizing a song is one thing, but creating your own requires deeper understanding and creativity. Companies need both types of skills, but relying too heavily on memorization leads to a lack of true innovation.

Also, asking veterans how to use a specific function/class/method in library X or framework Y is not it, chief. I often forget most of my own libraries' APIs, let alone other people's. You think I really remember what that method was called? Unless I worked with it recently (within ~6 months), I need a refresher.

However, my problem is with cheap startups and "enterprises" that still use jQuery and Java -1, acting as if they're Google. You're not. You don't make the software they do, you don't pay as much, and working with you sucks.

If you're running a startup and you ask me for take-home assignments and expect me to spend two months relearning patterns I’ve forgotten, you need to pay me as much as FAANG does, or you need to humble yourself and see reality for what it is. Your software sucks, your management sucks, y'all suck. You're not that guy, pal. You're not that guy. If I'm getting a good ROI, why wouldn't I brush up on basic algo manipulation techniques? I'll gladly do it—I'll consider it an investment. If I'm going to be a good slave from your point of view can I at least make good money off it?

It's hard to read this as anything other than a bitter candidate who got rejected after a series of FAANG interviews. There are some legitimate criticisms sprinkled in, but to characterize everyone who made it through as slaves who are more obedient than you seems like a coping mechanism.

it's a common one :)

The very notion of obediency being a negative trait is flawed IMHO.

People working at humanly unfathomable size organizations being more obedient doesn't sound like an issue to me, nor would it correlate with other qualities, including intelligence or critical thinking.

So if someone told you they admired how obedient you are, you would take that as a compliment?

Just call me "conciliant" or "cooperative" if you want to make it sound more like a compliment. "Obedient" is just putting connotations on an otherwise neutral trait.

Reply on news.ycombinator.com