Is the Coding Interview Dead? What 169 JavaScript Job Posts Say

An engineering manager at Anthropic recently said he stopped running coding interviews for his team. His reason was simple. Claude now does better at them than the candidates do.  He also had a line for junior engineers that travelled fast: hunger beats tenure.

Within a day the story was everywhere, and the headline had grown. One manager dropping one interview format for one team became "the coding interview is dead." If you are a JavaScript developer with an interview next month, that headline is a strange thing to read. Should you stop practicing? Should you stop doing take-homes? Should you walk into the next technical round and say you would rather show how you prompt?

I run a job board for JavaScript developers, and I read every job post that goes on it. So instead of guessing, I went back through every JavaScript job published on jsgurujobs.com in the last 90 days and checked what the posts actually say about the coding interview, and about AI.

I expected to write an article about a headline that had run ahead of reality. I expected most posts to still ask for a take-home or a live coding round, and I planned to tell you not to believe the hype.

The data said something different, and more useful.

There were 169 JavaScript job posts in that window, published between August 14 and November 12, 2026. Only 10 of them mention a coding step in the hiring process at all. That is 6 percent. Meanwhile 58 of them, a full third, say that AI tools are part of the job itself. Some of them name the tools. One says knowing them is mandatory.

So job posts have not killed the coding interview. They have mostly stopped talking about it. And they have started talking, loudly and specifically, about something else.

Here is what I found, what it does and does not mean, and what I would do if I were interviewing this winter.

Why a Silent Job Post Is Not a Dead Interview

Most JavaScript job posts do not describe their hiring process at all. Out of 169 posts, only 47 explain how the hiring process works, with steps, stages, or a rough timeline. That is 28 percent. The other 72 percent describe the role, the stack, the salary if you are lucky, and stop.

This matters before you read any other number in this article. If a post says nothing about its process, it is not telling you there is no coding round. It is telling you nothing. A company that never mentions a take-home can still send you one on day three. In my experience reading these posts, the companies that write out their process are usually the ones that have thought about it, and the ones that stay silent are often running whatever their last hiring manager set up.

So I am not going to tell you that 94 percent of companies dropped the coding interview. That would be the same mistake the headlines made, only with a spreadsheet attached.

What the data can tell you is what companies choose to put in front of candidates. A job post is a sales page. The company decides what to say about itself in the few hundred words you will actually read. When a third of those pages spend words on Cursor and Claude Code, and only one in seventeen spends words on how they will test your code, that is a signal about what they think matters now. It is a signal about what they want you to think matters, too.

It also changes how you should read a post. If the company describes its process, read it twice, because it is the most honest part of the page. If it does not, ask about the process in your first conversation. A recruiter who cannot tell you the steps is giving you information as well.

The 10 Job Posts That Still Test Your Code

Ten of the 169 JavaScript job posts on my board say there is a coding step in the interview. Seven mention a take-home assignment. Four mention live coding or a pair programming round, and one post mentions both.

The take-homes are short now, at least on paper. The ones that give a length say one hour, ninety minutes, or about two hours. That is very different from the weekend projects people complained about a few years ago. One post puts the take-home at step one of the process, before you have talked to an engineer. Another puts it after a culture fit conversation. One describes it as a chance to "prove that you can" do the work, and gives you ninety minutes to do it.

The live rounds look like pairing, not puzzles. One post lists a ninety minute pair programming interview, followed by a separate system design interview. Another lists a pair programming task between the engineering interview and the final round. A third ends the whole process with a live coding test as the final round. I did not find a single post that mentions algorithm puzzles or whiteboard problems in the hiring process. If those rounds still happen, companies are not advertising them.

And then there is the post I keep coming back to. One company, hiring a senior product engineer, wrote that instead of a take-home task, you will spend up to ninety minutes with two of their engineers, building on a real piece of their product. After that, you talk with the founders about what you would build.

That is the most interesting sentence in the whole dataset. It is not "the coding interview is dead." It is the coding interview moving from a fake problem to a real one, from alone at home to together on a call. You still write code. You just write it in their codebase, with people watching how you think.

If that is where interviews are going, the preparation changes. Memorizing patterns helps less. Being comfortable reading code you did not write helps more. I wrote about that skill in what interviewers actually write about you after a JavaScript interview, and it matters even more in a session where two people watch you find your way around their product.

A Third of JavaScript Jobs Now Expect You to Work With AI

58 of the 169 JavaScript job posts on my board say that AI tools are part of the daily work. That is 34 percent, more than five times the number that mention any coding step in the interview.

These are not vague lines about "staying curious about new technology." They are specific. Cursor appears as a work tool in 25 of the posts. Claude or Claude Code appears as a work tool in 34. Copilot, Codex, Windsurf, and a handful of newer agents show up next to them. One post says plainly that proficiency in Cursor, Claude Code, or Codex is mandatory. Another says every role at the company uses AI tools daily to amplify output. Another tells you to work AI-first every day. Another says coding agents are simply in daily use on the team.

Read those lines as a candidate and the message is clear. The company is not asking whether you are allowed to use AI. It assumes you do, and it wants to know how well.

There is a second group worth separating. 40 of the posts, about a quarter, say the job involves building AI features into the product itself. LLM pipelines, agent features, model APIs wired into a web app. Fifteen posts ask for both. So when people say "AI skills" they often mix two different things. Using an assistant to write and review your code is one skill. Building a product on top of a model is another, with its own problems around cost, latency, evaluation, and failure modes. A JavaScript developer can be very good at the first and have never touched the second.

I also found one line that made me smile. A company asked applicants to feel free to use AI to polish their written answers, but said the answers should be their own. That one sentence describes the whole situation better than any think piece. Use the tool. Do not hide behind it.

If you have been treating AI tools as something to keep quiet about at work, this data should change your mind. A third of the companies hiring JavaScript developers on my board are putting those tools in the job description. I covered the tension this creates in your company wants you to use AI all day and then bans it in the interview. The posts I read this quarter suggest the contradiction is starting to resolve, slowly, in favor of the tools.

What This Means for How You Get Tested

When a job post asks for AI fluency but describes no test for it, the test moves into the conversation. That is the practical consequence of these numbers, and it is the part most candidates are not ready for.

Think about it from the hiring manager's side. They wrote in the post that Claude Code or Cursor is part of the daily work. They have not built an interview round for it. So the questions come up in the technical conversation instead. How do you use these tools? When do you stop trusting the output? What did an agent get wrong last week, and how did you notice? Show me how you would approach this change with your setup.

Those are not trick questions, but they are easy to fail if you have never thought about your own workflow out loud. "I use Copilot for autocomplete" is a weak answer. A strong answer describes a real loop. What you hand to the tool, what you check yourself, where you have been burned, and what you changed afterwards.

The same goes for the live sessions. If a company pairs with you on a real piece of their product, they may let you use your tools, and they will watch what you do with them. A developer who generates a large diff and accepts it without reading will look worse than one who writes less and explains more. Speed is not what they are measuring. Judgment is.

And you still have to be able to code. Seven companies in a small sample still send take-homes, and some of them will ask you to explain every line. A take-home that was obviously generated and never understood is easy to spot in the follow-up call. The Anthropic manager's point, as I read it, was not that coding stopped mattering. It was that a standard coding puzzle stopped telling him anything useful about a candidate. That is a statement about the puzzle, not about you.

One more practical point, because it has cost real developers real money. A take-home from a company you cannot verify is a security risk before it is anything else. Earlier this month a reader reported a fake React and Web3 job on my own board. Candidates who applied were asked to install a "video call app" from the command line, and that app was malware. I took the job down the same evening and wrote up how the scheme works in fake job interview malware is targeting JavaScript developers. Real companies want to see how you write code. Only fake ones need you to run theirs.

Why I Think the Headline Got It Backwards

The coding interview is not dying, it is moving to where the real work is. That is my position after reading these posts, and it is different from both the excited version of the story and the dismissive one.

The excited version says coding tests are over, so stop practicing and start prompting. I think that is bad advice. Ten companies in this small sample still put a coding step in writing, the strongest example replaced a take-home with live work in their own codebase, and every company that lists AI tools will still need you to read, judge, and fix what those tools produce. You cannot judge code you could not have written.

The dismissive version says nothing has changed, the headline is hype, keep grinding the same problems. I think that is also wrong, and the data is why. When a third of job posts name AI tools and one says they are mandatory, the job has already changed, whether or not the interview has caught up. Preparing only for the old interview is preparing for a test that fewer companies bother to describe, for a job that no longer looks like the one you are practicing for.

What I see on the board is a slow swap. The puzzle at the start of the process is losing its place. In its place, companies describe the actual work, ask about your actual workflow, and when they test you, they do it on something real. That is harder to fake and harder to cram for. It also favors developers who have been doing real work with these tools for a while, not the ones who learned the right vocabulary last week.

There is a part of this I genuinely like. A ninety minute session building on a real product, with two engineers and a conversation with the founders afterwards, is a better interview for both sides than a timed puzzle ever was. If that is what the death of the coding interview looks like, I am glad to see it go. I just do not think we should pretend it already happened everywhere because one manager on one team said so.

What I Would Do Before My Next Interview

If I had a technical interview next month, I would stop thinking about it as a coding test and start thinking about it as a conversation about how I work. I would pick two or three real changes I made recently with an AI tool, and practice explaining them out loud. What I asked for, what came back, what I rejected, and why. I would be ready to say where these tools fail for me, because every experienced interviewer will ask, and "they don't" is the wrong answer.

I would still keep my hands warm. I would build something small without any assistant once a week, just to make sure I still can. Seven companies in a small sample sending take-homes is not zero, and the follow-up questions on those take-homes are where people fall apart.

And I would read the job post twice. The process section, if it exists, is the most honest part of the page. The AI tools line, if it exists, is the clearest hint of what the job will feel like on a Tuesday afternoon. Both are worth more than the list of frameworks in the middle.

A note on the data, so you can weigh it properly. These are 169 JavaScript job posts published on one job board over 90 days. They are not the whole market, and some companies on the board are there because I chose them. I searched titles and descriptions for specific phrases and then read the matches by hand, removing false hits like "pair programming" as a daily team practice or AI tools used to screen applications. Absence of a phrase does not prove absence of a practice. Treat these numbers as a careful look at one window, not a census.

The interview did not die this month. It moved closer to the job.

If you want to see the posts behind these numbers, the current JavaScript jobs on jsgurujobs.com show the process and AI lines where companies wrote them, and the weekly JS Pulse newsletter sends five of them, with salary and where they actually hire, every Monday.

FAQ

Is the coding interview dead for JavaScript developers? No, but it is changing shape. On jsgurujobs.com, 10 of 169 recent JavaScript job posts still describe a take-home or live coding step, and the strongest example replaced the take-home with live work on the company's real product.

Do JavaScript job posts mention AI tools? Yes, about a third of them do. In 169 posts from the last 90 days, 58 said AI tools are part of the daily work, with Cursor named in 25 posts and Claude or Claude Code in 34.

How should I prepare for a JavaScript interview if companies expect AI skills? Prepare to explain your real workflow with AI tools out loud. Pick recent changes you made with an assistant, and be ready to say what you accepted, what you rejected, and where the tools failed you, while still keeping your ability to write code without them.