Ask HN: What is interviewing like now with everyone using AI?

> The adversarial interviewing really hurts the entire feel of the process

Agreed. I have been through technical interviews where at the end, my feeling as a candidate was "I don't want to work with this asshole".

Man, I really hate it!

I can't fathom how making the whole process being all hostile makes any real sense!

We all want that great person to show up and really help, not just cope or put up a facade to survive.

Yet, that is exactly what happens. People that other people expect to bond with get put through the wringer....

Seems counterproductive to me.

Please report back when you do!

I don't remember how I came up with the idea. Maybe I just like learning things.

One candidate even wrote after their interview, "that was fun!"

Have you ever had a candidate say that? This was the moment when I realized I might be on to something. :-)

Interviews are too often an adversarial thing: "Are you good enough for us?"

But the real question is would we enjoy working together and build great things!

People talk about "signal" in an interview. Someone who has an interest they are passionate and curious about and likes to share it with others? That's a pretty strong signal to me.

Even if it has nothing to do with "coding".

Oh yes, they are!

You just need a small file, like a point file. Any gasheads remember those? And a single edge razor blade or the like to lift the reed.

To raise the pitch, you file the end of the reed, making it lighter so it vibrates faster.

To lower the pitch, you file near the attached end of the reed. I am not sure on the physics of this and would appreciate anyone's insight.

The specific tuning I've done many times is to convert a standard diatonic harp (the Richter tuning) to what is now called the Melody Maker tuning.

The Richter tuning was apparently designed for "campfire songs". You could just "blow, man, blow" and all the chords would sound OK.

Later, blues musicians discovered that you could emphasize the draw notes, the ones that are easy to bend to a flat note to get that bluesy sound. This is called "cross harp". For example, in a song in G you would use a C harp instead of one tuned in G.

The problem with cross harp is that the 7th is a minor 7th and you have no way to raise it up to a major 7th if that would fit your song. And the 2nd is completely missing! In fact you just have the tonic (G in this case) on both the draw and blow notes where you might hope to hit the 2nd (A). There is no A in this scale, only the G twice.

To imagine a song where this may be a problem, think of the first three notes of the Beatles song All My Loving. It starts with 3-2-1. Oops, I ain't got the 2. Just the 1 twice.

This is where the file comes in. You raise the blow 1st to a major 2nd. And you raise the minor 7th to a major 7th in both octaves.

Now you have a harp with that bluesy sound we all love, but in a major scale!

Isn’t every physical thing tunable since its materials have a resonant frequency?

I am! But I am now on the other side of the virtual table.

IBM conducted a mass layoff a few months ago, and as our little team lost our only customer at the time (this is public information), many of us were let go. Ah well.

One door closes, another opens.

If anyone out there is curious about "who is this guy with the strange and interesting ideas about interviewing", you can find my LinkedIn and other contact info in my HN profile.

People mostly fix some issue, or implement a feature at work. And then somebody outside can do the same in the same time.

In reality they need to look at this like onboarding a new team member.

If I have a public portfolio of existing projects on GitHub, couldn't that replace an assignment? Choose one of my projects (or let me choose one), and let's discuss about it during the review interview.

>>We did a lot of these assignments and no one assumed that they will be hired if they complete it. Its about how you communicate your intent.

Be upfront that finishing the assignment doesn't guarantee a hire and very likely the very people you want to hire won't show up.

Please note that as much as you want good people to participate in your processes. Most good talent doesn't like to waste its time and effort. How would you feel if someone wasted your time and effort?

Yeah, my resume does include a summary of what I did each job, but it sounds like the brag doc idea would involves much more detail.

Honestly, putting those details in writing in a way that I retrain after leaving might leave me vulnerable to claims of violating my corporate NDA. But legalities aside, yes, it would help with these kinds of interview issues - prospectively only of course, not retrospectively.

Annoyingly, it's also exactly the kind of doc that's difficult for people with ADHD to create and maintain rigorously, even though people with ADHD are more likely than average to need the reminders of those details. A lot of ADHD problems are that kind of frustrating catch-22, especially when interacting with a world that is largely designed around more typical brain types.

one of my buddies was a navy psychologist assistant. was a corpsman (navy medic) who moved that way.

dude maintained a "me wall" of achievements, commendation medals, etc. plus a file full of other crap. he mentioned he got a lot of promotions because you have a section to fill out where you describe all the shit you did over the least year, and he always came with examples...

Thanks for being understanding and compassionate about the situation! I like your idea of a time limited freelance gig, though immigration obstacles do sometimes make that quite complicated (as in my current situation). It's way better than not considering that people might have a reason for a resume with gaps or other irregularities which is not being a bad employee.

Beyond immigration types of obstacles, somehow recruiters and hiring managers rarely consider how many bad managers, bad executives, and bad companies there are when evaluating gaps and short tenures in an employee's resume. But equally, discussing those matters during an interview risks being seen as unprofessional and unreasonably negative. "Why did you leave this company?" "Oh, the warnings I got about the leadership from a former employee before I joined turned out to be true, and they didn't want to hear professionally presented necessary feedback about emotional safety in an emergency incident response situation, so they fired me without a single meaningful 1:1 discussion other than trying to assign blame." / "Oh, the CEO was enough of a problem that the investors eventually replaced him in a subsequent funding round despite him being the majority shareholder, but that was long after I had resigned or been fired due to that CEO's particular problems." / "Oh, they communicated in a very idiosyncratic way which didn't work for me and which I haven't seen at any company before or since." / etc. Most of that doesn't fly in an interview, but equally, even if it did, saying too much of that sounds like making up excuses for oneself even when it's 100% true. Same thing for why a job search doesn't succeed quickly.

Ours is a messy and imperfect industry, and it sucks that interview candidates have to pretend otherwise to seem like they'll be reasonable employees. Meanwhile the companies and executives that act in those ways get to present whatever positive and successful image they want, and they get to praise each other for firing fast or cutting costs with attrition or layoffs.

What if I use an LLM but I understand the code?

The drawback is that elements in a hashmap can’t be sorted and accessing a specific element by key is slower then accessing something in an array by index.

Linear search is easier to implement.

These are all trivial questions you ask to determine if a person can develop code. The hard questions are whether the person is the cream of the crop. The amount of supply of developers is so high most people don’t ask trivial questions like that.

"Drawbacks" was the wrong word to use here, "potential problems" is what I meant - collisions. Normally a follow up question: how do you solve those. But drawbacks too: memory usage - us developers are pretty used to having astronomical amounts of computational resources at our disposals but more often than not, people don't work on workstations with 246gb of ram.

If you really need to test them / check that they haven't used an LLM or hired someone else to do it for them (which was how people "cheated" on take-home tests before), ask them to implement a feature live; it's their code, it should be straightforward if they wrote it themselves.

> ... LET them use LLMs and see whether they can accomplish 10X what a coder 3 years ago could accomplish...

Do you seriously expect a 10x improvement with the use of LLMs vs no LLMs? Have you seen this personally, are you 1 10th the developer without an LLM? Or is the coding interview questions you ask or get asked, how to implement quicksort, or something?

Let's make it concrete, do you feel like you could implement a correct concurrent http server in 1/10th the time with an LLM than what you could do it without? Because if you jut let the LLM do the work I could probably find some issue in that code or alternatively completely stump you with an architectural question unless you are already familiar with it, and you should not be having an LLM implement something you couldn't have written yourself.

When you're operating a small furniture company, your master craftsmen can hand-fit every part. Match up the hole that's slightly too big with the dowel that's slightly too big, which they put to one side the other day.

When you're operating a huge furniture company, you want every dowel and every hole the same size. Then any fool can assemble it, and you don't have to waste time and space on a collection of slightly-too-large dowels.

To scale up often means focusing on consistency and precision, and less on expert judgement and care.

The desire for a scalable, standardized scoring mechanism so they can avoid lawsuits.

Was it in the US? Unless it’s Walmart, there is no company in the US that is larger than the largest FAANG by headcount.

Well, I respect the scale and speed. My process was still working fine at ~5 per month. I have doubts it'd work with orders of magnitude more. There's a lot of intuition and finesse in there, that is probably difficult to blindly delegate. Plus, big companies have very strong internal forces to eliminate intuition in favour of repeatable, measurable processes.

I have a consultancy - we mostly do development, but I also do quite a bit of "consulting CTO" work. Quite often, that means helping with hiring.

But hiring is nowhere near my full time job, thankfully :D

AI gives super powers because it saves you an insane amount of typing. I used to be a vim fanatic, I was very efficient but whenever I changed language there was a period where I had to spend getting efficient. Setup some new snippets for boilerplate, maybe tweak some LSP settings, save some new macros.

Now in cursor I just write "extract this block of code into its own function and set up the unit tests" and it does it, with no configuration from my part. Before I'd have a snippet for the unit test boilerplate for that specific project, I'd have to figure out the mocks mysel, etc.

Yes, if you use AI to just generate new code blindly and check it in without no understanding, you end up with garbage. But those people were most likely copy pasting from SO before AI, AI just made them faster.

>I feel like I am taking crazy pills that other devs don't feel this way.

Don't take this the wrong way, but maybe you are.

For example, this weekend I was working on something where I needed to decode a Rails v3 session cookie in Python. I know, roughly, nothing about Rails. In less than 5 minutes ChatGPT gave me some code that took me around 10 minutes to get working.

Without ChatGPT I could have easily spent a couple hours putzing around with tracking down old Rails documentation, possibly involving reading old Rails code and grepping around to find where sessions were generated, hunting for helper libraries, some deadends while I tried to intuit a solution ("Ok, this looks like it's base64 encoded, but base64 decoding kind of works but produces an error. It looks like there's some garbage at the end. Oh, that's a signature, I wonder how it's signed...")

Instead, I asked for an overview of Rails session cookies, a fairly simple question about decoding a Rails session cookie, guided it to Rails v3 when I realized it was producing the wrong code (it was encrypting the cookie, but my cookies were not encrypted). It gave me 75 lines of code that took me ~15 minutes to get working.

This is a "spare time" project that I've wanted to do for over 5 years. Quite simply, if I had to spend hours fiddling around with it, I probably wouldn't have done it; it's not at the top of my todo list (hence, spare time project).

I don't understand how people don't see that AI can give them "superpowers" by leveraging a developers least productive time into providing their highest value.

Devs who don't feel that way aren't talking about the stuff you're talking about.

Look at it this way - a powerful debugger gives you superpowers. That doesn't mean it turns bad devs into good devs, or that devs with a powerful debugger never write bad code! If somebody says a powerful debugger gives them superpowers they're not claiming those things; they're claiming that it makes good devs even better.

> They just say, well the AI picked this, as if that means something in and of itself.

In any other professional field that would be grounds for termination for incompetence. It's so weird that we seem to shrug off that kind of behavior so readily in tech.

Depending on what language you use and what domain your problem is in, current AIs can vary widely in how useful they are.

I was amazed at how great ChatGPT and DeepSeek and Claude etc are at quickly throwing together some small visualisations in Python or JavaScript. But they struggled a lot with Bird-style literate Haskell. (And just that specific style. Plain Haskell code was much less of a problem.)

Because there are plenty of devs who take the output, actually read if it makes sense, do a code review, iterate back and forth with it a few times, and then finally check in the result. It's just a tool. Shitty devs will make shitty code regardless of the tool. And good devs are insanely productive with good tools. In your example what's the difference with that dev just copy/pasting from StackOverflow?

In my experience the lack of correctness and accuracy (I have seen a lot of calls to hallucinated apis), is made up from the "eagerness" to fill out boilerplate.

It's indeed like having a super junior, drunk intern working for you if we are using the gps analogy.

Some work is done but you have to go over it and fix a bunch of things.

You are. Only noobs do this, experts using a llm are way more efficient. (Unless you work like with the same language and libraries for years)

Yes and this means it doesn't replace anyone or make someone who isn't able to code able to code. It just means it's a tool for people who already know how to code.

I'm only 33 and I've worked with at least two of 'em. They're a type :-D

I thought it was nicely poetic.

"You're holding it wrong" doesn't make a small, too light, crooked, and backwards hammer any better.

I stopped using AI for code a little over a year ago and at that point I'd used Copilot for 8-12 months. I tried Cursor out a couple of weeks ago for very small autocomplete snippets and it was about the same or slightly worse than Copilot, in my opinion.

The integration with the editor was neat but the quality of the suggestions were no different than what I'd had with Copilot much earlier, and the pathological cases where it just spun off into some useless corner of its behavior (recommending code that was already in the very same file, recommending code that didn't make any sense, etc.) seemed to happen more than with Copilot.

This was a ridiculously simple project for it to work on, to be clear, just a parser for a language I started working on, and the general structure was already there for it to work with when I started trying Cursor out. From prior experience I know the base is pretty easy to work with for people who aren't even familiar with it (or even parsing in general), so I think given the difficulties that Cursor had even putting together pretty basic things it might be that a user of Cursor would see minimal gains in velocity and end up having less understanding in the medium to long term, at least in this particular case.

> It is already being used A LOT

Which is an argument for quality why? Bad coders are not going to produce better code that way. Just more with less effort.

Copilot isn't a single model. Copilot is merely a brand and uses openAI and anthropics newest models.

>> If the LLM spits out junk you should be able to tell.

Reading existing code and ensuring correctness is way harder than writing it yourself. How would someone who can't do it in the first place tell if it was incorrect?

> you are not being lousy you still need to think about all the edge cases

This is honestly where I believe LLMs can really shine. I think we like to believe the problems we are solving are unique, but I strongly believe most of us are solving problems that have already been solved. What I've found is, if you provide the LLM with enough information, it will surface edge cases that you haven't thought of and implement logic in your code that you haven't thought of.

I'm currently using LLMs to build my file drag and drop component for my chat app. You can view the problem and solution statement at https://beta.gitsense.com/?chat=da8fcd73-6b99-43d6-8ec0-b1ce...

By chatting with the LLM, I created four user stories that I never thought of to improve user experience and security. I don't necessarily think it is about knowing the edge cases, but rather it is about knowing how to describe the problem and your solution. If you can do that, LLMs can really help you surface edge cases and help you write logic.

Obviously what I am working on, is really not novel, but I think a lot of the stuff we are doing isn't that novel, if we can properly break it down.

So for interviews that allow LLMs, I would honestly spend 5 minutes chatting with it to create a problem and solution statement. I'm sure if you can properly articulate the problem, the LLM can help you devise a solution and a plan.

We usually just ask them to share their background, like the typical background exchange handshake at the beginning of any external call.

That normally prompts some follow ups about specific work, specific projects, if they know so-and-so moot at their old company. I call it behavioral because I don’t have another word but it’s not brainteasers and etc like consulting/finance interviews.

We usually get laughs, some quick jokes, etc., some really involved candidates will ask if it’s worded that way to prevent using ChatGPT.

No one’s found it offensive, the prompt is mostly neutral just very “dangerous activity” coded.

Unfortunately, we've noticed that candidates are on another call and their screen is fed by someone else using chatGPT and pasting the responses, as they can hear both the interviewer and the candidate

Yeah pretty much, they either go silent for 2-3 minutes or leave the call and claim their internet has cut out and need to reschedule.

Just one time someone got mad and yelled at the interviewer about nothing specific, just stuff like I’m not who you are looking for, you will never find anybody to hire.

Yea but I also suck in 95% of FAANG like interviews since I'm very bad at leetcode medium/hard type of questions. It's just something that I never practiced. It's very tempting at this point to trow in my towel and just use some aid. No one cares about my intense career and the millions I helped my clients earn, all that matters (and sometimes directly affects comp rate) is how I do on the "coding task".

Well, cheaters only cheat because they suck and they know it. Otherwise cheat would not be a rational approach.

Yeah, we found this when we started doing take-home exams: it turns out that a junior dev who spends twice as much time on the problem than what we asked them to doesn’t put out senior-level code - we could read the skill level in the code almost instantly. Same thing with cheating like that - it turns out knowing the answer isn’t the same thing as having experience, and it’s pretty obvious pretty quickly which one you’re dealing with.

I dunno why there is always the assumption in these threads that leetcode is being used. My company has never used leetcode-style questions, and likely never will.

I work in security, and our questions are pretty basic stuff. "What is cross-site scripting, and how would you protect against it?", "You're tasked with parsing a log file to return the IP addresses that appear at least 10 times, how would you approach this?" Stuff like that. And then a follow-up or two customized to the candidate's response.

I really don't know how we could possibly make it easier for candidates to pass these interviews. We aren't trying to trick people, or weed people out. We're trying to find people that have the foundational experience required to do the job they're being hired for. Even when people do answer them incorrectly, we try to help them out and give them guidance, because it's really about trying to evaluate how a person thinks rather than making sure they get the right answer.

I mean hell, it's not like I'm spending hours interviewing people because I get my rocks off by asking people lame questions or rejecting people; I want to hire people! I will go out of my way to advocate for hiring someone that's honest and upfront about being incorrect or not knowing an answer, but wants to think through it with me.

But cheating? That's a show stopper. If you've been asked to not use ChatGPT, but you use it anyway, you're not getting the benefit of the doubt. You're getting rejected and blacklisted.

The employer sets the terms of the interview. If you don’t like them, don’t apply.

What you’re suggesting here isn’t any different than submitting a fraudulent resume because you disagree with the required qualifications.

I wouldn't call it cheating but most of the time it's just stupid. For majority of software developer jobs would be more suitable to discuss the solution of the more complex problem tham randomly stress out people just because you think you should.

> It is patently unfair to the individuals that are smart enough to do your work, but poor at some farcical representation of the work. That is cheating.

On the other hand, if you have 1,000 candidates, and you only need 1, why not do it if the top candidate selected by this method can do well on the test and your work?

It’s unfair but it meets their objective of finding a high in candidate. Google admits they do this.

The companies that do this only do it because they can. They have to have hundreds of people applying. The companies that don’t do this basically don’t have many people applying.

If you’re spending the time applying and submitting something then you might as well spend the extra 30 minutes or so to do it right, no?

this is very strange statement. in what world did AI possibly shift power to the applicant?? applicants have almost never been in shittier position than they are now and things are getting much, much worse by the day

How so? Tons of companies are moving to AI automated intake systems because they're getting flooded with low-quality AI generated resumes. Of course, the original online applications systems were terrible already which is what encouraged people towards low effort in their applications so it's become a stale-mate.

Did it? What I see instead is total mistrust of the open resume pool, because the percentage of outright lies, from resume to behavioral to everything else is just that high. So I see companies raise their hands and going back to maximum prioritization of in-network candidates, where we have someone vouching that the candidate is not a total waste of everyone's time.

The one who loses all power is the new junior straight out of school, which used to already be difficult to distinguish from many other candidates with similar resumes: Now they compete with thousands upon thousands of total fakes which claim more experience anyway.

> They’re about trying to find out if you’ll be a good hire, which notably includes whether you’re willing and interested in spending effort learning

I admire this worldview, and wish for it to be true, but I can't help but see it in conflict with much of what floats around these parts.

There's a recent thread on Aider where the authors' proudly proclaim that ~80% of code is written by Aider itself.

I've no idea what to make of the general state of the programming profession at all at the moment, but I can't help but feel learning various programming trivia has a lower return on investment than ever.

I get learning the business and domain and etc, but it seems like we're in a fast race to the bottom where the focus is on making programmers' skills as redundant as possible as soon as possible.

> Interviews aren’t about solving problems.

Eh, I wish more people felt that way, I have failed so many interviews because I haven't solved the coding problem in time.

The feedback has always been something along the lines of "great at communicating your thoughts, discussing trade-offs, having a good back and forth" but "yeah, ultimately really wanted to see if you could pass all the unit tests."

Even in interview panels I've personally been a part of, one of the things we evaluate (heavily) is whether the candidate solved the problem.

Isnt one of the ways of solving the problem using all the tools at your disposal? If at the end of the day, isnt having working code the fundamental goal? I guess you could argue that the code needs to be efficient, stable, and secure. But if you could use "AI" to get part way there, then use smarts to finish it off. Isnt that reasonable? (Devils advocate) The other big question is the legality of using code from an AI in a final commercial product.

Yeah everyone says that they are interested in how you got there but this isn’t true in reality from my experience. Your bias inevitably judges them on the solution because you have many other candidates who got the correct solution.

Knowledge and skill are two different things. Sometimes interviewers test that you know how to do something, when in practice it's irrelevant if you A) know how to retrieve that knowledge and B) know when to retrieve it.

Yep, if I’m forced to talk through the problem, I’ll force myself to go through various things that you might want to hear, that I wouldn’t do.

Whereas my natural approach would be to take a long shower, workout etc and let my brain wander a bit before digging into it. But that wouldn’t fly during an interview..

Ironically this is exactly how I am too. Even at work, if I'm talking through a problem on a presentation or with my boss, I'm much more scatterbrained, and I'll try to dodge those kinds of calls with "Just give me 30 minutes and I'll figure it out." which always goes better for me.

That said, now we're just talking about take home challenges for interviews and you always hear complaints about those too. And shorter, async timed challenges (something like "Here's a few hours to solve this problem, I'll check back in later") are now going to be way more difficult to judge since AI is now ubiquitous.

So I really don't think there's any perfect methodology out there right now. The best I can come up with is to get the candidate in front of you and talk through problems with them. The best barometer I found so far was to set up a small collection of files making up a tiny app and then have candidates debug it with me.

I need my default mode network to produce good code, and I don't talk while it's active

The interview works as intended because the main priority is to avoid hiring people who will be a negative for the company. Discarding a small number of good candidates is an acceptable tradeoff.

What do you do if a junior asks for help and it's easiest to code through with them?

Some part of the problem statement you want help with (rather than a complete answer)?

One example would be looking up syntax and common functions. In a high-pressure situation it's much tougher to bumble around Google and Stack Overflow, so this would be a way for solving for "I totally know how to do this thing but it's just not coming to mind at this moment" which is fair. Usually we the interviews can obviously just tell them ourselves though, but that's what I was going for.

But yeah, the point is that once I applied it in practice it did quickly become confusing, so now I know from experience not to use it.

I think the other suggestions in this thread about how to use it are good ones, but they would present their own meta challenges for an interview too. Just about finding whatever balance works for you I guess.

Just another interview methodology pulled out of someone's ass. They don't know.

Yup, we told them exactly that.

See my answer to the other comment on this question. We figured there were some good use cases for AI in an interview that weren't just copy/pasting code, it's not about guessing intentions. It seemed most helpful to potentially unstick candidates from specific parts of the problem if they were drawing a blank under pressure, basically just an easier "You can look it up on Google" in a way that would burn less time for them. However we quickly found it was just easier for us to unstick them ourselves.

> If AI is an issue for you then just ban it.

Yes, that was the conclusion I just said we rapidly came to.

That's pretty good because it can exhaust the context window quickly and then it starts spiraling out of control, which would require the candidate to act.

Maybe you could allow using AI, but only through the interviewer-provided interface. That interface would allow using any model the candidate likes, but before sending the response it will inject errors into the code (either randomly or through another AI prompt).

Exactly. You never know. Some interviewers will penalize you for not having something memorized and having to look it up, some will penalize you for guessing, some will penalize you for simply not knowing and asking for help. Some interviewers will penalize you for coming up with something quick and dirty and then refining it, some will penalize you for jumping right to the final product. There's no consistency.

I do what I can to allay that fear. The rest is up to them.

My suggestion was in an ideal world which sadly this isn't. Your issue suggests they aren't tailored for each application, which could potentially be a reason. It is better to show why one project makes you a great fit as opposed to how many projects you have done. Sometimes the person in charge of hiring may not fully have all the expertise in the area they are hiring for.

Iroincally I'd probably have more github projects if I didn't spend 20 months looking for a full-time job.

And tbh, at the senior level they rarely care about personal projects. I must have had 60+ interviews and I feel a lack of a github cost me maybe 2 positions. When you job is getting a job, you rarely have the time for passion.I'm doing contract work in the meantime; prevents gaps from showing, more appealing than a personal project, and I can talk about that to the extent of my NDA (plenty of tech to talk about without revealing the project)

Brilliantly put! Upvoted and "favorited".

I would also add meticulous attention to documenting requirements and decisions taken along the development process, especially where compromises were made. All the "why's", so to speak.

But yes, commercial development, capital-A "Agile" absolutely kills the drive.

>I am energetic and love to go for the throat of the problems on my first day

The long term goal should be that you should NOT be energetic, yet be able to pretend that you are. We'll see where you are at the 33 year mark :)

> If you have an effective and well designed open ended interview that's more collaborative, you get a lot more signal to filter the wheat from the chaff.

I understood their point but my point is a direct opposition to theirs, that at some point with AI advances this will essentially become impossible. You can make it as open ended as you want but if AI continues to improve, the human interviewee can simply act as a ventriloquist dummy for the AI and get the job. Stated another way, what kind of "effective and well designed open ended interview" can you make that would not succumb to this problem?

And what is wrong with being a cog? Not everyone is going to invent the next ai innovation and not everyone is cut out to build the next hot programming language.

Bugs need to be fixed. Features need to be implemented. If it weren't for cogs, you'd have people just throwing new projects over the fence and dropped 6 months after release. Don't want to be another cog? Join a startup. Plenty of those hiring. The reality is that when you work at a large company, you're one of 50,000 people. By definition, only 1% are in the top 1%.

Someone has to wash the dishes and clear the tables. Let's stop looking down at jobs just because it's not hot and sexy. People who show up and provide value is great and should be appreciated.

>But what is in your opinion a better signal for junior or new grads?

They are juniors, I don't expect them to be experts, I expect eagerness and passion. They spent 4 or more years focusing on schooling, show me the results of your projects. Let them talk and see how well they understand what they did. Side projects are even better to stand out.

And you know... apparently people can still fail fizzbuzz in 2025. If you really question their ability to code, ask the basics, not if they can write a Sudoku verifier on the spot. If you aren't a sudoku game studio I don't see the application outside of "can they work with arrays?"

>I don’t know about you, but most interviewers out there don’t have the ability to judge the technical merit of a bullshitters’s contribution to a class or internship project in half an hour, specially if it’s in a domain interviewer has no familiarity with.

everyone has a different style. Personally I care a lot less about programming proficiency and a lot more about technical communication. If they only wrote 10 lines of code for a group project but can explain every aspect of the project as if they written it themselves, what am I really missing? The odds of that sort of technical reaspning being accompanied by poor coding is a lot rarer than the alternative of a Leetcode wizard who can't grasp architectural concept nor adjust to software tooling, in my experiences.

>But what is in your opinion a better signal for junior or new grads?

For students specifically, the strongest signal is if they've done research with a past collaborator of mine and my collaborator vouches for them. It's a great signal because it's very high barrier to entry and absolutely does not scale.

Realistically, being able to speak confidently about something they did/built during their education is a decent proxy. If they can handle open-ended follow-up questions like "what did you learn?" and "what trade-offs did you make?" and "how would you tweak it under X different requirements?" then that's a great signal too.

These aren't "gotcha" questions, but they insist on the candidate being reasonably competent and (most importantly) an actual human who can think on their feet.

>> It is not possible to perform an interview in ~4 hours such that someone sufficiently engages in what the job “actually entails”.

>> ... leetcode interview are an imperfect but relatively decent proxy.

I think all this is just the status quo that should be challenged instead of being justified.

When I conduct interviews (environment: a FAANG company), I focus on (a) fundamental understanding and (b) practical problems. None of the coding problems I pose are more than O[N] in complexity. Yet, my hiring decisions have never gone wrong.

I dunno... estimating how many golf balls fit in a bus or explaining why manhole cover are round make leetcode look almost... useful by comparison.

A filter could probably do it already. There are already filters to make you appear to be looking at the camera no matter where your eyes are pointing.

That’s an interesting idea. Sadly I think the next AI interviewing tool to be developed in response would make you look like your eyes are closed. But in the interim period it could be an interesting way to interview. Doesn’t really help for technical interviews where they kinda need to have their eyes open, but for pre-screens maybe…

> For somebody who knows their stuff it'll have zero impact

I just tried and it's: hard. It feels like being ask to keep one's breath like writing something.

I need to focus too much on keeping my eyes closed, I don't have enough bandwith left to thing about anything relevant.

I would say as long as it is stated you can complete the coding exercise using any tool available it is fine. I do agree, no task should be a trick.

I am personally of the view you should be able to use search engines, AI, anything you want, as the task should be representative of doing the task in person. The key focus has to be the programmer's knowledge and why they did what they did.

Well, the challenge involves using a python LLM framework to build a simple RAG system for recipes.

It's not a hidden requirement per se to use LLM assistance, but the candidate should have a good answer ready why they didn't use an LLM to solve the challenge.

So you allow yourself to use AI in order to save time, but we have to put up with the shit[1] companies make up? That's good, it's for the best if I don't work for a company that thinks so lowly of its potential candidates.

[1]: Including but not limited to: having to manually fill a web form because the system couldn't correctly parse a CV; take-home coding challenges; studying for LeetCode interviews; sending a perfectly worded, boot-licking cover letter.

They put their phone number there because they want you to call it. I say "I saw this position <position name> advertised on LinkedIn and I'm interested, is this still available?"

Last time I did this they told me it is but that they are at late stages of interviewing so I shouldn't bother applying for that one, but they got down my details and had other jobs that matched what I was looking for. Recruiters are sales people and you just reversed cold called them making their job easier. The majority of applications are AI bots and people who don't live in the country the job is listed in. By making a phone call you are up the top of the list of "most likely to be a legitimate applicant".

Projects are personal projects, or at least projects in which you did a distinguishable effort.

They don't have to be public to the whole world, you can have links that are only in your resume.

But if they're on GitHub, they have to be public, since there aren't unlisted repositories.

I'm saying the sections of the resume don't matter at all. The resume is basically ignored. You either have public code you can point to on Github or you aren't ever hearing from us.

IP secrecy isn't a moat in the age of AI. Open Source is the only way.