If companies interviewed tech recruiters the way they interview programmers | Hacker News Reader

If companies interviewed tech recruiters the way they interview programmers

medium.com

216 pointsNTDF9103 comments

I am, now and on occasion, a hiring manager. Naturally, every freelance recruiter wants to be my friend.

They often start cold calls with a description of a person's technical abilities, and then ask if I would be interested in interviewing that person.

When that happens, I ask them to define one of the buzzwords that they have just used. "Could you tell me what 'big data' means?" or "What's the difference between AWS and GCE?"

I don't do business with technical recruiters who aren't familiar with the meanings of the terms that they throw around. They have never been more valuable than a regex.

Please, please share one of the funnier stories you have about grilling recruiters who didn't know the difference between AWS and GCE.

Most recently I asked if the recruiter knew the difference between Java and JavaScript, since he had just mentioned both of them.

"Uh, they're web technologies... in very high demand."

"Yes, but is there a difference between them? What kind of web technologies are they?"

Long pause.

The background silence changes a little, as though a hand were placed over the telephone's mouthpiece.

I can't hear the word in the conversation he's having, but it's clear that he is talking to someone.

The hand goes away.

"Java is a general purpose computer programming language with concurrent objects, and JavaScript is the script version."

Pause.

"Did I get that right?"

Perfect.

Next time you should respond, "Hmm...that's not what I have here. The answer is, 'JavaScript uses Electron and Java uses Spring.' I'm sorry, I don't think you're a great fit for us. Best of luck and have a good day."

Then hang up, and kill two birds with one stone in the process: the tone-deaf recruiter finally understands how the buzzword bingo interview feels, and you have one less incompetent recruiter to deal with.

I like you.

There's another side to the value of headhunters and agencies, at least the competent ones, and that's the ability to warm a pipeline of candidates and do a lot of the grooming that your regex, no matter how clever, won't be able to do.

You can scour LinkedIn day and night for candidates, but especially in software engineering, finding inclined candidates is a much narrower task than finding an engineer with big data experience and experience with GCE.

Any recruiters I work with only need to understand how much they need to understand about technical skills to deliver me a workable and most importantly inclined pipeline. It's my job to educate them about subtleties in my requirements.

Edit: I should note, these are recruiters I've worked with on an ongoing basis. With cold calls, if they lead with a frag grenade of skills and buzzwords, that's just a bad pitch imo.

I had a recruiter who called me in the mid-90's. It was pretty obvious I wasn't ready to leave yet, but we struck up a conversation and she called back a couple of times. She did have a basic grasp of the technology, but there were a lot of technologies, much like today, and understanding if an OWL programmer could adapt to a place using MFC was a challenge to recruiters. HR and the computer industry loves buzzwords, so its no surprise recruiters end up using them with about the same understanding.

I guess I always preferred teaching to help enhance the relationship from my side. My being a nice guy and teacher, did help when I wanted to leave.

FWIW also a hiring manager, and I wouldn't say I've seen a huge correlation between technical aptitude and efficacy from the recruiters I've worked with. A good recruiter typically learns what you are looking for and who would like to work for you from how far their candidates get into the interview process and the feedback from both sides, and adjusts to match. This doesn't require having much understanding of any of the technology involved.

The primary litmus test I apply, and I think it is quite effective, is "after I tell you I prefer to communicate via email, do you still call me constantly or do you actually stick to email."

When I read articles like this, I tend to assume that they are exaggerations written by people who feel burned because they didn't get the job they want and that the reason was unfair interview questions.

In other words, I simply don't believe that interviewers are, as a group, so stupid that they regularly ask obscure Excel questions when they are plainly not relevant.

To continue with the recruiting example, I suspect what is more common is that interviewers are expecting candidates with some Excel experience, and ask questions to gauge some basic level of competency. And interviewees have conflated using it one time with any depth of experience.

I can attest to seeing this many times during programming interviews. If I see something towards the top of someone's resume, I will ask a basic question to see if anything whatsoever is known about that thing. Yes, book knowledge. Stuff that you would know if you had actually read any docs.

I don't want to work alongside someone who claims knowledge or experience of something and doesn't know the basics. Or doesn't know that they don't know the basics.

Yes I think you are right, buuuut...

Lots of times the initial screen is done by someone totally non-technical, and they are asking questions from a sheet and judging whether you are saying what is in the answer field for their sheet. This is super stupid, but I have seen it, usually when some headhunting firm is deciding whether to add your resume to their database which they pull resume's from to send to clients.

The moral: Don't use headhunting firms, because they will basically never send you a decent candidate. In the very rare cases where they by pure luck do send a good candidate, this is rarely worth the dozens of crap candidates they have sent you (not to mention that they will try to push candidates on you if they think they can get away with it).

Yep on the first point. I was once asked to bend a comically large paper clip out of pipe cleaners. Next I was to solve some physics questions.

This was for an analyst job at a bank.

Some recruiters/recruiter agencies can be pretty good though. I've had interactions with those that let me surprised at their skill and knowledge.

My past initial screen was hilarious:

  - I see that you worked for a consultancy firm on your previous job. Do you
    have experience working with clients?
  - Yes. My client at the time was XXX Bank where I was involved in foo bar
    baz...
  - So you don’t have experience working with clients.
  - What? Yes, yes I do. I worked and interacted with them on a daily basis,
    with meetings and the like.
  - Okay. Do you have experience with databases?
  - Yes. Mostly Oracle and MySQL. Some postgresql. I’m also quite comfortable
    with NoSQL databases such as Redis and MongoDB.
  - Good. Do you have experience with programming languages?
  - ... Yes.

Some codility tests and interviews later I was notified I was not getting an offer due to lack of first hand experience with AWS (previous interviewers were apparently fine with that, but this one saw it as a red flag, although it was not listed as a requirement in the job offer).

Definitely a good call for both ends, as this was one of those modern companies where everyone are supposed to be friends, play with nerf-guns and have after work drinks. I think I’m too old for that.

For the record, it feels good for once being rejected on lack of technical merits rather than failing some “culture fit” interview. A trend that is giving me the worst interview streak of my career and is making me consider a change of profession.

Sure, but I've just had an interview with a recruiter who literally did the "Do you know Reactjs? Yes. But do you know JavaScript?" face-palm to me. Only with Angular instead of React. Not all recruiters are this dumb, but I promise you I have encountered plenty who are.

That's not "dumb", that's just "incompetent".

After giving them a quick overview of my 6 years worth of Django experience, I was asked if I know Python.

In fairness, I don't consider my javascript skills to be much good[1], but I know React quite well (because I've been using React from clojurescript since fairly early on).

[1] I can get by, but I'm far from a JS developer. I can read JS just fine, but mainly because I've used plenty of other languages, although when I write JS I need to google often and don't write the best JS code.

I don't think anyone is suggesting what is written here _actually_ happened. The point is that you are correct -- most interviews are not so stupid as to ask obscure Excel questions that are not relevant. That just doesn't happen.

The point is that, for some reason, we put up with this kind of behaviour in software interviews, and no where else would it be considered reasonable.

> In other words, I simply don't believe that interviewers are, as a group, so stupid that they regularly ask obscure Excel questions when they are plainly not relevant.

Sure. But I think the point of these constant articles is that interviewers are regularly asking obscure programming questions when they are plainly not relevant.

Programming managers are, apparently, so unsure of their own ability to hire other programmers, that they look up game show questions to grill their candidates with.

I was once interviewing for a fairly generic Java CRUD job, and the interviewer asked me to figure out how to balance a binary search tree. He then interrupted me every minute or so as I was trying to figure out a way to ask me if that was my completed algorithm.

Can you explain what it means to balance a binary search tree? Are you referring to writing your own implementation of AVL or RB trees?

>Can you explain what it means to balance a binary search tree?

Yes, to minimize the depth by "filling" every branch possible/equalizing the number of nodes in every subtree at a given depth.

>Are you referring to writing your own implementation of AVL or RB trees?

Yes, though the interviewer didn't say "AVL" or "RB". I'm not sure I ever even got a class with those in it, and frankly, I don't care enough to memorize how to implement them just for an interview question.

Again, this wasn't Google. This wasn't a firm that did complicated data-structures stuff all the time. They fully admitted how simple their work is. But they asked about how to balance a binary search tree anyway.

I don't think this is a huge exaggeration. This falls directly into the "it's funny because it's true" category, down to the last sentence. I've had far more interviews that went like this than I care to admit. Most of them (mercifully) end at the phone screen and I don't have to haul myself into an office for more of this treatment.

For an industry constantly whining about the "shortage of tech talent" we treat tech talent pretty horribly while we court them. It's like a guy complaining there aren't enough good women out there, starting a date by pulling out a tape measure.

>> In other words, I simply don't believe that interviewers are, as a group, so stupid that they regularly ask obscure Excel questions when they are plainly not relevant.

I was interviewed just a couple of weeks ago. The interview itself was pretty straightforward, but they asked me to do a few test questions, which were very much like those described in the article.

"Here's some really obscure C code with undefined behaviour, what's the problem" "Well, that you wrote it that way, who the hell would write that?" "Sure, sure, but can you see the problem" "Well yeah, you've got someone who delights in writing obfuscated C in weird ways, that's your problem. You could avoid many classes of error here by writing things out in simpler steps."

They were all seriously contrived. (--edit-- and equally as semi-relevant to the role, which is to do with microservices and scalability)

I've been moving around the US for the past few years for personal reasons and I've gone through a round of interviews on every move in a wide variety of situations, and I've honestly never seen anything like this. In fact, I can remember the only two times I didn't actually know the answer to a technical questions, and in both cases I thought they were reasonable questions that tested the limits of what I had recently worked on.

This stuff may have been common 15 years ago, but I haven't seen it for a long time. OTOH, when I'm on the other side of the table, I run across a lot of candidates who literally can't write fizzbuzz in a reasonable amount of time.

"Interview parody" is a common genre these days, but I'd be much more interested in seeing the actual bad questions people are getting in their interviews rather than a parody of them.

I think the reason you don't see bad questions posted more often is that you get comments like the top comment in this chain, where people believe you're just upset that you didn't get the job.

I also think it is more common for recent graduates to get garbage questions about things you never use. Some of my friends had awful experiences over the last couple of years.

Nice. Actually, like me, they feel burned because it took 100 senseless conversations (1 hour each) just to get a likable job.

    Interviewer: It means we do Agile. Everything is in a flat structure, except
    when it comes to salary and responsibilities. We have a Recruitment Master,
    that coordinates all the other recruiters in Sprints.

Absolute gold.

To give credit where it is due, this especially funny quote is nearly verbatim copied from the original article (https://medium.freecodecamp.com/welcome-to-the-software-inte...) from which "inspiration" for this one was taken:

    It means we do Agile. Everything is in a flat structure,
    except when it comes to salary and responsibilities. 
    We have a Translator Master, that coordinates all 
    the other Translators in Sprints."

"inspiration". And I don't think they even fully understood the original, because this joke makes no sense in the new version, but did in the original:

> What filter will you use, if you want more than two conditions or if you want to analyze the list using database function? Candidate: I’m sorry. What? Is that a question?

"""inspiration""". It's a flat-out and less funny rip-off of the original. In fact, several of the responses don't make sense in this version that did make sense in the original.

    Candidate: Forget it. Just give me a second ok? I think I will organize
    rows as candidates and columns as dates/times and use NOW, TODAY, WEEKNUM
    and the rarely used called YEARFRAC

    Interviewer: Oh, no, that’s from the answer sheet in the “Cracking the
    Recruiting Interview: 150 Spreadsheet Questions and Solutions.”

    Candidate: No, I mean, that is something I have used in the past for simple
    fractions

    Interviewer: How would I know? I’m not a spreadsheet wizard like you.

Oh yeah, I read this as like "you fail for giving me a standard answer" but reading the original it's clear they missed the point here.

I get at least 5 phone calls from recruiters a week, being a contractor. The amount of times i get someone that asks me something like:

  Recruiter: "We're looking for someone with React experience, do you have that?"
  Me: "Yes"
  Them: "Ok, how about Javascript?"

I want to explain to them but i end up just saying yes to every acronym on their list since they've no idea what they're asking for.

Actual recruiting call:

"I have an opening for someone with mesosphere and machine learning experience."

"Well, I don't have any of those, but I have used docker a little bit."

"Great, I'd like you to interview."

It's funny because in a different context, that's exactly a sequence of questions that I as an engineer would ask:

> Do you have experience with React?

> Okay, do you have experience writing pure, vanilla JavaScript? Absent a framework like jQuery or Backbone or Angular?

The second question can often screen out people who simply maintain framework apps rather than those who actually know JS.

Are you assuming that people who haven't maintained a vanilla JS app don't actually know JS?

Not at all. I'm getting at the fact that many frontend devs don't know JavaScript, they just know cut-and-paste jQuery or how to fiddle with/maintain React/Angular components in a large app.

I doubt you can really just cut-n-paste jQuery in any nontrivial web app...

Correct, and that's one way to decisively filter out people who haven't worked on a nontrivial web app.

Exactly. A nuanced question like that is beneficial... but it has to be clear that there is that nuance.

As I posted in another comment in this thread, I can actually truthfully answer that with "Yes, No". I've got plenty of React experience, but in Clojurescript and not Javascript.

I would obviously fail the interview, rightfully, since I wouldn't be much good on a Javascript team using React. But I do know React.

(Okok, in reality, I'd learn. Its not that I don't know any JS at all, I do, but I avoid it as much as possible so when I write JS, its pretty bad hacky JS, and I can read it)

20 year recovering recruiter here (now more focused on providing services to help job seekers).

I think at least some of the animosity job seekers have for recruiters is that they may feel recruiters are designing these types of esoteric interview questions and exercises. The overwhelming majority of recruiters are entirely incapable of designing them because they lack the technical skills (myself included).

The recruiter is primarily responsible for identifying a (hopefully) qualified candidate and managing the hiring process along to ensure the "candidate experience" doesn't get in the way of a hire being made. The recruiter might be just as frustrated with that hiring process and the methods as the candidate, but probably has little control over it.

If we want to end these types of interviews, the people to change them are engineering managers. If the engineering manager wanted to end whiteboard exercises and trivial questions on minute details, I assure you the recruiter wouldn't be against it.

Exactly. My interactions with tech recruiters are, by and large, pleasant and effective. There are some bad ones, but most just seem overworked at best, flaky at worst. I don't see recruiters as a major part of the tech interviewing problem. It's not until the point where the recruitment process gets tossed over into to the hiring manager's hands where things go feet-up and I start feeling like a piece of steak being graded.

On the flip side I recently interviewed for a programming position at a civil engineering company and at no point in the process did anybody ask any questions that would in any way test if I actually knew any of the things I claimed to know. The entire "programming" part of the interview was essentially:

"We use quite a bit of python. I see from your CV you've used python".

"Oh absolutely, I consider python the language I know best. I've worked on a couple of larger python applications as well as used it extensively in a number of smaller projects"

"Great!"

Actual programming interview question:

"How would you rate your skill with cloudformation on a scale of 1 to 10"

"I guess a 9.5"

"Great."

No follow up question.

We all deserved to be treated with that kind of dignity.

I'm not sure where our industry went wrong. You'd never ask a doctor medical school trivia during an interview.

I don't know. If I was to get a new co-worker tomorrow I would hope that someone had checked that he had relevant skills beyond knowing that 'python' was a programming language and knowing how to sound overconfident in interviews.

And in the case of the doctor he'll have to have a verifiable degree from a verifiable university as well a verifiable several year long 'internship' from a reputable 'company' before you would even consider interviewing him.

The software industry has a lot of equivalents: we just mostly ignore them. You can have a verifiable degree from a verifiable university with several years of experience in reputable companies and still have to sit down and answer trivia questions and try to program a basic algorithm on whiteboard, none of which you'd need in the day-to-day job.

I think "dignity" is a spot on word for it: professionals like doctors and civil engineers are generally assumed to have the qualifying skills that their resume says they have; software developers are assumed to have no skills unless proven otherwise and your resume barely gets your foot in the door.

Doctors take a test and go through a verifiable apprenticeship period.

If Dr. Nidal got his MD from Johns Hopkins and did his residency in pediatric oncology at Sloan Kettering where he is a fellow and has published 2 papers on Nueroblastoma you can safely assume he knows a thing or two about high risk pediatric solid tumor cancers.

What do we have for programmers?

Github, and the number of stars on their repo.

Most programmers work will be in house.

HN comment history

I'd never get hired

But you will get lots of up votes.

I have a shipping product I worked on for 12 years and that is used all over the industry. I have a public mailing list you can search where I answered questions from developers about the product during that entire time. I have a profile on some well-known programming web sites (like Stack Overflow, etc.). I have a degree from a well-known university and actually have at least 1 paper listed on Google Scholar. I still have had to do stupid whiteboard programming exercises of 1st year data structure and algorithm nonsense.

Yes I'd say you deserve more respect than someone with an unknown background, which is to say most candidates.

Further, when I hire someone to fix my roof, I don't make him build me a doghouse first to scrutinize whether he's any good.

On the other hand, if you don't ask at least some basic questions, you risk hiring the Brillant Paula Bean [1].

1: http://thedailywtf.com/articles/The_Brillant_Paula_Bean

I kind of wish I'd gotten the people I hired to build our terrace to first build something small, like a doghouse, before hiring them.

This is why you ask any contractors for references you can check. Good contractors will provide them willingly.

Another way to get a good contractor (in the first place) is to ask around via a somewhat orthogonal method. For instance, we needed to get a new block fence installed around our house. This wasn't going to be cheap, and we wanted it done right. My wife interviewed several contractors, and half of them were drunk, and the other half couldn't figure out which end of a tape measure to use.

So we got creative: "Who should we call that might know who is a good contractor for block fence construction, and who isn't?"

Well - that's the kind of thing you have to go "inside" the industry; so we figured, well let's call some suppliers of concrete block. A few calls around to these places, asking the people "who would you hire to build a fence" produced a list of candidates from each vendor - and where there were matches, that boosted them on the list. Narrowed it down to three, had them come out and bid, then we went with the guy who struck our fancy best (not with the cheapest - never go with the cheapest, unless they seem the most competent).

We've used this kind of system since (along with checking references and such), and haven't had a problem finding a capable contractor for construction and maintenance work.

Wow, must be nice to be able to pick and choose. Where I am, if you want someone to do roof repair, appliance repair, HVAC work, etc. you basically go with whoever actually manages to pick up their phone. Everyone seems to have so much business that you often go straight to voicemail, and sometimes the voicemail box is full so you can't even leave a message. When you do get a callback, they're all booked months in advance. Man, why didn't I went into a trade?

In this hospital we use scalpels. Are you familiar with scalpels? How would you rate your experience in scalpels?

I'd like to hire you as my lawyer to review my contracts. Lawyers need good reading skills. Can you please read this fax to me and tell me what it's about?

I'm looking for someone to cut my hair. Can you tell me how many hairs are in a typical human head? Can you show me how you hold a scissors? I'm only looking for people with the best scissors skills.

Oh, you're here to fix my microwave? Great. Before we start though, can you show me the contents of your toolbox? I want to make sure you are familiar with all the latest brands of screwdrivers and wrenches. Come over to this whiteboard and draw a typical microwave, labeling the major parts.

on the other hand doctors are credentialed and software developers aren't. you don't get invited to interview for a position as a doctor unless you have your medical school degree, and all of the associated training that goes with that (residencies, etc.). there is nothing equivalent to that for software development, and in fact a computer science degree is sufficiently abstract/mathy that it's possibly to graduate with one and still not really know how to do practical software development.

There are things that are equivalent. The issue isn't that there aren't credentials that could be trusted for software developers, so much as no one interviewing for software developers cares.

My degree was an ABET accredited engineering degree that required practical software development skills (including soft skills). Outside of interviewing in my hometown, no one knows that or cares.

The software industry tomorrow could easily adopt the internships and test/certification requirements of a profession like medicine or engineering. The industry doesn't seem inclined to do so, however, for a weird variety of reasons and excuses, and seems for the most part overly satisfied with trivia questions and whiteboard problems.

> seems for the most part overly satisfied with trivia questions and whiteboard problems.

I agree and it is puzzling to me as well. My own CompSci degree as ABET accredited and I did two years worth of internships before working full time. It doesn't translate into a strong credential though. I still get asked to do whiteboard shit, just like everyone else.

I think it's a complicated issue and is in some sense due to the immaturity of the industry (only a couple of decades old, whereas some other professional disciplines are centuries old). In any case I'm glad it's a topic of frequent discussion in the community. It's important and the discussions are usually good ones.

I believe that it started during the dotcom boom, when a lot of unqualified people tried to join the industry despite having no skills - once you get bit by hiring people who claim (and have) job experience but turns out can't code at all, not even on a basic junior level; you need some process to filter them out.

No, it started way before that. I interviewed with Microsoft in 1993 and had to answer questions like "Why are manhole covers round," and "Reverse this linked list." This has been going on for decades.

My favourite answer to that is: because the hole they are covering is round.

I'd say it mattered less then. This was all new. Nobody knew what they were doing so it was easy for imposters to come in and fake it till they made it. Things are more transparent and aggressive now. The industry I entered in the late 90's is very different than it is today. It grew up.

I think it's at least partly because how averse many shops are to hiring people; even people who clearly lied on their interview/resume.

At one point in the past I worked with someone who was incapable of understanding pass-by-reference; something like:

   int getFoo(foo *out);

A colleague spent multiple hours per day for a week trying to explain this to them. After a week they still were unable to successfully make use of this interface.

Their resume claimed 5 years experience in C.

Isn't this passing by pointer and not passing by reference?

I guess technically in C everything is passed by value but you can pass a pointer to something and call it, naturally, a pass-by-pointer. Since in C you can typically get the pointer value by providing the reference (I don't remember if it is called the reference in pure C, but we are clearly talking about the same thing here) it can also be called a pass-by-reference, consistent with some other programming languages.

Pointers are a specific type reference. As they are the only type of reference built-in to the language, it is common to use the more general term "pass by reference" to mean "pass by pointer" when discussing C.

Some of the best places I've worked at were these. They're more concerned about the person/company fit, which has in some cases been shown to be a better indicator of success at the company (than technical skills).

Although if I were interviewing I'd also ask a few basic programming questions to figure out what kind of programmer they are, how good they think they are, the things they've worked on etc.

I was once sent to interview (by a recruiter I've had who's placed me at a couple of great positions in the past) at a company for a web development position using php.

The interview lasted for a couple of hours. They had 3 or 4 of their developers in the interview as well as the hiring manager. At no point did anyone ask any questions about software development - of any kind. It was really bizarre.

After the interview I told my recruiter that the interview went well - other than not being asked any software development questions. He found that odd, but got back in touch with them.

They basically told him that the position was no longer available and wouldn't give him any more information. A very weird dead end. I would've like to have worked for the company (the web development was for their customer facing sites - they are a retail chain basically, and I have shopped at them in the past), but I think I dodged something there in the end.

That really was funny, but man, it's hard to stomach "inspired by" when realistically it's a Mad Lib of the original post from Free Code Camp.

Total rip off of the original post. What does it bring? The jokes are the same ( and sometimes lose their meaning in "translation")

Yes, almost byte by byte translation, and a bad one. The original is much better.

I guess this title is better aimed at audience though, since many people may not have interest on translation.

Strongly suggest people not read yet to read the original post https://medium.freecodecamp.com/welcome-to-the-software-inte...

These pieces always tend to feel to me like complaining. It assumes the reader already agrees that tech interviewers are broken and does nothing to convince others. I for one don't see whiteboarding questions as a problem, so the scenario rings hollow.

Would you allow me to interview you and ask you some questions on algorithms and data structures and have that recorded for everyone here to see. I bet you that I can ask relevant questions that you'll struggle and most likely fail to answer in the 20 minutes time allotted. And no they won't be from any standard 'cracking the code interview' questions. The point is, the relationship between interviewer and interviewee should be reciprocal. Both should ask questions and the winner gets the job (maybe even the interviewer's job) Now, I think companies would love that as it exposes weakness in their ranks, but interviewers would then join the rank of complainers. You haver to think more deeply about this stuff, not just state whatever you feel like as your righteous opinion.

Time is the most valuable resource which can be saved tremendously if really competent recruiters/interviewers are involved in the recruitment process.

I was recently interviewing for a position with a company behind pushcrew/vwo, it took me roughly 55+ hours (cumulative) to work on their assignment, attend interviews, company/business analysis etc.

I knew the the assignment which I had created was really good given the time constraint on it. Even recruiters acknowledged it (!), but at the end the decision was made on basis of team diversity!! They wanted to have a diverse set of team. I'm not against their decision, it's their company and their team. But to come to this conclusion, there's no need to make a candidate spend this much amount of time.

Just by glancing over resume and previous history, they could have rejected me straightaway OR maybe on the very first call! Both of my interviewers were good, I think, but I doubt they weren't sure what exactly they were looking for? It is simply another set of people, who I believe are from tech background but lack experience in recruitment.

The equation should be managed properly: Tech knowledge + People Skills/Management = Good Recruiter.

A good recruiter should be skilled equally in tech + his/her people reading skills. It saves a lot of time, money and efforts for both of the parties involved in the process.

Recruiters usually aren't good at programming. If they were - in most cases - they wouldn't be recruiting, but writing code... So their "identification of good programmers" is somehow limited...

There are places where good technical recruiters earn substantially more than programmers - if they get 10% year salary (which I understand is not the highest number you might see), they only need ~1 successful placement a month to make reach parity.

Not only that but they may just enjoy recruiting more than they enjoy (or don't enjoy) programing.

The two recruiters I know basically did it has a mid life career switch.

Why are we suddenly inundated with "If companies interviewed * the way they interview programmers" posts?

because the community is super frustrated with the state of interviewing.

It's quite interesting how different submissions on the front page build on each other and there is a sort of meta-conversation happening with the flow of articles.

I think AI or whatever you want to call it is not up to it yet, but it would be an interesting investigation for in a few years.

Because people copy things that have been recently popular, as a way of boosting their own audiences.

"Curated list of XXX" was popular a while back, after that it was "Machine learning applied to XXX", and this week it is recruitment.

Next week it will be something else.

This is the first one I’ve seen in response to the translator one and would love to see more.

https://medium.freecodecamp.com/welcome-to-the-software-inte...

I believe this is the first of its kind. Enjoy.

Because sometimes people need to see the typical practices lampooned through another field's criteria before they can realize how far off the rails their own field has gotten.

See all the people who always pop up in interviewing threads to say that this crap really is necessary in order to test for knowledge of "fundamentals" (defined as a small set of algorithm questions that candidates now memorize the answers to out of books with little or no actual understanding, since all they have to do is regurgitate them, not understand them) and to weed out people who "can't code" (defined as people who haven't memorized the set of stock answers from the books).

> You see, we are looking for the very best Recruiters, and it has been proven by major companies that the people that are able to do the job best have a very solid foundation in spreadsheets for quick applicant tracking.

Doesn't the punchline hinge on the above quote from the interviewer being false?

In other words, if the research really did show that testing on spreadsheet desiderata would get you the best recruiters, there would be no joke here.

edit: clarification

This is a picture perfect description of my interview with stitchfix.

I'm sorry to hear that. For which position were you interviewing?

Engineering. First job ive never gotten an offer for. I feel like they werent serious about hiring and maybe they were required to interview a number of non internal candidates and were just checking boxes. Huge waste of my time.

Granted I acknowledge Im not perfect and desirable in every way, but the interview felt really silly

I get that the point of the article is to point out the flaws of technical interviews, but I see a lot of people griping and quite frankly circle jerking about how bad recruiters are.

I am definitely "mid career" at this point and a manager and I consider my "recruiter bench" to be a huge asset, both for when I am hiring, and also looking. The thing is, yes absolutely 80% of them are garbage- they are mere regex's and will likely be out of the industry in a few years.

The other 20%, that really know their shit, and have deep connections in the industry are gold though. What you need to do is find those guys and build relationships with them over time, so when you have an open head, or decide its time, you already have a half dozen people you can call that you have a long relationship that you trust to help get you a job. These guys can also just give you good intelligence- what is hot right now, what is not, who is paying well, which companies despite their darling status at the moment can't seem to keep an engineer in their seats more than a year.

To get that kind of info though, you have to build a relationship. If I see someone that writes a well informed, grammatically correct email to me, I will look them up on LinkedIn. If they have been around awhile, have some shared connections with me, maybe shared some posts that are interesting, I will usually give them a call back and say "hey I am not interested, but lets keep in touch- here are some things that might interest me in a new role, you are welcome to bounce stuff that fits this off me any time." They will inevitably continue to call you over time- and that's when you can start asking them stuff- who is good/bad, etc. Even offer to get drinks (they will almost always pay)- that's when you can get the really good gossip.

If you keep that bench warm, you will likely find that the quality of potential positions thrown your way improves dramatically, as well as the quality of potential candidates. At least that's been my experience.

Step 1: Copy post from Free Code Camp

Step 2: s/translator/recruiter/g

Step 3: ?

Step 4: Profit

Why-is-the-title-written-like-this?

because-it-makes-you-read-it-faster?

To save space(s). :)

I actually created an Excel question for interviewing help desk candidates:

If you were to type in 5+2 into a cell, what would be the result?

:-)

Instant classic. Hilarious -- and spot-on.

Reply on news.ycombinator.com