One thing I realized recently while interviewing candidates at my company is that it’s one of the few opportunities that individual contributors like myself have to exert significant power over someone else, and not everyone is prepared to handle it well.

Recently, we had a candidate come through that wasn’t a good fit for us (he claimed to be a cypress expert so we asked him to set cypress up in a dummy react repo and he floundered the entire time). One of my coworkers took some pot shots at the candidate, being deeply critical and rude, cutting the candidate off mid-sentence, etc. I was honestly embarrassed to be on the call and I thought it reflected poorly on my company. I’d never seen my coworker act like this before and it changed the way I felt about him.

I wonder how much of the leetcode interviewing culture is rooted in this desire to dominate candidates, since ICs rarely have opportunities to wield such power over others.

This post ought to be the final nail on the coffin of the cult of leetcode/whiteboard style inverviewing.

Just looking at this guy's repo and his writing style -- you'd be foolish to waste his time or yours on leetcode-style hazing. Your conversation should be strictly high-level. If you must, pick a file at random from one his larger projects, and ask a few straightforward quetions ("I'm new to Go - can you explain why I would use this datastructure here?") just to make sure the repo isn't a copy of someone else's, and he isn't outright trolling you. Apologizing as you're doing so, of course ("Sorry, but do you mind if I ask a silly-sounding question or two about something in your repo?").

That's all you need to do. Most candidates won't have work samples that are quite as slam-dunk, of course. But still, your own "smell test" can save you tons and tons of time (and the candidate, agony). It's really, really hard to fake one's way through questions like these -- and really easy to tell if someone is trying to do so.

Put another way, your basic mindset should be: "Trust, but verify". Not: "Joel Spolsky wrote that post 20 years ago claiming that 99.5 percent of all candidates are utterly incompetent. Therefore I need to torture this guy until he confesses."

At least as far as answering the "can he/she code?" question is concerned.

I preface my interviews saying that I'm we're going to have a conversation rather than a list of trivia questions. The goal is find out what the candidate knows, rather than if they know an answer to any specific question, or specific version of a technology. If I ask a question that is too easy, it's not a trick, it's a segue to more conversation. If I ask a question that's incomprehensible, it's because I don't have a prepped list in front of me and I'm making some questions up on the fly, and the candidate should just ask for clarification. Also, that a lot of my questions are open ended, or have multiple right answers and any of them are acceptable.

It's not really a pattern of interview I expect most people can implement immediately, but it really gives a good idea of fluency. I just have to home in on what they do know. The easy questions get some momentum going and provide context for the follow ups. When they don't know an answer I'll tell them the answer. Sometimes this leads to them adding some depth beyond that answer as they know what's going on but haven't worked with it formally, or have worked with it in passing, or maybe know it by a different name.

The best interviews are designed not to filter out bad candidates but rather to allow good candidates to demonstrate that they are good. The best companies know that and design their interviews in that spirit.

Some technical test interviews appear pointless to experienced candidates because they are designed to give an opportunity to someone without any experience to show that they know enough to get started. That's how some companies can hire people without work experience.

Many (most?) companies are simply bad at hiring and use poorly designed cargo-cult test interviews. They have a vague notion that more successful companies use test interviews so they try to do the same, only without designing an actual effective hiring process. As a result, their hiring is essentially random - they interview some people, which they put through a test interview ritual, and then hire a random selection of these people. Even if you can get a job at such a company, would you want to work somewhere where you'll end up with randomly selected colleagues? These also tend to be the companies that have high employee turnover - they have to let underperformers go to compensate for their random hiring, and the best people leave because they don't like their randomly selected team.

If you have a realistic view of your own skill and fit for the role and the interviews don't make sense then either you're overqualified or it's just a bad company or both, and you wouldn't want that job anyway.

Heh. I have 25 years experience and I fail phone screens too. :-D

It's fine, though. TFA goes into ways to improve the hiring process such that this sort of thing doesn't happen. But I don't mind it at all. I want to fail fast; if the company decides I'm not the right candidate, great, I'm glad it happened before we wasted time with more extensive interviews.

There are two possibilities. If they're right and I'm not a good fit, I don't want that job because I won't be successful there. If they're wrong, I don't want that job because the company isn't being successful at hiring me. The hiring process is looking for the wrong attributes, or the interviewer isn't properly trained, or... well, something, somewhere has gone wrong. There are no false negatives.

A company that's firing on all cylinders does a lot of hiring, and is good at it. They source solid candidates, and interview them thoroughly but quickly. If they're not hiring effectively, well, they're probably dysfunctional in other areas too.

It's important to remember that it's also YOU interviewing THEM.

The coding interview is an opportunity to get to know the company culture in a very feet-on-the-ground fashion. How the interviewer behaves and how they expect you to do things reflects upon them as managers, mentors, and in general people you'll be working with for potentially a long time.

- If they're forcing you to go against your natural flow, that's a red flag.

- If they're preventing you from building or explaining things as you'd normally do on the job, that's a red flag.

- If they don't allow you to consult the resources you'd normally do, that's a red flag.

- If they prevent you from testing your work and assumptions as you'd normally do, that's a red flag.

- If they're only looking for work and no conversation (all questions to you and none to them), that's a red flag.

I've had times during an interview where I've had to pause everything and explain that this is how I work, and how I would work if I were hired. Usually the interviewer will stop, reassess, apologize and we move on no harm no foul. I've also had occasion to stop the interview and say that we're not going to be a good fit, sorry and goodbye.

It's on YOU, the interviewee, to make sure that you're not getting bullied or coerced (either accidentally or deliberately). This is not a one-way street. If you don't push back, at best you get hired into an abusive or incompetent environment, and at worst they reject you after toying with you, wasting even more of your time and sapping your morale. Yeah, it's a bad time when one hires a bad employee, but it's MUCH MUCH worse to get hired into a bad company! You're taking a bigger risk than they are, so make sure you interview them well!

Breaking off an interview is not a bad thing; you're assessing THEM as much as they are assessing you, and eliminating the deadwood early is in your best interests, because YOUR time and resources are precious too.

Remember: THEY can fail phone screens, too.

Today's interview process seems eminently gameable by grinding LeetCode and watching YouTube videos on system design. In the last 4 months of job searching I've gone from barely being able to get past the question (reading under time pressure stresses me out), to convincingly passing about half of my recent phone screens. All I've done is one LeetCode per day and interviewed a couple of times per week. I'm not fundamentally any better of a software engineer than 4 months ago. The current system is great for zero-knowledge people with the time and mettle to study, and awful for accomplished but time-poor senior engineers.

And, why all companies have decided upon almost the exact same methodology, I can't understand that either. It seems to be the same double edged sword as the Common Application for college: you get more applicants because the incremental effort required to apply to college n+1 is low, but it drives down college admit rates as well as matriculation rates: the signal to noise ratio probably goes way down.

I have 15 years of experience, and seem to woo teams every time we do screening calls.

Could be how he describes the problem. Most of the time during code screens they don't want you to perfectly solve it. Talk it out. Someone who feels that perfect or bust is the only way to go will fail most of the time. Idk feels like something is missing. He's right, feedback loops suck.

Question is... Can he practice doing a phone screening with a friend? Does he know anyone who interviews? Does his current job allow him to interview or sit in some? Just being part of it can give great interview experience.

Around 10 years of experience is when I learned a ton of interview skills. Interviewing is indeed a skill in itself.

It's great when senior people admit they're no good at interviewing.

I've never passed a technical interview.

I got my internship at a company that thankfully valued informal broad technical discussion over a conventional technical interview, then from there I slid into a full-time job at the same company with no additional interview. By the time I applied for my second job I was senior enough not to be asked to do a technical screen.

I've attempted conventional tech interviews in between and absolutely crashed and burned! So I'm impressed by anyone getting through these interviews, because I can't do it!

at this point of my career i straight out refuse technical/coding interviews

i have a GitHub account with 7 years worth of contributions, multimillion dollar exit, projects online and previous senior roles on my cv

if they still don’t trust me to do my job, the one i’ve provably done about a decade, their loss

nowadays it’s easier to find high-dollar consulting gigs than deal with dysfunctional hiring processes

advice: get jobs from people you know

Interviewing is really tough. The OP replaced some coding questions with other questions and if he were to interview a bunch of people with them, we'd get another set of blog posts complaining how ridiculous his interview questions were.

"Why is it bad to write a file to the disk one byte at a time?"

What are they interviewing for, low level disk experts?

"Here's a stack trace from an open source project, can you tell me what went wrong?"

Oh sure, print-based debugging is awful, you just have to read stack traces from unfamiliar projects in the blink of an eye.

"Here's a CRUD app, copy existing code patterns to implement a new CRUD endpoint"

Ah yes, the reductive "everything is a CRUD app" - this interviewer doesn't understand that most applications don't fall under the simplistic "CRUD" moniker!!!!

I have sympathy because I program in a similar way as the author. Not so much with tests but with some kind of fast feedback loop where I do lots of guess-and-check. I don't know how I'd do in this kind of interview.

However...

> If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.

My sense is that 90%+ of these interviews is maintaining your composure, asking questions and generally coming off as well-adjusted and personable even if you don't know the answer or get stuck.

> Certainly there are a lot of confident, mediocre tall white men in the tech industry

That's some chip on his shoulder.

So here's my read on this, based on the post.

The author is focused with technical review, and as such he probably fails to see just how important personal review is. Yes, you are being reviewed technically, but you are also being reviewed personally. You may know a lot of technical things, but do I want you on my team? The phone interview is what i'm going to use to make that decision. Technical we can work over later, but only if you sound like someone I want on my team.

I'm always willing to say, "They look like a great fit for the team and our goals, and let's give them a chance to learn the tech" versus, "They know a lot of technical stuff and let's give them a chance to see if they can learn to work with other people."

I have 25 years of experience and I spent a year looking for a job, getting rejected after complex, time-wasting tests and endless voice interviews that went nowhere. At one point I had to take a cognitive test which I actually failed.

I eventually found something but it was really discouraging there for a long time.

Everything he said is spot on. I suspect algorithm interviews are optimized for FAANGS - e.g if you can do the whiteboard and coderpad under pressure and interruptions you'd statistically do well in FAANG. I suppose that's true otherwise they wouldn't be doing it. But this hiring process is extremely broken for most everyone else; FAANGs don't really care about false negatives; they have so many great people wanting to work for them its ok for them not to hire some great people. But this whole process seems problematic to me for smaller companies who are in great need of good people and aren't drowning in great resumes. You can't really afford to miss 50% of great people if you're a startup, and this process will do just that; it will let you hire good people but also not hire good people on a really bad margin. Companies who are not FAANGs, especially startups, are better off coming up with some hiring process like the author described; it's not perfect but it will have less false negatives.

About 11-years ago, I was in a bad shape after a disastrous Startup failure. I was looking for a job and out of many prospects, I had an interview with bookings.com. It started with a phone interview and they wanted to go technical right away; so started asking me the basics of CSS.

I was taken off-guard because I don’t remember what is the default value of float, or the list of default values for many CSS objects.

I explained that I don’t remember those as they usually pop up in the IDE when I start typing. However, if they want, I can show my open-source bare-bone drop-in grid framework I wrote sometime back or I can walk them through CSS Box-Model or even explain how I can help bridge the gap between designers and engineers.

Unfortunately, it ended as their time ran out. I got a rejected reply because I could not pass the basis of CSS on a phone call. That was the incident I promise myself that any candidates I interview in future will always get a chance to explain/prove their worth in the ways they know best.

I was in agreement with most of the article, but the final footnote came out of left field for me:

  7. I have a bunch of ideas around testing how quickly and how accurately people can type, or accurately transcribe text from a second screen, that I think could be decent predictors of job performance but I'm not sure are fair to test out in a professional context without academic research that could validate them at least a little bit.

Can anyone explain how including such a thing in an interview is relevant at all?

Your code on github is pretty slick. I love the documentation.

Leetcode is an exam that you can study for. For me, it's pretty damned hard and I dislike it.

I can think of three reasons why someone might be good at those kinds of problems:

• You just have a knack for it.

• You are very intelligent.

• You practiced a lot.

Which one of those can you do something about?

Every time I force myself to grok a new leetcode trick, I've truly learned something. Something irrelevant in my ten years of programming, but allegedly an indicator of someone who might be good at what we do.

> ” I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.”

That’s exactly what happens to me. The thing is, I am not as fast or experienced as the author. I don’t do well on those Triplebyte quizzes because they put data structures and algorithm question among even in the frontend quiz. And also ask trick questions that I usually run the code to see what happens, not spend 3 minutes imagining what the outcome would be. I much prefer take-home tasks even if I take 4 to 5 hours when instructions said I should take two.

So, I am just terrible at technical assessments in general. And I don’t have that solid CS knowledge that some positions require or people think is the minimum necessary for me to be called “engineer. I don’t care. I am happy being called a “developer”.

The challenge is: how do I find a job post that would hire for what I am good at?

I am good at shipping things. I am good at communicating with non-engineers in general. I am good at scoping, understanding the problem that people want to solve with code and proposing the fastest way to get there. I am good at creating simple code that it’s easy to understand and do what’s needed to be done with good performance. I am good at writing tests that make sense. I am good at focusing and organizing my time to deliver working code in the agreed deadline. I am good of delivering good work with autonomy. I am good at working as a team. I am quick to learn new tech. I am quick to understand legacy code and to improve it.

Despite my poor technical interview skills, I was never fired for poor technical skills. On the contrary, I was always complimented for what I ship, how quickly I learn and contribute when dealing with new tech/codebase, and how I quickly improve upon feedback.

So, how do I find a job whose hiring process value those, not the former?

I am considering not even trying if the process has a mandatory live-code step or leet code.

Good candidates do not apply if leetcode is involved; good candidates know they can code and they want to have interviews where they are asked, from a high level perspective, about past projects and the like. On the other hand, bad candidates know they cannot code nor talk about past projects in a decent way, but it’s easier for them to cheat by submitting copied pasted code than to talk about software.

By using leetcode in your interviews you are giving bad candidates an opportunity to apply for a job in your company.

I truly despise the leetcode style of interviewing. It comes off as completely lazy and ineffective for most companies, and is a terrible indicator of how talented individuals are. I've been in the field for about a decade and have been on both sides of the interview table more than I can remember. I'm at the point where if I get asked these kinds of pointless questions at a screening phase, it is a signal I probably don't even care to work for them. If they don't care enough to actually create a meaningful interview process rather than copy+pasting the dumb Silicon Valley company pointless leetcode interviewing template, then they're clearly not somewhere I want to work.

The worst experience I had was applying for a couple of large companies like Peloton and Compass. They outsourced the leetcode interviewing process to some arbitrary company in Russia. Not only did I not have the chance to ask any questions of the company, but I had to do absolutely pointless trick questions for an arbitrary third party. It was an absolute waste of time that I only did once and told the other company basically to fuck off. Seriously, if a company can't even run their own interviews what is the freaking point?? It's an absolute absurdity and I cannot believe that this practice is so common.

At last company we used an online tool to screen junior/intermediates and the whole point of that tool was "Here's the task, here's the tests that need to pass when you're finished, feel free to write more", and someone writing more unit tests to exercise their code was a big positive.

Asking someone to implement stuff without running it sounds counterproductive to me. About as effective as asking them to write syntactically valid code on a whiteboard.

Companies are missing out on tons of great, talented individuals who are frightened to endure Leeetcode-like interviews. Are there any firms that give candidates choices on how to demonstrate they’re a good fit for open positions? Maybe you do like grinding Leetcode algorithm questions, maybe you want to create a new service that satisfies requirements and discuss the design choices, perhaps you’re really good at contributing to existing projects.

I read about three paragraphs in and then stopped.

Coderpad tests where you're encouraged not to write tests, can't hit the run button, and can't use reference material? Worthless. Most people - not just the author - are going to fail those, and they are not representative of the work environment, so what's the point?

We use Coderpad for one of the 3 interviews we give candidates. We do a tech screen first, then the coderpad, then a panel interview; the author is right in that it's about a 5-6 hour process overall (for the candidate). The coderpad is as much about watching how you go about solving a problem as it is you getting the right answer, although that certainly counts. We want to see if you pay attention to the question and implement what we asked for (not brain teaser 'gotcha!' stuff, simple stuff like "write a function that does ... and returns a boolean" - a lot of people will have their function print an answer and return nothing, or won't write a function at all, or will ignore other key requirements), that you can explain your approach, that you can think of some test cases, and that you can accept help/coaching if you're clearly stuck. We want people to do it in a language they are comfortable with, and looking up syntax is OK.

Overall I'm not sure how much value we get out of coderpad. It's manufactured pressure, just like a whiteboard exercise in an in-person interview. You can tell candidates what I wrote above, and try to convince them that it's not about getting the right answer as much as how you get at the answer, but that doesn't really work. Some people are not going to do well in those interviews regardless of their ability.

I conceptually like the idea of dropping coding screens, etc - but how do you objectively identify what you're looking for in a candidate without adding bias to the process?

I.e., at least with a coding question, you can set up objective criteria. If you ask someone about their work, it might be a good experience but you're also setting yourself up to bias towards people who talk/think like you.

> I often make trivial mistakes just trying to get a "first draft" of a program out

In my experience, it's helpful to add simple tests as you go. I have done some live coding tests in Python recently, which I'm not super familiar with, and the first couple I did, I made a lot of trivial errors that caused my solution to fail until I went back and cleaned them up. Luckily the interviewers kept their mouths shut while I was coding, and I was able to clean up quickly afterwards, but I could tell it wasn't a great look to say, "Okay, I _think_ this solution is correct," only to have it flame out spectacularly.

After those first two, I started writing simple tests for everything I did. Not only did it avoid embarrassing fails when the solution was supposedly complete, not only was it quicker overall, but every interviewer I've done this with has commented approvingly about it.

yeah and if you are an anxious person like me, (i may be on the spectrum, i have some social issues), writing code in front of people makes me very anxious, it takes me back to my childhood when my dad would scream at me for being dyslexic, i got my b’s and d’s mixed up.

i know that is not what is happening during an interview but, it’s how i feel. and this prevents me from getting ahead in an industry i am madly passionate about

I think it is fortunate that great engineers like OP are rejected in Leetcode style interviews. The benefit is twofold:

- It makes fresh graduate noobs (or even just noobs in general) able to compete on equal ground on high-paying job prospects. Think about it, if every high paying jobs out there value experience over leetcode style of interviews, then young noob programmers won't be able to rake great salary because all of those jobs are filled already by experienced engineers

- Great engineers should just use their talent somewhere else in startups, create more innovation, create more wealth rather than helping the big tech giants become bigger

Quite honestly, if the job description says "we are looking for the best of the best" or "we are looking for a talented java developer" I know this job isn't for me. Same with algorithm questions, if the interviewer asks me an algorithm question, I will switch off and politely put a cross that this role isn't for me. I don't have cs background and my CV is clear that I've not done anything like that.

Edit: I am not a great coder by any means. I just don't like to waste my time when it's clear I am not a fit for the company or the role.

I worked with Kevin at a startup (Otto smart lock). He's a solid developer that I'd be happy to vouch for.

You don't need to have someone write code to find out if they know how to code, or how well. Simply ask a series of increasingly deeper questions about a range of coding topics that elucidate both technical expertise and experience. If you don't know all of that yourself, find someone else that does and have them do the interview. I've always been able to conduct interviews and find out someone's strengths and weaknesses without seeing them write code or fix a broken thing. Maybe I'm just some magical unicorn and this is a super rare skill? But I doubt it. I'm just looking for the tell-tale signs of someone who has done real work and learned things in that process.

The other thing is, as someone hiring, my main concern is just making sure the candidate has the specific skillset or experience I need. The person may learn quickly, but I probably don't have time for them to learn the one technology I need them to use ASAP. A lot of candidates end up getting rejected because they put something on their resume that we really need but they don't know well enough. And some just seem to be trying to reach and do a job they don't have experience in. It's hard to find someone who has just done the job I need done and isn't trying to get some other job.

Had a guy with 20 years experience at UPS or One of those come in for an interview.

He had spent the 20 years copying and pasting the same bit of html and changing the text.

No clue what an array or anything was.

> In theory a phone screen is supposed to evaluate whether a) this person would be good at the job being hired for and b) whether it's worth investing another five hours in trying to hire this person.

They also screen whether or not you communicate well, your motivations for looking for work and whether that matches the role and future growth of the role, whether there are any logistical or compensation-based blockers to the role...

Frankly, getting all the deal-killers out of the way is the point of the phone screen. Figuring out whether you can actually do the job, and do it well, is for later phases of the interviews.

I feel like the hiring process is often misunderstood. The first screen is one of two things - if you are working with a company directly, it is just a screening for deal-killers. If you are working with an outside recruiter, it is them trying to understand you to know how to market you to the hiring manager.

In either situation, though, if they are getting into remote coding of algorithms on an initial phone screen, something is really off in their hiring process.

> Coderpad must work for some people since companies are able to hire a nonzero number of engineers, but it is definitely not a good fit for me.

Seems everywhere I've applied recently has been using Coderpad.

Lately I've been accepting interview requests for principle roles from on-site recruiters, and I've been consistently rejected after these Coderpad tech screens. What's bugging me, however, is the "challenges" have all been softball questions. Reverse a string. Demonstrate an understanding of closures. Write a function that tests if two strings are anagrams. Write some basic React. Create an interactive form. I breeze through well enough, then it's either an immediate rejection or else they ghost me. Not once do I get farther than that. I'm not even mad, just confused as hell.

This is coming from the perspective of someone who was getting used to offers from the first job they applied to. If there's something off-putting about me lately, I wish I knew.

It's tricky to interview people lacking experience, but with >=decade of experience just do deep dives into past projects. You're basically talking to one of if not the authority on whatever it was they worked on, let them tell you all about it, down to the weeds. If they can't, then you've probably got a problem.

I have 15 years of experience and have found unless I'm contacted directly by the internal recruiter of a company it's pretty much impossible to even get a reply to a job ad.

I don't know how people who are new to this industry are managing to find work. Pretty sure I'm getting filtered near 100% of the time.

I really love those suggested questions. I made a note to come back to this next time I have to do some interviews.

I don't ask candidates to code on a phone screen. For coding proficiency, I show them code with flaws and ask them you do a code review. To break the ice I just ask them to describe the program behavior line-by-line.

For a good candidate, it's a jumping off point for a deeper discussion.

Hold your head high. Being good at algorithms is a life hack to get a tech job. You did it the hard way.

Companies are full of people who do well at a whiteboard. You're the rare variety that companies NEED MORE of (even though they don't know it).

> Most phone screens involve implementing some fairly complex algorithm3 in one or multiple steps on Coderpad, an online text editing tool

Well OP, you lost me there. That's not my approach interviewing, nor is it what I've experienced.

coderpad interviews test performance anxiety. there is a set of programmers without performance anxiety and there is a set of programmers with performance anxiety. whats interesting is that the cargo culting of coderpad interviews from google on down means google takes the best programmers with acting skills (thanks to infinite money) and everyone else takes the second tier of programmer with acting skills. the best programmers without acting skills (like kevin here) are left out. the plus side, for them, is they may find the set of companies who arent cargo culting and might really have a clue.

I think I would prefer to work with someone who optimizes their strengths the way kevinburke describes in his post. However as a manager I would structure phone screens to quickly filter out candidates who would never work out, no matter how optimal they seem. This is an art and odds are candidates are never going to have the perspective to appreciate the aesthetic of the completed work…

I feel this differently.

I too can pass on-site interviews, but my problem is I don't even get a first phone screen to begin with, they discard me without even spending 5 minutes on me.

You Americans (even afroamericans) have absolutely zero clue about how racist your companies actually are.

"But Google and Microsoft CEO are Indian!" Yeah, but not really.

By the way, I'm Southern European, with a Southern European sounding name.

The secret to these is to not play the game. If you send me to a website like coderpad I'll just say thanks but no thanks. If my code portfolio and extensive experience isn't enough to get me to talk to one of your real engineers and find out what I know (that I'm not bullshitting) then we should both stop wasting our time and you can find someone else.

Yeah well, I recently flunked a role I had years of experience doing. The expectation I assume in some of these phone screens is that you will lie to get the job. I refused to tell them that I had done something I hadn't and laid it out to them why something they were asking for wasn't possible in an IC role. I refuse to play these games.

> I'm not fast at reasoning about code, and I often make trivial mistakes just trying to get a "first draft" of a program out. If I get behind or the interviewer starts interrupting to ask about the bad code I'm writing I get very stressed and have trouble both listening to the interviewer and trying to address the issues with the code.

Sounds to me that the author likes to program by "sketching". I do too! Paul Graham recommends this in Hackers and Painters.

> For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging. > > For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.

On the other hand, as the post describes, interviews are geared towards a more waterfall-y approach. I find this frustrating as well, but I think that there is something really important to keep in mind that this post misses, and that most conversations about coding interviews miss. The question is whether something is _predictive_ of job performance.

For example, consider the question "What is your favorite number?". Imagine that the larger the answer to that question, the more likely you are to perform well as a developer. You might object "But I'm never doing anything relevant to my favorite number on the job!". IMHO, it doesn't matter. The goal is to predict who will perform well on the job, and if having a large favorite number does this, it should be incorporated.

Now consider the question of how well you perform on waterfall-style interview questions. Like "What's your favorite number?", it isn't something that you will find yourself doing on the job. But that isn't the right question. The right question is whether or not it is predictive of job performance.

Of course, it seems unlikely that "What is your favorite number?" would predict job performance. And it seems unlikely that if you never code in a waterfall-style on the job, that coding in that style during an interview would predict job performance. But maybe it does. I'm skeptical, but who knows. More importantly, I think that this is the question that needs to be asked. And without strong data, it's hard to be too confident in the answer.

Didn't open this post/article because I assumed it was about mobile phone display technology. Couldn't have made just a tiny bit more effort on the title wording?

As Jensson points out, smart people can grind leetcode, so if you have good experience, grinding leetcode shows you're smart enough to get the job. If you don't grind, there's no signal of how good you are at coding, so it's a no hire.

Really, it's on you if you don't do what needs to be done to get the job. So get grinding! Or remain unemployed.

From a labor perspective, the typical dev interview process is profoundly anti-worker.

You're probably just "not a good fit" and lay the blame on a technical interview.