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.
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.
"Uh, they're web technologies... in very high demand."
"Yes, but is there a difference between them? What kind of web technologies are they?"
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.
"Did I get that right?"
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.
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."
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.
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.
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.
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.
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.
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).
- 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
- 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.
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.
This was for an analyst job at a bank.
 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.
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 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.
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)
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.
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.
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."
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
Interviewer: How would I know? I’m not a spreadsheet wizard like you.
> 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?
Recruiter: "We're looking for someone with React experience, do you have that?"
"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."
> Do you have experience with React?
The second question can often screen out people who simply maintain framework apps rather than those who actually know JS.
(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)
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.
"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"
I'm not sure where our industry went wrong. You'd never ask a doctor medical school trivia during an interview.
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.
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.
On the other hand, if you don't ask at least some basic questions, you risk hiring the Brillant Paula Bean .
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.
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?
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.
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.
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.
At one point in the past I worked with someone who was incapable of understanding pass-by-reference; something like:
int getFoo(foo *out);
Their resume claimed 5 years experience in C.
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.
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.
"How would you rate your skill with cloudformation on a scale of 1 to 10"
"I guess a 9.5"
No follow up question.
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
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.
"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.
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).
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.
I believe this is the first of its kind. Enjoy.
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.
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 2: s/translator/recruiter/g
Step 3: ?
Step 4: Profit
If you were to type in 5+2 into a cell, what would be the result?