Programming interviews turn normal people into a-holes
new.pythonforengineers.com
new.pythonforengineers.com
1. What do you do for fun when not at work? … dig into to questions from here. 2. What is the coolest thing you ever built? How did it work? How long did it take to build? What language? What architecture / framework? What was hard about it? … you get the idea. 3. What are your biggest pet peeves when it comes to reading other peoples code?
Question #1 breaks the ice and gives permission to the candidate to be themselves. Look for common ground. Connect with them. Learn who they are as a person.
Question #2 gets you to see their passion. Talk to them on their ground. Give them the benefit of the doubt. Ask them hard questions, but don’t intimidate. Just go deep. The candidate cannot fake this. It’s not possible. People without the experience they claim are painfully obvious here.
Question #3 gives you two things. 1. Is this person openly critical of things looking to improve them? And Is this person a jerk? I call this the Jerk Trap. Jerks jump right in to being Jerks. After all you just kind of game them permission here! — I would ask though you be careful about excluding neurodiverse people who may not be able to control tone or navigate social situations well. These people will tend to be direct. Don’t confuse directness with being a Jerk. They are not the same thing.
I’ve interviewed a lot of engineers in my career, and tried a lot of things. This methodology has yet to fail me.
EDIT: It’s sad I even have to point this out, but in #1 you are looking to connect with the person on a human level. It’s not bait them into talking about coding outside of work. If you do that or think that way you are being discriminatory towards people who can’t code outside of work… you know like single mothers. And people wonder why we don’t have more women in tech. Stop equating passion with > 40 hours a week. It’s bullshit. Stop.
In my entire career the single most talented Programmer I ever knew was a single mother who logged off the computer every day after 8 hours period, and choose to spent her life with her kids.
I'm sure that mother would give amazing answers to the other parts of this interview.
But if that is their answer, it’s also a gateway to a more natural and relaxed conversation about the tech they care about and what makes them tick.
I’ll often learn far more about a person that way than the typical “tell me about a project/time when…” style questions.
Maybe it would be more appropriate to word it like that? Maybe not?
I feel it's hard to fake convincing answers to these kind of "getting things done in the real world" questions.
Like if i was to answer that honestly, it was fixing an obscure i18n bug for an underserved language group. I felt it was cool because it was such a small amount of work but made some people inordinately happy. In many ways i am much more proud of this 20 min bug fix than all the big technical projects i've done. But if you asked me any technical questions about it, the answer would almost entirely be - i used the architecture that already existed, because i was fixing a bug not rewriting the code base.
Fixing a bug isn't the same as building something, though.
The point is to see if the experience you claim matches what you have actually done.
I work for a finance company. The vast majority of the devs, including seniors, haven't released any software outside of work. Maybe 10% have. It seems this is true for other non-tech industries too.
Even on here, do you think more than 50% have released something they made by themself, that is more advanced than a simple Android app? Obviously there's a lot of talent here. I would be surprised if the number is higher than that.
If you’re been working 5-10 years or more and you’ve never built anything at all that you’re excited about, that’s a red flag.
Made me think the other questions are follow-ups to these.
Eh, when you work on large systems in a large and highly regulated company, it's not very exciting. There have been some interesting components to those systems, but in general they have been mundane business topics with tight guiderails and little freedom. I mean, the majority of people in the world don't get "excited" about work - it's just the means of survival.
You're virtually guaranteed to not be terrible given this self-evaluation. You might not be some senior-level elite developer, but I'm not sure I've ever met someone who said this who was truly awful.
They can do this because their prestige ensures a near limitless supply of candidates willing to jump through those hoops.
At it's best we tended to reject too many great candidates because our rubrics were so rigid, and it didn't let us make room for folks that were clearly amazing but didn't answer the questions in just the right way. Seriously, the talent we passed over was truly world class.
There's a lot to be said for all of the non-verbal and subtle information that's conveyed in an interview. I think that throwing that all away is foolish because you're not really doing much better at removing the bias anyway.
Wouldn't it make more sense to consider the fastest growing companies, or perhaps the subset of fast growing companies with the most profit per employee?
From a human side, I would hire someone who decides to take care of their kid after hours instead of honing their technical skills. They tend to be a lot more responsible with their work too.
Let the candidate lead the conversation. People love being listened to. Where they take it is way more revealing about them than any fixed interview grid. And they leave the interview with a smile because all they had to do is be themselves.
I don't see how one could be sued for discrimination based on information that people reveal of their own will.
Like if someone says their goal in life is to make the best tasting sourdough, ask them how they go about doing that. Researching new recipes? Starting with a base recipe they like and making small tweaks? Optimizing for their own taste preferences vs the tastes of the people they share it with? Etc.
Even if their hobby isn't collecting Github stars, you can still learn a bit about their mindset. Plus I've found that getting someone to talk about something they're passionate about for 5 minutes is a good icebreaker to start an interview.
Sorry but I think it's a bad question. What if the answer is "Oh I don't have much spare time these days, I make dinner for our toddler son and put him to bed. My lesbian partner can't help much because she's expecting in a month." It's a trap leading to unwanted information - many of which would be downright illegal if factored into hiring decisions.
There's a reason why all the big companies emphasize never to ask anything about nationality, ethnicity, marital status, religion, blah blah. You don't need to know, you don't want to know.
Oh, congratulations!!! Do you know the sex of the baby yet? What an exciting time, I bet you have lots of preparation going on. I also have a child and (blah blah bit of history)
So we ask this question to get a bit of an idea about the candidates hobbies which tells us about them as a person, - are you outdoorsy or indoorsy? Are you a movie buff or a reader, or a rock climber or a painter or a poet? Or something even more interesting?! before you were so busy, how would you spend your non-work time?
That way:
Puts them at ease, shows you have empathy for their situation, find common ground, explain the reasoning for the question, gently nudge the conversation towards what we were looking for.
It’s not rocket science people it’s just conversation skills.
What the hell man, are you speedrunning the ability to get sued / posterized on Twitter?
I know engineers love open, discussion-y interviews and senior interviewers like giving them, but the evidence just doesn't bare it out. "Work sample tests" and "Structured Interviews" are the most predictive of on-the-job success from the published research I've seen. No matter how much I'd prefer to have a freewheeling conversation as you describe, I have to bow to the evidence.
I've been to work for companies that say anything you build while employed at company belongs to them unless you go through the proper channels and layers of red tape to discuss the projects with them to ensure that anything you are working on does not involve any company IP. This could sound like baiting for a different direction than the other comments are alluding.
I think the idea of the question is sound, but it's sufficient to ask "what drives you?" and dig in there.
In contrast, the places that have done tech interviews have generally been awful to work at. Less intelligent people, less interesting work, worse management, etc.
My time outside of work and what I do for fun isn’t your concern, and I don’t want to share those details with you.
Personally I never had a problem with it and from the interviewer point of view it helps lighten the atmosphere a bit talking about out of work stuff.
Maybe your first question might work to get more at that idea.
1) When the person who wrote the code is no longer available to talk to. Having even a 5-10 minute chat can massively speed up my comprehension of someone else's code and save a lot of time.
2) Unused code that hasn't been deleted. I think everyone should strive to clean up their codebases. I'm not exactly blame-free here either so it's something I try to apply more and more as the codebases I work on start staying around for longer.
Actually, I loved it. You might not be able to imagine this, but I actually like lawyers, as a rule.
Since Google insists on giving candidates a problem, I took a patent from a previous job that I was familiar with, and said, "OK, we're going to pretend I'm the inventor, and I'm going to describe this invention to you. Your job will be to write the first claim."
This is pretty similar to their actual job, at least on the patent prosecution side. They have to come up to speed on an unfamiliar technology quickly? Well, that's what patent lawyers do. Most of them did pretty well on the test, too. It was way fun.
Unlike in a SWE interview, I never heard anything after I gave my feedback (with a SWE, you would see what the other interviewers said). The only way I even heard if they were hired was to check a few months later. I didn't know if Legal even paid attention to me.
Years later, I joined Legal and found out they'd been hanging on my every word.
Of course you shouldn't humiliate the candidate, that's never the right thing to do. But there's a huge gap between maintaining a high hiring standard and believing that "everyone else looking for a job is an idiot, and our job is to expose them, to teach them a lesson, to humiliate them till they quit." The bulk of the advice in this article is fine, but the hyperbole is just plain annoying.
Also, seeing people site the no asshole rule is a warning sign for me. I worked at a place that constantly mentioned that, and let's just say it was clearly ineffective. Assholes rarely think that they are the asshole and are perfectly comfortable citing that principle.
Once you do enough interviews, you realize this isn't a myth. Okay, maybe most is too strong of a qualifier. But the reality is that a title of Senior Software Engineer doesn't imply the ability to translate human problems into machine-executable code in a structured way. It's very possible that a "Senior Software Engineer" has been working at a small consultancy on the same project for 5+ years, has few if any technical teammates, and spends most of their time copy and pasting StackOverflow answers and doing "guess and check" programming to do bug fixes for a legacy VB6 or FoxPro app. I'd know, as I've worked with those people.
That being said...
> The interviewer asked me a very basic question– something small like how to create a table(or something silly like that).
If you're asking syntax questions in an interview, you've already lost. For technical interviews, the thought process is far more important than the end result. Again, programming is the act of turning human problems into machine code in a structured, repeatable way. Pseudocode is sufficient for this. Forget whether you should be using `sort` or `sorted` in python? Me too, so just tell me what you expect the sort method to do and move on.
So yes, asking for the SQL create table syntax in an interview is absurd and the author is right to complain here.
> Actually talk about their fucking resume... You can easily filter out people who just coasted along vs those who accomplished something.
Sorry, but you cannot. Some people are excellent at bullshitting and making themselves sound like incredible workers, especially if they've had time to prepare. You'll hear amazing stories of late nights and heroic effort, but they were often done by other people and merely observed by the interviewee, or just fabrications.
All the most advanced computer science research areas right now basically come down to guess and check. E.g. AI, ML, NLP, etc. The folks behind spaCy have a good talk somewhere explaining that this is the reason why there isn't more academic funding things like NER, despite the fact that it's an insanely valuable problem.
But regardless, the best programmers you know probably spend most of their week doing guess and check.
The best programmers I know do not do this.
despite the fact that the specific problem has been memed to death, i can still reliably wash out 70% or so of the interview cohort i’ve interviewed by fizzbuzzing.
it’s shocking every time.
They have a strong tendency to rely on hardcoding, sometimes pasting one loop 5x instead of just adding an outer loop.
It's absolutely wild.
I also agree that some of them panic from the induced stress of interviewing. I try to keep my interviews very cordial, I've been there before, too, so I'm sympathetic, and I also suffer from horrible imposter syndrome, because I am a CS college dropout, despite the fact that I've had a wonderful career with dozens of major victories over the last 16+ years. I really do get it. Despite that people who cannot program find their way in front of me, interviewing for Senior+ roles.
A recent example is a Senior Software Engineer new hire (I did not interview this person) who was tasked with moving a git repository to a new upstream as part of a larger migration in the engineering org. This person proceeded to try write a sprawling bash script to handle the process in order to "preserve history."
Clearly this individual doesn't understand git at all. The script wasn't even doing anything. Their other tasks, which were application development tasks, demonstrated code that was also somewhere around an intern/associate level.
I left that role very shortly after because when I brought this to my management team it was made clear to me that what we needed was warm bodies. That person is still employed by my former employer, over 9 months later, making a 6-figure salary with an annual performance bonus and stock grants.
I think I must always take "can't program" a bit too literally, because it sounds like this person very clearly can program but doesn't understand git. I have worked with enough senior/staff engineers from exotic computing environments (mainframes, academic/scientific computing) that the idea of a senior engineer who doesn't know git is not surprising, but I would have expected such a person to ask for guidance/help. I found myself in similar situations when I joined MSFT despite having only used Linux/OS X for over a decade.
I guess maybe I would suggest that you phrase your assessment of someone like that as, "this person is unfamiliar with a standard tool and does not produce work that meets my code quality bar" instead of "this person can't program," as the implies that they got and have kept their current job through deceit and/or outright fraud, and were caught attempting to defraud you.
I had one candidate take the entire first half of the interview to solve it, and I guided him very strongly the entire time. By the time he was half way through, he had so much sweat pouring from his face he looked like he was running a marathon. It was very awkward and uncomfortable for me.
Like fishtoaster’s #3 above, these candidates came through recruiters where we specified the technologies we wanted.
1. A couple years out of college, I went back to my alma matter to recruit interns. I stood at a booth at a job fair and chatted with people. Anyone who seemed interesting I invited for a 30-minute interview the next day (9 people). The next day I had all 9 people do fizzbuzz on paper (I know, I know, I was young!) - every single one passed easily and it filtered out no one.
2. More recently, I was recruiting off of workatastartup.com for senior devs. I went through a few dozen first-round interviews and didn't once come across someone who couldn't code.
3. More recently still, I was working with some recruiters who would send resumes my way. I was looking for a specific combo of two common techs and I started out giving a first-round interview to anyone who listed any experience with both. I found that something like 60-80% of these candidates would *not* have, (in my opinion), been able to code fizzbuzz.
It was interesting because, until #3, I'd never really believed the "most people cannot program" thing - at least not after my experience with #1. The lesson I took was that it totally depends on your pipeline. If you put a job listing on Indeed.com or whatever, you'll get a lot of people who cannot program. If you use other channels or do any other form of screening (implicit or not), you may get almost none.
And I would roughly say 70% are stunned because they don't know what to do. The remaining 30% are shocked by how ridiculously trivial the question is.
My approach is to try and make the candidate feel relaxed, as I want them to show their best self in an already stressful situation. Following this it's about giving them the opportunity to demonstrate their skills.
If you go into an interview with a combative mindset of "filtering out the lemons" and then complain how hard it is to hire good people, you really ought to take a long hard look in the mirror.
1. Both parties hope it's a match but of course worry about making the wrong choice. Think: the interview wants me to do well, I need to help them say yes to me.
2. Programming ability is a necessary but not sufficient skill for a real programming job. How you are on call, how you are with brainstorming, how you are hashing through requirements, how you are when you make a mistake, how you are when you are being coached - all matter and the programming interview is generally structured to get signal on those things.
I think most people who make themselves crazy / hate interviews / are befuddled - it's because they don't see this.
Look it's definitely an interview and you're being evaluated but good interviewers help you a lot - eg hint when you're over or under thinking something, ask about edge cases you neglected, etc. If you think of the interview as adversarial you probably miss all of that. .
// coding puzzles for fun, but not while being watched and judged and a clock is ticking.
Have you ever troubleshooted a production issue with millions of dollars at stake every few minutes of down time? Lots of eyes on you and time pressure.
Like I said, the interview gives signal.
Remember, nobody is at their best in there situations. The interviewers aren't expecting perfection, they are expecting reasonable performance given the situation. They are usually calibrated on dozens or hundreds of other interviews.
I have done high stakes production troubleshooting many times. It’s not remotely the same as an interview—not even in the same ballpark. Everyone of those eyes wants you to succeed and will help you in any way they can. And if they aren’t being helpful, I politely tell them I’ll solve it faster if I can focus without people looking over my shoulder.
The fake adversarial system created by coding interviews is why I prefer pair programming with a candidate on a novel problem.
Do they? I've come across many interview loops where I felt I was being put through the gauntlet to prove that I am unworthy.
It was horrible. Never want to be the reason someone didn't get a job again lol.
The bit at the end about trying to discover what candidates are good at and see them actually working... I'm shocked that so few interviews actually do that. I get that it's hard in tiny companies where you have one vaguely technical person who realises they're out of their depth and is hiring to fill that gap. Everyone else has no excuse for lousy evaluation of technical skills.
This means when they ask him for feedback he'll say "Oh he was okay. Not very technical"
To solve for this guy, you need to have some very good questions about technical problems the company may be facing and then you need to be able to have insights on how they might solve this.
You essentially have to structure the interview for them. Give them the questions and then you answer and then you have to impress.
The aim should always be to impress and be liked unless you have someone who is out to prove you wrong. With those types you need to show technical superiority in addition. These types are usually small in number though.
This is really big; we've been using the same basic "is this person a big phony" set of questions for a long time, and it immediately filters out people who just have no knowledge. Stuff like what is a Boolean variable, what is ssh, what is asymmetric encryption, name 3 hardware components of a server, what is a primary key, etc. I've seen people with resumes full of tech jobs that fail at all of these. And I don't mean slightly off, I mean no clue at all. We don't require a perfect score or anything, and recognize language barriers, but it becomes super clear super quickly when someone is just bullshitting.
I stopped bothering with questions before that point, I'd read their application, look at their resume, then get them in to play with a computer. The good news is that it actually found the people we needed, the bad news is we never found an effective way to pre-filter the ones who couldn't (and even a couple who said "I've never seen this before" when looking at the code!!)
Mostly, I think this is just the result of companies looking to satisfy mainly three competing tasks. One, how do we assess someone can code. Two, making a standardized interviewing approach that many different people can perform. Three, doing it all in a time/resource efficient manner. Obviously code reviews satisfies the first but present very serious reproducibility and time requirement issues. I posit that programming leetcode style questions is the solution that most companies think balances the three. It feels bad as the interviewee because it is a fairly specific skill of programming that you need to practice and you cannot opt for another method to better illustrate your ability.
That's true, but it is meant as a different filter when applied to a large number of candidates.
I went through a bunch of leetcode style interviews last year with some very odd interviewers - the oddest was a Sr Principal engineer asking me to manipulate linked lists with recursion.
And the comment he made after I wrote the code was that "We don't care if you write code at work, but we want to know you like writing code enough to not see it as beneath you to do. To make sure you're not some whiteboard architect, because everyone you are supposed to lead will be writing code."
I had been looking at the interview as a sort of idiot catcher before that point, but suddenly it seemed like a good filter for respecting the effort at the lowest level of the profession.
Google invented this interview style 2 decades ago basically as an intelligence test, and it's been the status quo ever since.
That's all there is to it.
However . .
When prospective associates are responding to these sorts of questions, it's possibly more informative to see how they handle questions that they don't know the answer to.
Native intelligence and initiative outweigh a set quantity of specialized knowledge; far more important to find out how a prospect thinks about the problem and how they respond to these situations under pressure.
Problem here is that the interviewers need to know their stuff, and, regretfully, that's not been the case for virtually any interview board I've assisted. All the participants were far, far too high above the levels where work happened, well into the vertiginous expanse of Aero/Def Management Brain Rot. Best I could do was wave my hands vigorously while silently mouthing the words HE DOESN'T KNOW WHAT WHITESPACE MEANS . . to no avail.
Thing is, I know it's not just my industry. It happens in the "normal" world too. Some guy makes a thingy with Framework X, leaves, and then it's practically impossible for management to find another random guy who knows Framework X in just the same way, because damned if management knows what the heck Framework X is.
People bs-ing in their cvs about their actual experience is one of the factors interview process has become like this.
However, a lot of them will have real problems when switching companies and being faced with a real technical interview as they are severely lacking in technical depth. Ask them about anything deeper than a manager's understanding of the topic and they will waffle on without answering the question. "What security measures did you take in your code?" - is a good question, followed up by a more specific "how did you prevent injection attacks when you did X?" (YMMV). Usually these candidates have no clue what that even is, compared to someone who actually had to deal with the nasty bits of the job the project hoppers can't be asked to deal with.
1. I admit I am nervous so much that I just couldn't tell my own name.
2. It's just strange for first look that I don't remember, but we create tables so rarely, that it's not a surprise.
3. Okay, let's try to figure out the command, my first hint is that it should be "new", "create" or something. Let's recall, how to deal other way, say, delete or modify tables: "drop table", "alter table" - so my best hint is "create table" or "new table". (Offensive notice: if you learnt SQL one day before the interview, this gonna not work.)
Great, go on, it's pretty sure it should contain the list of fields, define them: names, types, and some constraints, whether it can be empty etc. Maybe this command defines the indexes as well, then every index should declare one or more fields, ascending/descending marks per field. Oh, a table unique key is also can be specified, at the field specification. Finally I notice, that different SQL servers may have different syntax and even features, like choosing storage system for the table (MySQL: InnoDB etc.).
That's the _content_ of the SQL's create table command, withot any syntax. I think, it's clear, that I would have no problem with writing a table creating SQL statement.
If you can not solve the "I-forget-the-syntax" problem, probably (another offensive statement, sorry) you're not for this job. In real life, you will have even more stressful situations, and you have to solve them, or at least DO SOMETHING. What you've done was NOTHING.
Depending on what your needs are, you may need to do a technical interview. Do the same thing with the technical interview, figure out your needs then write your questions. Have a similar group of people doing the situational interviews do the technical interview, preferably the people the candidate is going to work with. Find a way to make it collaborative if you can. Seeing how a candidate works with other people is nearly as valuable as seeing how technically proficient a candidate is.
That's it.
I have no problem solving exercises in interviews as long as we're talking about one session of at most one hour. I was contacted by recruiters of companies that expected me to go through many rounds of interviews that would span many weeks. lol
I always reply that I'm already employed, that for me their company is just like any other company and that working for them is not a privilege, it's just a job.
Also, grug hit dot on keyboard and list of things grug can do pop up magic
Exackery. I seriously struggle when I'm using vim or nano on a remote box because they don't have autocomplete and I have to duckgo the syntax for bash. Bob help us all if I have to work in C++ like that with the 200 million variations on collection.add(). {eugh dunno}
We set up all these artificial handicaps and are then surprised people do badly in interviews. Just let them code using their own machine and IDE, and any other tool they need.
I wonder if you'll also scoff when people start asking for Copilot or GPT.
Myself I am guilty of freaking out a candidate because I had just rolled off a huge escalation, heart racing and firing on all cylinders. Nervous, talking fast, etc.
I will try some Gotcha type questions to use as shorthand for how deep they are in certain areas. Even if someone whiffs one of those I am still likely to recommend them if everything else was good. No biggie. If there is time I will explain the answer to see how they digest it.
I am not trying to be an asshole. But in comparison I know a guy who won't hire someone if he doesn't like their shoes. He's an asshole outside of interviews though.
Put yourself in an A players shoes. Your trivia on the spot question shows you value unimportant things. A players can see talent in small signals and can map out a candidates profile you are trying to filter candidates by nonsense that doesn't map to the job. That leads to random results.
Hiring is an important management responsibility that most developers should not be involved with unless they are part of the management track hopefully with some training
Absolutely, this is what it boils down to. After a certain point (like 15-20 engineers or so) you need someone in management to actually come up with an interview plan. Letting developers just wing interviews and ask trivia questions is a sign of an immature organization and is a big red flag for anyone senior coming in.
But the tech industry interview process is such low hanging fruit for mocking, I don't think this article is anything more than meme-ing a trendy topic for clicks.
If we really want to evolve into something better, then here's what I propose: All employers must release their laptop surveillance data to the public domain for all the see. That way we can objectively compare who writes the most LoC and logs the most onscreen hours.
As an interviewer, I prefer to give potential applicants a softball, like writing a function that computes the nth digit of PI in O(1).
print( math.pi )
me: [scans resume] ... "tell me about project y here"
interviewee: [tells me a bit]
me: [ask questions, listen, drill down, listen, get gently more and more technical, back off if I hit a soft spot and find another place to drill down]
repeat, repeat.
I find its a good way to determine the candidate's strengths - versus freaking them out with a gotcha that's irrelevant to their skillset.
I'd talk a bit more about power, generally, and what it does to people but this is good
Perhaps because I always interviewed for "full stack" jobs where the knowledge of tiny details this very moment is a lot less important than the ability to understand systems as a whole and how those little things fit together.
On the hiring end before it came to me being directly involved the candidate would already have gone through the basic "test" I and my colleagues prepared. It was a series of "question" "answer" sets starting with really simple and increasing in difficulty we gave to our manager. He would do the first part of the interview with a candidate and to fail, one would have to really have no clue. It was really surprising that 90% of candidates, with really good resumes we got sent by recruitment agencies failed that. It is important to stress those were not questions of the sort "implement some algorithm in pseudo language", but more like, "explain what is a microservice", "what is redis and when you would use it(assuming they have it in their cv)" etc. They were simple questions. I had similar questions on every single interview asked of me when I was a candidate (except the very first one when I was asked to fix an actual issue, but by then I was almost hired).
Then once they passed this initial step they would sit down with us(hopefully their future coworkers) and we would talk to them about their resume, ask what they worked at in previous jobs, what problems they resolved and how etc. This allowed me and my coworkers doing that part of the interview to very quickly get an idea if the person we're interviewing is on "our level" or not. Perhaps it was helpful that we interviewed people for both senior and junior positions so someone with less experience, but demonstrating ability/willingness to learn could still be a good match. At the end, if our manager was happy with what he heard he would ask us for our opinion. And I have to say, despite this easy-going interview method it took us over a year to find a good candidate for one senior role we were hiring for. During this year we had only 5 or 6 people progress to the second stage and we had a new stack of CVs to go through every 2 weeks or so. We did get 3 people for junior roles at the same time.
So is it true "most people interviewing have no clue"? I'll respond to this by saying it depends which recruiter has sent them. I have had recruiters admit to me they "tweak" CVs on more than one occasion. Also, yes, there are lots of people applying for jobs way above their skill level. Hiring is not easy. That's why good recruiters make more money than developers they recruit (I know a recruiter making £50k monthly in commission).