none the less i think a leader who could & who can understand the current sde II role & hack it if they had to is almost always a better more capable general.
that ability to empathize & share perspective helps, if not necessarily the ability to sling stuff together & get it shipped, day by day.
I don't know how many can't but Microsoft Azure's CTO is Mark Russinovich who was responsible for creating the sysinternal tools. He can most definitely hack.
But can he solve an obscure dynamic programming problem from the interviewer's PhD thesis in 20 minutes on the whiteboard, with a marker that's almost spent? That's a completely different skill than actual software engineering, that the companies (including Microsoft) continue to inexplicably screen for.
I recently interviewed with AWS. I still remember one of the questions. It boiled down to: please implement Aho-Corasick in 10 minutes on a virtual whiteboard.
Perhaps there are folks in programming competitions that can do that, but not moi.
It blows my mind how tricky some of the technical interviews I have been through, and even passed, and even been offered roles for, but this morning I spent thirty minutes failing to update the s3 tags on a bucket literally named 'example-bucket'.
I kind of wonder if there actually was a systematic study of some sort aimed at quantifying how much time people are wasting on unnecessarily manual wrangling of cloud infrastructure. I know I waste a lot of time on that, even though I try to automate everything I reasonably can, and I don't use three dozen different services. Unbelievably obtuse docs even for the simplest things, dozens of manual yak shaving steps which could be done by a shell script, nobody seems to give a slightest shit - people think that's how it ought to be.
I bought my own markers recently, just so I would never have to deal with "this marker is almost out, and this one is too light to be able to read, and this one...." bullshit.
i dont know mark or his story well, byt a quick review of systinternals & mark does make me question this situation in another way though. mark had enormous opportunity, just vast. 1994 phd. a year at numega, building winternals for a year. cofounding & chief archtiecting a sysinternals startup.
he can clearly hack. i think he still can. he seems to still be the chief blogger/vlogger on sysinternals, an uber-technical tool, serving as a chief information radiator for it; strong technics mixed with great demonstrated communication abilities: a great combo.
but still i can varry some doubt. would he have been a good MAANA employee, or other medium-sized tech company? ever? would he have been able to engage in that kind of product development, amid these product development lifecycles? staying good & sharp & beliving in oneself & what one is up to is a question of opportunity, alongside talent & capability. maybe he would have made a shit sde ii. which he probably does hire many smart sharp well trained candidates for.
Goes to show the value of a good post title. This one (we are commenting on) goes straight to the point and it follows it is more attention grabbing than the linked post.
It’s another example of the editorialization policy being unreasonably harsh and sometimes better ignored. Many actual article titles are absolutely unfit for submissions, especially with the rise of clickbait or endlessly long content-free sentences in large publications (“They said he couldn’t do X. But then he did Y. His neighbors weren’t impressed. His wife was stunned. What happened next will blow your mind. “) that even change sometimes.
Many of the most successful submissions have heavily editorialized titles, sometimes necessarily so - sometimes what’s to be pointed out is something completely different from the page’s title or the page doesn’t even really have one.
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
I think this should be more like “only editorialize when necessary”.
Amazon seems to be hurting for hires. Many people I know including myself who large tech companies normally would not go near got several Amazon recruiters reaching out during our last job hunts.
I spoke with an AWS recruiter last week for an infosec role and they were surprised I was not interested. Sent them links to the nytimes and other pieces showing it’s a grind house.
The comp premium is just not there imho for the hit to quality of life (at least for the roles I’d be eligible for).
I’m guessing it’s mostly bad press around work environments.
I personally didn’t bother going through because A) I wasn’t prepared and B) I was locked into a new lease and after some research the relocation benefits they offered wouldn’t be worth it. I believe at the time they weren’t overly flexible on work location.
I had an AWS manager reach out to me last year to discuss working some Rust related stuff (and they knew that my Rust experience was very limited even before reaching out to me). They decided after an interview or two not to go ahead with it because I wasn't willing to relocate.
Can't imagine why they might be hurting for hires...
We're seeing that lower in the food chain. We aren't even able to find people who can write a simple single function on the fly that compiles right. This isn't leet code, or big O, or anything.
Just make it function. I guess anyone who could was hired by AMZ.
Yet one common trick they pull on experienced hires is to force them into a lower "level". While low-balling is an industry-wide practice, they have clearly taken it to the next level (ahem) by abusing the equivalence relationship to the Google/Facebook ladder.
To begin with, the "Senior" level at Amazon is designated L6; while Google/Facebook designates their "Senior" level L5/E5. If you visit Levels.fyi [1] you can see this equivalence clearly laid out... except Amazon recruiters / hiring managers seem to really believe that only someone who roughly qualifies for Google L6 can qualify for Amazon L6. I find this delusional at best, because precisely as another comment here said, Amazon does NOT currently allocate enough compensation premium to justify this "high bar". Heck, from the PoV of an actually competent candidate, why would they pick Amazon over other offers, if it means they would have to take a "title hit" in return for... mediocre total comp, worse WLB, constant gaslighting, and low job security?
I do not understand how you can lowball or downlevel people at scale. Everyone I know interviews at multiple companies and then compares offers. Some offers are more competitive some are less - just pick the best one in term of level/comp/interest.
The only hard thing is frankly balancing salary vs interest. Do you want more money to work on increasing ad click rate by 0.1% or less money to design software for Mars mission.
> I do not understand how you can lowball or downlevel people at scale
A common tactics is to enforce YoE requirements aggressively --- basically the jokes along the lines of "10 YoE w/ k8s". These days they do it less blatantly (i.e. the specifics are not written in the JD) but the spirit remains.
> The only hard thing is frankly balancing salary vs interest
I can only say from my recent experience that this is a simplified model. Not saying this is wrong, but some circumstances call for analysis of other factors, such as those involving career path planning. Wouldn't go too deep here but the trick is a lowball'd and/or downlevel'd offer at BigTech/FAANG might actually remain desirable. This unfortunately reinforces their (predatory) behavior, but such is the force of the market after all...
We are all about junior people making a mistake, but, heaven forbid it's a recruiter and not an engineer (recruiting for an SDE II would be a junior recruiter). It's sort of a dick move for a CTO post that, since the "NN" still potentially identifies the recruiter. This recruiter will be at a minimum the subject of ridicule or worse, let go.
Recruiters have well, one job. A great recruiter actually takes time to research people and find good fits. They are incredibly rare, but worth their weight in gold IMO.
The vast majority of recruiters just do lazy keyword searches and spamming. He or she obviously didn't even bother to read the title or profile of who they were bothering. Spamming is more of a dick move than calling out spam, IMO.
What’s your point? A junior recruiter out to prove themselves will need to cut corners just like all the other recruiters do. Give them an opportunity to make mistakes, I guarantee you the great recruiters have made and learned from their fair share. Plus, if this is that bad of a mistake, the organization is partly responsible for not having safeguards in place to prevent it.
Well said. I was going to write something similar, but kept stopping because I felt I was implying we should seek to embarrass people.
We should absolutely call out mistakes, and it's good if people feel embarrassed for them. I have a few moments in my career where I felt so embarrassed I wanted to slink away and disappear. I'll never forget them, nor the lessons each taught.
Depends how you look at it. I'd consider writing bad code and or bugs more akin to misspellings and grammatical mistakes in this context.
This is more akin to being asked to write an auth api, but delivering a fizzbuzz function instead...in that I obviously didn't even read the problem/ask, but instead spammed code to keep the numbers up.
Secondly, every job is different in severity and scope. A surgeon making a mistake is not a fry cook making a mistake is not a civil engineer making a mistake is not a lawyer making a mistake. And public facing roles have different expectations and risks compared to the others. It's what you sign up for, I guess.
To be clear, I don't think this person should be fired or hunted down or anything. I just don't see a big issue bringing it to light with the information given. Amazon could identify them if they wanted to already. I doubt anyone outside could, given there's probably multiple NN recruiters working there.
maybe they had multiple windows open, scrolled too far, saw a previous job history? Or an automated script gone wrong?
Nobody is saying the recruiter did a good job here, when someone messes up code in Azure, you didn't see the CTO go "OMG my intern wrote the worst code! Let me post it on Twitter so everyone laughs".
This is a teachable moment -- not a shaming moment.
The CTO of Azure has no responsibility to an Amazon recruiter. While the recruiter could likely be identified if you searched hard enough, most people aren't crazy enough to care.
This is a teachable moment. Amazon shouldn't engage in these practices and should manage the people they employ so this doesn't happen.
If this was an innocent mistake, you shrug, cop a few jokes with your co-workers and deal with it. No one is going to sack you solely over an incident like this unless you've been going against a strict policy.
This has nothing to do with MSFT or AMZN. A good CTO is at any company provides an example of what to aspire to become. They are mentors and teachers to the technical community as a whole.
Amazon recruiters are just mass emailing people with mail merge. In the past few months I've gotten emails from probably 20 different Amazon recruiters. Some of them have read my profile, and others are just sending nearly the same pre-formatted text. This isn't someone making a mistake, it's just lack of effort.
I don't see the harm. Either this was following Amazon's standard practices or it wasn't. This SHOULD be the subject of ridicule! No one is saying hunt the guy down and dox him over it. If this is against Amazon's standard practices and they let the recruiter go its because of THAT not because some senior person decided to share it. You can't expect secrecy if your doing a cold approach.
This is exactly the kind of incident that helps bring recruiters back to reality. Getting dozens of cold approaches about roles that are obviously not a good fit if someone spent 5 minutes researching can be infuriating (or even knew what they were recruiting for).
Because the power imbalance between CTO of one of the biggest cloud platforms in the world, and a rank and file recruiter. It’s a bad look, to those of us that care. Punch up not down.
Probably was a win for Microsoft Azure and its CTO though, with all the viral mindshare
I think there would be less harm if the possibly identifying information about the recruiter was left out. Everyone in Amazon recruiting is going to be made aware of this now, and this individual is being called out. Usually performance coaching is done privately, but, now the entire org will know "NN" is this person and I'm sure it's embarrassing.
Making a mistake is fine, but you should also expect some good natured razzing when you make a bonehead move like this. Having said that, this happens all the time. I've gotten plenty of messages to apply for SDE-I & II roles while employed as a Director or CTO.
razzing from a lateral co-worker on your team is one thing. That's typically good natured (though I'm sure technically an HR Issue). Publicly called out from a CTO at your biggest rival, is not apples to oranges.
Ah recruiters. Several years ago I recall the story of one of the creators of a programming language who was asked how many years of experience they had with the language and the response "all of them" was perfect. I can't recall if this was Gosling/Java or Van Rossum/Python (or someone else entirely).
A similar and absurd story[1] I remember from last year:
"I saw a job post the other day. It required 4+ years of experience in FastAPI. I couldn't apply as I only have 1.5+ years of experience since I created that thing."
Eh, it happens. As a PhD student in robotics at CMU I got calls from an agressive recruiter for Uber ATG, asking if I was interested in being a test driver for their cars, a job which didn't really require any kind of degree and with pay fairly close to minimum wage, iirc. I politely declined, as I wasn't qualified - I don't have a valid US driver's license.
Not sure why this is offended, but I actually think he may have some chances failing the interview if he goes through. I do think he's definitely capable and knowledgeable of doing a principal/fellow engineer job.
I went through a few interviews myself recently and I got very puzzled with the interview process. It's quite brutal. And I just went through a 5 technical rounds after passing the first 2 rounds (1 technical and 1 behavioral) for a senior position. The 5 rounds include: architecture design, model/object algo design, refactoring/optimization, build a complete CRUD api with tests. I know how to build these things and I would take time to do it, but I couldn't do it with the very fast speed that I was limited to during the interview.
Even if we accept CS101-styled timed coding questions as a necessary evil to weed out the fakers, having recently been on the receiving end of some of the "system design" questions recently, I must say it's a really really bad idea to (1) having these subject to a tight time limit, and/or (2) treat this as if it's a standardized test.
The worst offenders (according to myself):
- Expected me to "design a xxxxx-ing system" (topic redacted but it's really broad) in 25 minutes. This is barely enough to get to narrow down the scope and clarify the requirements.
- Presented me with a specific problem using almost exclusively domain-specific jargon, without explaining any of it. Time limit is 30 min. Not wanting to "waste" all my time budget clarifying, but apparently (1) they did not like anything about what I hacked up (2) wouldn't give any feedback on why they didn't like it either. Ended up really awkward.
- Presented me with a more normal, self-contained design problem (finally!). Time limit is 45 min (seemed reasonable?). So I proceeded normally. However after the interview I was informed that during this 45 min I did not cover a certain topics "A, B, or even C", and therefore scored really low. Apparently, lack of a signal for them is an anti-signal.
The list can go on and on; point being, while the coding questions have been thoroughly calibrated, esp. w.r.t. what is a reasonable time to solve each question, more likely than not a "system design question" is poorly designed. Even from an employer's perspective, I'd be confused about what kind of signal these interviews are designed to extract. Yet, our industry as a whole is increasingly more keen on gatekeeping "Senior+" positions with them (alongside with other draconian measures).
My take on how they can be improved, if not abolished altogether:
1. Relaxing the time limit to say 75 minutes; better to have some people "finish" early;
2. Train the interviewers to help with setting expectations on the pace
3. Either have the interviewer nudge the candidate when the open-ended question receives an unexpected take, or be ready to evaluate them fairly.
These kinds of questions aren't bad per se, but they should be used as a basis for an open-ended discussion with the candidate. Kind of like conversation starters: "Let's discuss how you would approach designing a simple solution that does X, Y and Z".
Asking the candidate to write down a system design on a whiteboard, or even worse, defining the API, is terrible. No one does that in a vacuum, and if they are forced to do it, it's pretty much random whether the person managed to tick all the boxes that the interviewer (or whoever wrote the test) considers important.
This might not be truly universal, but by and large coding interviews can be and has been made more or less a standardized test, whiteboard or online collab (e.g. HackerRank, CoderPad, ...) alike. Like any standardized test, you can practice to become more or less consistent.
It's true that some interviewers might hand out whacky and/or ill-defined problems, but my experience on both sides of the interview indicates that the average difficulty of problems has converged onto what is now known as "LeetCode Medium". The problem will be random, but the difficulty won't. Why this benefits interviewers is left as an exercise for the reader.
> whether the person managed to tick all the boxes that the interviewer (or whoever wrote the test) considers important
Exactly, and "API design" is one of the MANY boxes expected to be ticked early on. Just watch one of these "system design interview how-to" videos online.
> Expected me to "design a xxxxx-ing system" (topic redacted but it's really broad) in 25 minutes. This is barely enough to get to narrow down the scope and clarify the requirements.
System design interviews aren't about system design. They are about demonstrating you are a particular kind of person. They are the vague, undefined, "culture fit" interviews that tech companies pretend they don't conduct.
>>I know how to build these things and I would take time to do it, but I couldn't do it with the very fast speed that I was limited to during the interview.
I've been rejected even after doing all these things. I didn't read the interviewer's favorite paper from Google, therefore the feedback given was I wasn't a passionate engineer.
On the other hand almost anywhere I hear people getting hired often(The ones who jump jobs and get placed often) have struggle staying and building even trivial stuff.
As it turns people who get jobs, are good at interviews aren't all that good at doing their job.
It's funny how mistakes like this always go in one direction (senior candidates being recruited for much more junior jobs). Often a recruiter E-mails me with: "I'm looking to fill a 6 month temp position, 2 years of experience required." (I'm happily employed at a BigTech company and have 20 years of experience.) Or, at best it's "We are impressed with your background doing ABC, and would like to know if you're willing to explore... doing exact same ABC, but at our company instead!" Sorry but no.
What I never seem to get is: "Hi, I see you have a great background with a lot of experience! How would you like to be Senior VP of Engineering at this medium sized company?" That would get my attention!
Recruiters seem to use the query WHERE candidate_level >= job_level, where they'd get more hits if they used WHERE candidate_level < job_level
I get these too and used to wonder what about my profile made me seem like a relatively new to industry person and how I could make myself seem more experienced and qualified.
I always wondered this as well until I saw firsthand how rudimentary most sourcing strings are. The only good interaction I have ever had with recruiting was when I had them run their sourcing string against my entire VP org on LinkedIn to demonstrate that they excluded 90% of current engineers because they were insisting on Java and actively selecting against DevOps. It became less positive when they didn’t change their practices.
76 comments
[ 4.6 ms ] story [ 144 ms ] threadthat ability to empathize & share perspective helps, if not necessarily the ability to sling stuff together & get it shipped, day by day.
Perhaps there are folks in programming competitions that can do that, but not moi.
With some time to get the rust off, yeah though
i dont know mark or his story well, byt a quick review of systinternals & mark does make me question this situation in another way though. mark had enormous opportunity, just vast. 1994 phd. a year at numega, building winternals for a year. cofounding & chief archtiecting a sysinternals startup.
he can clearly hack. i think he still can. he seems to still be the chief blogger/vlogger on sysinternals, an uber-technical tool, serving as a chief information radiator for it; strong technics mixed with great demonstrated communication abilities: a great combo.
but still i can varry some doubt. would he have been a good MAANA employee, or other medium-sized tech company? ever? would he have been able to engage in that kind of product development, amid these product development lifecycles? staying good & sharp & beliving in oneself & what one is up to is a question of opportunity, alongside talent & capability. maybe he would have made a shit sde ii. which he probably does hire many smart sharp well trained candidates for.
Many of the most successful submissions have heavily editorialized titles, sometimes necessarily so - sometimes what’s to be pointed out is something completely different from the page’s title or the page doesn’t even really have one.
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
I think this should be more like “only editorialize when necessary”.
I bet he gets an offer letter before some middle manager goes “oh crap”.
The comp premium is just not there imho for the hit to quality of life (at least for the roles I’d be eligible for).
I personally didn’t bother going through because A) I wasn’t prepared and B) I was locked into a new lease and after some research the relocation benefits they offered wouldn’t be worth it. I believe at the time they weren’t overly flexible on work location.
Can't imagine why they might be hurting for hires...
They did had some interesting looking roles, but the entire work culture seems iffy to me.
To begin with, the "Senior" level at Amazon is designated L6; while Google/Facebook designates their "Senior" level L5/E5. If you visit Levels.fyi [1] you can see this equivalence clearly laid out... except Amazon recruiters / hiring managers seem to really believe that only someone who roughly qualifies for Google L6 can qualify for Amazon L6. I find this delusional at best, because precisely as another comment here said, Amazon does NOT currently allocate enough compensation premium to justify this "high bar". Heck, from the PoV of an actually competent candidate, why would they pick Amazon over other offers, if it means they would have to take a "title hit" in return for... mediocre total comp, worse WLB, constant gaslighting, and low job security?
[1]: https://www.levels.fyi/?compare=Amazon,Cruise,Facebook,Googl...
The only hard thing is frankly balancing salary vs interest. Do you want more money to work on increasing ad click rate by 0.1% or less money to design software for Mars mission.
A common tactics is to enforce YoE requirements aggressively --- basically the jokes along the lines of "10 YoE w/ k8s". These days they do it less blatantly (i.e. the specifics are not written in the JD) but the spirit remains.
> The only hard thing is frankly balancing salary vs interest
I can only say from my recent experience that this is a simplified model. Not saying this is wrong, but some circumstances call for analysis of other factors, such as those involving career path planning. Wouldn't go too deep here but the trick is a lowball'd and/or downlevel'd offer at BigTech/FAANG might actually remain desirable. This unfortunately reinforces their (predatory) behavior, but such is the force of the market after all...
The vast majority of recruiters just do lazy keyword searches and spamming. He or she obviously didn't even bother to read the title or profile of who they were bothering. Spamming is more of a dick move than calling out spam, IMO.
I don't have a problem with my co-workers saying I did something dumb. That's not the same as saying I am dumb.
You should be a little embarrassed if you screw up. You only get embarrassed if you care. Its part of the motivation to improve.
We should absolutely call out mistakes, and it's good if people feel embarrassed for them. I have a few moments in my career where I felt so embarrassed I wanted to slink away and disappear. I'll never forget them, nor the lessons each taught.
This is more akin to being asked to write an auth api, but delivering a fizzbuzz function instead...in that I obviously didn't even read the problem/ask, but instead spammed code to keep the numbers up.
Secondly, every job is different in severity and scope. A surgeon making a mistake is not a fry cook making a mistake is not a civil engineer making a mistake is not a lawyer making a mistake. And public facing roles have different expectations and risks compared to the others. It's what you sign up for, I guess.
To be clear, I don't think this person should be fired or hunted down or anything. I just don't see a big issue bringing it to light with the information given. Amazon could identify them if they wanted to already. I doubt anyone outside could, given there's probably multiple NN recruiters working there.
Nobody is saying the recruiter did a good job here, when someone messes up code in Azure, you didn't see the CTO go "OMG my intern wrote the worst code! Let me post it on Twitter so everyone laughs".
This is a teachable moment -- not a shaming moment.
This is a teachable moment. Amazon shouldn't engage in these practices and should manage the people they employ so this doesn't happen.
If this was an innocent mistake, you shrug, cop a few jokes with your co-workers and deal with it. No one is going to sack you solely over an incident like this unless you've been going against a strict policy.
This is exactly the kind of incident that helps bring recruiters back to reality. Getting dozens of cold approaches about roles that are obviously not a good fit if someone spent 5 minutes researching can be infuriating (or even knew what they were recruiting for).
Probably was a win for Microsoft Azure and its CTO though, with all the viral mindshare
"I saw a job post the other day. It required 4+ years of experience in FastAPI. I couldn't apply as I only have 1.5+ years of experience since I created that thing."
[1] https://twitter.com/tiangolo/status/1281946592459853830
It does sound like a good job, since minimum wage would be more than what you are making per actual work hour as a graduate research assistant.
I went through a few interviews myself recently and I got very puzzled with the interview process. It's quite brutal. And I just went through a 5 technical rounds after passing the first 2 rounds (1 technical and 1 behavioral) for a senior position. The 5 rounds include: architecture design, model/object algo design, refactoring/optimization, build a complete CRUD api with tests. I know how to build these things and I would take time to do it, but I couldn't do it with the very fast speed that I was limited to during the interview.
The worst offenders (according to myself):
- Expected me to "design a xxxxx-ing system" (topic redacted but it's really broad) in 25 minutes. This is barely enough to get to narrow down the scope and clarify the requirements.
- Presented me with a specific problem using almost exclusively domain-specific jargon, without explaining any of it. Time limit is 30 min. Not wanting to "waste" all my time budget clarifying, but apparently (1) they did not like anything about what I hacked up (2) wouldn't give any feedback on why they didn't like it either. Ended up really awkward.
- Presented me with a more normal, self-contained design problem (finally!). Time limit is 45 min (seemed reasonable?). So I proceeded normally. However after the interview I was informed that during this 45 min I did not cover a certain topics "A, B, or even C", and therefore scored really low. Apparently, lack of a signal for them is an anti-signal.
The list can go on and on; point being, while the coding questions have been thoroughly calibrated, esp. w.r.t. what is a reasonable time to solve each question, more likely than not a "system design question" is poorly designed. Even from an employer's perspective, I'd be confused about what kind of signal these interviews are designed to extract. Yet, our industry as a whole is increasingly more keen on gatekeeping "Senior+" positions with them (alongside with other draconian measures).
My take on how they can be improved, if not abolished altogether:
1. Relaxing the time limit to say 75 minutes; better to have some people "finish" early;
2. Train the interviewers to help with setting expectations on the pace
3. Either have the interviewer nudge the candidate when the open-ended question receives an unexpected take, or be ready to evaluate them fairly.
Asking the candidate to write down a system design on a whiteboard, or even worse, defining the API, is terrible. No one does that in a vacuum, and if they are forced to do it, it's pretty much random whether the person managed to tick all the boxes that the interviewer (or whoever wrote the test) considers important.
That is an accurate summary of most whiteboard interviews.
FTFY.
It's true that some interviewers might hand out whacky and/or ill-defined problems, but my experience on both sides of the interview indicates that the average difficulty of problems has converged onto what is now known as "LeetCode Medium". The problem will be random, but the difficulty won't. Why this benefits interviewers is left as an exercise for the reader.
Exactly, and "API design" is one of the MANY boxes expected to be ticked early on. Just watch one of these "system design interview how-to" videos online.
Tech company? Probably a track-ing system. ;-(
Crash/trash-ing system would also be realistic.
I've been rejected even after doing all these things. I didn't read the interviewer's favorite paper from Google, therefore the feedback given was I wasn't a passionate engineer.
On the other hand almost anywhere I hear people getting hired often(The ones who jump jobs and get placed often) have struggle staying and building even trivial stuff.
As it turns people who get jobs, are good at interviews aren't all that good at doing their job.
What I never seem to get is: "Hi, I see you have a great background with a lot of experience! How would you like to be Senior VP of Engineering at this medium sized company?" That would get my attention!
Recruiters seem to use the query WHERE candidate_level >= job_level, where they'd get more hits if they used WHERE candidate_level < job_level
Suddenly I don't feel so bad anymore