I'm currently writing a book on the subject of bad hiring practices, and other management mistakes. Allow me to share some of what I wrote:
---------------------
Homework assignments and personality quizzes won’t give you excellence
This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program.
Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned.
"Wow, I didn't expect things to move this fast!" she exclaimed.
Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!"
Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.”
At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?”
What an empty ritual; reading words that are not understood.
I'm confused. Did you suggest she 'come by the office and meet the whole team' or did you 'ask her to come by the office for an interview?'
I can see how she'd be so excited because it implies she's getting hired or is very close to getting hired, while the invitation to interview is just a standard hiring event.
Did you hire her? If not, the meeting before the interview wasted everyone's time.
I think of the coding challenge as a way to understand what kind of code can I expect from the candidate. Having seen many (from who we hire), helps me determine what kind of training I need for the team, what kind of standards need to be set to prevent some type of code and how can I expect the codebase to evolve.
It helps dramatically in determining the level of the person (junior, intermediate, senior, etc.). The level is subjective to the company, that's why it's important: definition of senior at one company is very different from the other. Notice that a coding challenge without a technical chat first is kind of useless though. Various strong developers would just write the shortest code to complete the challenge, instead of trying to show off, so you have to read between the lines.
A cool thing about this is that you can have an idea of the level of interest of the candidate.
Finally, isn't everything just signal? The entire goal is just to have many conversations so that by the end of it, we have a rough idea if we like each other and can work together.
Coding challenges used to sound like a good idea to me. Who wants to go through the whiteboard torture session?
The last time I looked for a job I was presented with multiple "take-home" coding challenges. I had to spend hours on them each night after working my regular job. It was exhausting. I would send it off and either receive no feedback at all, a "thanks but no thanks" with no constructive feedback, or an invitation... to come in for a whiteboard algorithms red/black tree interview.
Ultimately I got a job that had a traditional (sucky) interview process.
These coding assignments are a disrespectful waste of time.
Homework interviews are terrible because they cost absolutely nothing for a company to give.
You can spend 4 hours on them and perhaps nobody will even take a single look at it, they just gave it to you because why not.
They’re also (IMO) pretty low signal because you could cheat on them easily.
Meanwhile a phone interview (even if algorithms) takes only 60m or less and shows the company is at least invested enough in you as a candidate to have somebody spend that time with you. Cheating is definitely still possible, but harder and more awkward. It just seems better overall.
I agree with that statement, that's why we put the coding challenge to _after_ the technical chat. The technical chat (which is just a chat, no algorithms involved) is performed by a developer, it's 45 minutes chat. Only after that there is the coding challenge.
The company is definitely invested by that time. I also enforce the rule of providing feedback, as well as invest an enormous amount of time reviewing and evaluating the submissions (at least 1 hour + time to write down feedback, points to further dig through during the next interview step).
And yes, when applying for a job it's the worst. I also have no solution. Removing it would mean making the "full day with the team" even longer and more stressful (I'd rather do less live coding than more).
Yes it can be cheated, but that would come up in the full day interview (it did happen), so it's irrelevant, there are multiple filters on purpose, however each filter is more expensive for the company or the candidate and balancing between the two is important.
That's also why I think a chat with a developer is important to have as early as possible.
> The last time I looked for a job I was presented with multiple "take-home" coding challenges. I had to spend hours on them each night after working my regular job. It was exhausting. I would send it off and either receive no feedback at all, a "thanks but no thanks" with no constructive feedback, or an invitation... to come in for a whiteboard algorithms red/black tree interview.
That's the reason I advise against them.
Unless you are the top company in your bracket, your completion rate will also not be so great for a take-home (people have limited time: they'll sort by how good your company is). Sure they'll do Google's take-home but local business that does local comp/prevailing wages? It's at the bottom of the pile. By the time they get to it, the best candidates will already have an offer from a better company.
That's why I prefer to bring people on-site as soon as possible, and do a little whiteboard (the point being that the candidate must... know how to code!). It's an artificial challenge that's really a pretext to have a technical discussion.
Only time I advise to use take-homes is when you are dealing with a massive number of applicants from institutions that have a poor signal to noise ratio. Bootcamps come to mind. But then you end up with candidates that have the homework done by someone else and it ends up not being a good filter either.
> ...I think of the coding challenge as a way to understand what kind of code can I expect from the candidate.
Sounds reasonable in general and especially if indeed the resulting code will be seen with constructive and qualified eyes, or better yet, a feedback on it will be given back to the candidate.
In contrast to that, too often there is too little meaning to creating such a hurdle, when it's just a gauge for discipline and compliance. This is especially true of junior devs, who still have tons of doubts and need direction and good examples to follow.
Wastefulness at interview stage may be an indicator of wastefulness of internal culture. Imagine a surprise of a new hire, who would readily jump into the new assignment ... just to later discover that it was shelved, or worse, was given just to keep him/her busy and "get used to the process".
> I think of the coding challenge as a way to understand what kind of code can I expect from the candidate.
I think you get the "coding challenge kind of code" with varying degrees of the subject's personal flavor on it. People can and will produce different kind of code in a different setting, or if you just ask them to do so. So it might not tell you as much as you think?
EDIT: Virtually every employer / project I've worked on has had completely different requirements for what the code should be like. And my own style(s) for my own projects is again completely different. There's no "here's the kind of code I produce", but "what kind of code would you like?". And it's ok not to get it right in the first sitting, these things are discussed and they evolve internally in reviews, style guidelines, meetings, etc.
> A cool thing about this is that you can have an idea of the level of interest of the candidate.
Towards what? The coding challenge? The long overdue neo-legacy project you're going to hand them? Just having a job?
How does that interest show?
> Finally, isn't everything just signal?
The signal doesn't necessarily say what you think it says. That's the biggest issue I find in all these hiring threads. If you do such and such, you suck. Good candidates do this and that. I wouldn't hire someone who X. The best candidates Y. Bla bla, yada yada, on and on. I feel like there's an immense amount of assumptions that hold.. in the interviewer's mental image of the ideal candidate / stereotypical poor candidate. In reality it smells like prejudice and "no true scotsman" all over, at least when taken with the limited context we're given.
And my anecdote is that the signal is very often wrong. This comes mainly from helping out newbies and/or joining educational groups. Many times the first impressions mislead: I can't help but think "this dude has no clue" and I'm almost ready to write them off as a hopeless case. But give them a few weeks and many of them turn out to be very competent, fast learners, good thinkers. It's easy to underappreciate how diverse people.
> I think you get the "coding challenge kind of code" with varying degrees of the subject's personal flavor on it. People can and will produce different kind of code in a different setting, or if you just ask them to do so. So I don't think it helps you as much as you think?
Good point. The hiring process I work on is definitely not objective though and I don't expect to be able to have an objective process. I expect to have a subjective process (yes, it's driven by people) but have people on the job we are happy to work with (not necessary excellent).
Striving for the best candidate is great, but I have no idea what to do to achieve that, I'm working on it.
Referrals are a great way, but that resource is used extensively already, there is a need for also the other funnel (lot of hiring needed), there aren't enough people in just referrals.
> How does that interest show?
In various ways, as I said, I think being subjective is the only way to manage a coding challenge, is not an objective measurement by any mean.
Sometimes it's clearly a showcase (this part is too easy, I don't care, but you should really look at this small snippet), sometimes is "this is way too easy, here is an 80 lines script to do it efficiently, you don't need anything else", sometimes is a widely designed system for the purpose of showing design skill.
Sometimes people have no time, but the question needed to answer is "can the person code and do I want to bring them to the next step".
Sometimes I can't infer anything aside from the "can code", there are many variables at play.
Everything is signal, but I'm not looking for something specific aside from the "can code".
Sorry, yes, there are people that can't code at all and do apply and we have to filter for them. Consider the challenge a captcha for developers.
The first chat with the technical person should highlight if there is a need for a coding challenge at all. Like, the very strong candidates are so thoughtful that's essentially pointless to ask them to code. They are also rare and far between, though.
The average candidate can code and something can be said based on their coding challenge, which is not necessary something measurable or comparable, but it is something useful to understand who that candidate is.
I'm struggling to express my thought because I'm the first one to say "I should be able to chat with a person for ~X hours to know if I want to hire them", however I'm faced with the reality that:
- it's expensive (people hiring should be your strong people)
- guts are not always right, occasionally they fail and that candidate is not good
- the best experiences I had as an interviewee did involve some live coding, although that wasn't necessary the focus of the interview: getting to know the people on the other side and pair with them is what made it a good experience. I dread live coding, but in some form those interviews were great
- met candidates which were amazing in all forms of chat, everyone hyped, until we faced them with technical stuff (very basic)
I don't think there is a saving grace for the process I'm currently using, however I can't find a solution either. A simple chat with the team has proven dangerous as well as expensive multiple times.
An objective process has proven impossible and rigid. We are talking with humans, I'd rather tune every evaluation to the candidate itself, which in turn leads to making the process hard to evaluate.
Referrals work only up to a certain point, given the amount of people needed to hire, it's not a funnel big enough.
I wish I could solve the problem in some way, I read and study, but I still haven't found a way to solve it.
Almost forgot:
The coding challenge keeps being a useful way to sprout conversation during the "full day with the team" interview, so it sets the ground for that too.
No, just a candidate with low interest in the job. As I said the challenge must come after a chat with a technical person.
It's a good way to assess the level and filter out the kind of code you want or don't want to deal with. Or just help identify what you are looking for.
In the end every suggestion misses _some_ data points that could be useful in a form or another to hiring.
Either way, our process is flexible. The tech screening comes first, so depending on the candidate we might not ask about a coding challenge at all, it would be even embarassing to ask given the seniority of some people (masters).
This supports the view that any interview is really focused on finding a reason not to hire someone rather than finding reasons to hire them. Because if the candidate isn't already someone that could do the job then the company wouldn't be talking to them. I think I first read that view in the book "What Does Somebody Have to Do to Get a Job Around Here??" by Cynthia Shapiro. Some of the advice in that book is a bit dated but it does a good job of conveying the main challenges from both sides of the hiring process.
> This happens when there is a glut of qualified candidates relative to demand - as there is for junior devs.
But, the process doesn't materially change when companies are looking for senior or mid-level developers, except that they then start adding system design rounds.
Incidentally, I just had a thought: if there really is a glut of junior developers relative to demand, shouldn't that push down wages? It seems like there's some sort of market failure at work, but I'm not quite sure exactly what's causing it.
If you're really a senior developer, will you enjoy to work with C's?
Try to actively «fire» the interviewer at the first minutes of interview by showing the darkest points of your CV upfront. If you succeed, you will save 6 hours of hazing and a few months of your life after that.
I was in a team with inexperienced PM and few crooks, which negotiated 2x salary over mine, but had no skills. They hated programming, actually. I tried to help, but PM fired me instead. The project collapsed, so they started to blame me, damaging my reputation. It was an awful experience.
For me, it's easy to recognize the technical level of somebody else, because I will just ask a high-level question and then see how the discussion goes. If they say «Okey, now tell me about your experience», then they are definitely not A's.
You cannot bullshit A's, so bringing your weak points to the table upfront will give you some credibility in the eyes of A's, but it will do the opposite in the eyes of B's. It's detailed in "Getting naked"[0].
If you are doing consultation and want satisfied clients only, or looking for an A level job only, then it's OK. If you are looking for any job (with high salary, of course), then it better to hide your weak points, to be accepted by a B, and then do the dull work.
I'm sorry to veer off topic but is anyone else infuriated that a brand new hard cover edition of this book is $13 (or as low as $7 from other sellers) but the Kindle version is $15? I don't even own a Kindle but that's ridiculous pricing.
It's immaterial because the 6 hours of hazing, which resembles nothing like what one would encounter on the job, is the bad part. Is the point of a hiring process to hire people who can regurgitate algorithms on a whiteboard in 45 minutes, or is it to find the people who are best able to do the job you're hiring for among the people who are willing to come work for you?
There is a glut of people who want to do the job because of its perks, however there's still a shortage of people who are capable of doing it ( as defined by the employer)
Sure, but if wages for juniors were more like ~40k instead of 100k+, and there was a steep upward wage growth from junior to midlevel to senior, you don't think that would change the candidate pool?
> Because if the candidate isn't already someone that could do the job then the company wouldn't be talking to them.
No, there are a huge number of unprepared applicants. Most are just a time waste, knowing just enough to get to the technical interviews without being able to pass them.
The fact that you're expecting prepared candidates is a red flag on its own. As an experienced professional I shouldn't have to prepare for your interview except for maybe reading up on the company.
>This supports the view that any interview is really focused on finding a reason not to hire someone rather than finding reasons to hire them.
I completely disagree with the current interview process as it existed for the last 20+ years. Last discussion I had I came to the conclusion that big tech companies created this process to not hire domestic workers so they can use H1-B visa workers, who are much easier to control under threat of deportation. H1-B was really big in the early 2000s which is when this process really started. There is a legal requirement to hire H1-B that a company must try to find a domestic worker but were unsuccessful. This style of interview process fits that requirement perfectly. The industry just happened to cargo cult it and here we are, massively employing an interview process designed not to hire people.
Additional requirements for H-1B-dependent or willful violator employers with LCAs filed prior to October 1, 2003 and after March 7, 2005.
No displacement of a similarly employed U.S. worker beginning 90 days before and ending 90 days after the filing of an H-1B visa petition;
Recruitment of U.S. workers before seeking an H-1B worker.
Offer employment to an equally or better qualified U.S. applicant for the job for which H-1B workers are sought (enforced by the Department of Justice).
Like @zerocount alluded to, asking her to come by the office "and meet the whole team" has a completely different connotation than "for an interview." You could probably spend an entire chapter of your book on the differences.
As a candidate, I personally liked the short (30 minute) online coding quizes.
First, they're an easy-for-me filter to pass. There are a lot of unqualified candidates just spamming their resumes, so I totally empathize with a company needing a low-effort filter on their side.
Second, if the company doesn't like my code, I don't want to waste any time. I've been in a few situations where an interviewer has a chip on their shoulder and rejected my perfectly fine solution that didn't have a microoptimization or other detail that I could only infer from mind reading.
What'd you think of this method for homework. I asked a junior candidate (web-dev) for their portfolio, they didn't have one. I told them that was okay, but advised that they complete a generic exercise I gave them and host it publicly on their Github for extra credit.
Candidate get's a better portfolio of work, and I get to see their style. Seemed fair to me?
Homework assignments and personality quizzes won’t give you excellence
This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program.
Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned.
"Wow, I didn't expect things to move this fast!" she exclaimed.
Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!"
Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.”
At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?”
What an empty ritual; reading words that are not understood.
If you are lost at sea, don’t drink the brine
Stories abound of people lost at sea, perhaps because their ship engine died, or their ship sank and they escaped in a life raft. Once the clean drinking water runs out, the temptation to drink the sea water is strong. But of course, that is a fatal step: the sea has more salt than than the human body can tolerate; drinking makes you more thirsty, not less so. And yet the sea is vast. What a paradox, to die of thirst amid such an abundance. “Water, water, everywhere, and not a drop to drink,” as Coleridge said.
I’ve had this conversation with tech team leads:
Me: Where are you looking for candidates?
Them: I’ve put a job posting up at LinkedIn and Indeed and StackOverflow.
Me: Did you get any candidates that you like?
Them: Well, the problem is, I’ve gotten several thousand. The problem is trying to narrow down the pile. I cannot possibly look through all of them. I’ve decided to post the job a second time, but this time I created quiz that people have to take.
Me: What is the quiz about?
Them: It’s 100 questions about the technologies we use, plus some algorithm questions that should help cut down the number of applicants who get through.
Me: You created the questions yourself?
Them: No, I copy-and-pasted them from various online sources. Most of them are about standard stuff. I put in a few trick questions to help filter out the weak candidates.
Me: Are you sure you want the candidates who get your trick questions?
Them: Well, if they get the trick questions, then they must know some fairly obscure stuff.
Me: Is that what you need right now, people who happen to know some fairly obscure stuff?
Them: Well, not really, our work here is fairly standard, but I need some way to screen the applicants because the first time I posted the job we got way too many responses.
Me: Are you sure the people who get your most obscure questions are the candidates who will work out the best once you hire them?
Them: No, but I’m not sure what else to do. You never really know about a person until you’ve seen them actually work.
Me: How many people do you need to hire?
Them: I need 3 developers for the frontend, and 2 more for the backend.
Me: That seems like a manageable number. Have you tried to find some good candidates from friends of friends?
Them: Oh, I don’t have time for that. We need to move quickly with these hires.
Me: Is that any slower than making up quizzes for Indeed?
Them: Well, I’m not sure how I would even start.
Me: Something simple. You could go through your email contacts and make a special list with the email addresses of those who you know work in tech. Software developers, project managers, designers, anyone who might be able to give a meaningful recommendation. Send out an email explaining what you’re looking for.
Them: Hmm, well, some people might feel that I’m trying to poach talent from their team.
Me: They don’t have to respond. They can simply remain silent.
Them: I worry it would feel like I’m asking for a favor.
Me: That’s exactly what you are doing, you are asking for a favor. And then later on, when they are hiring, you could potentially pay them back by recommending someone, if at that later time you know of a good software developer who is looking for a job, when you yourself are not hiring.
Them: Yeah, but, if they don’t know of anyone, then it’s just a big waste of time.
Me: But it sounds like your original effort with Indeed was a waste of time.
Them: Sure, but now that I’ve got a quiz in place, I’m hoping to filter out more of the applicants, so I’ll get a smaller number.
Me: But the process does take time, right? No matter what you do, you have to invest some time in this?
Them: Yeah, it really sucks. I’ve got a lot of work to do, but instead I have to waste time hiring.
Me: But hiring is work. This is the work that you are doing right now. This is important.
Them: Sure, I guess that’s true, but I’ve also got a lot of software that I’m supposed to write.
Me: But as your team grows, you’ll need to spend less time writing code and more time focused on management tasks, such as hiring people.
Them: I’m afraid so.
Me: Is that something to be afraid of? Your team is growing, it sounds like things are going well.
Them: Yes, I guess that’s true, but I’m worried, once I’m no longer writing code every day, and reading everyone else’s code, how can I be sure the quality of the work will still be strong?
Me: You could hire excellent people and then expect excellent results from them.
Them: Yeah, but that’s a lot easier said than done. You should see some of the resumes that I got from the applicants. Full of typos, obvious exaggerations, mistakes about dates, or dates that overlap, stuff that makes no sense. Some of these resumes are so bad it’s funny. I’ve started sharing them with the team so we can all have a laugh about it.
Me: It sounds like Indeed isn’t really giving you what you want.
Them: That’s true, Indeed sucks. The applicants we’re getting from these online sites, most of them are really awful.
Me: Are you sure you don’t want to reach out to your acquaintances and ask them for recommendations?
Them: Oh, gosh, no. Like I said, that would take too much time.
For many categories of job applicants, job sites like Monster or LinkedIn or Indeed or StackOverflow are basically like drinking the brine: they offer such a abundance of material that you are tricked into thinking “Surely we can drink an endless amount from this source.” And yet, they waste so much of your time that they are effectively a kind of poison.
It's pretty obvious that this whole "email everybody you know" method to find candidates has some serious selection biases. In particular, you're more likely to get referrals to people who are in the industry and have proven themselves, which clearly isn't a bad thing in and of itself, of course. However, I'd be concerned that this sort of thing just selects for people who are like the people that you know already. That doesn't seem like a solid strategy when what you want is actually the best available people who are willing to come work with you. How would you design a recruiting process to attract those people?
You don't need "the best available people" though unless your plan is to completely dominate an entire industry (maybe it is, but it's probably not). And even then unless you've got enough money to make your developers rich and enough interesting technical challenges to keep them there after they are, you're not going to get the best people at all.
Excellent question. If one accepts that no hiring process is 100% objective, then one is left with the conclusion that the only way to have a hiring process that is fair to everyone is to deliberately aim to overcome one's subjective biases. I try to address it in this part of the book:
---------------
Recommendations from friends or friends of friends should count for a lot
When hiring, I rely heavily on recommendations from people I know. To use some Silicon Valley jargon, I rely on "social proof." If a good engineer, who I've worked with, recommends some other engineer, that counts for a lot with me.
I wrote this on Twitter and James Youngman responded, “It seems to me that this kind of approach is what perpetuates the domination of the industry by an in-group (who know each other, directly or indirectly) at the expense of outsiders, to the detriment of both diversity and fairness.”
To be clear, this approach very much works when you are hiring novices who are straight out of school. Back in 2018, when I need some junior level frontend software developers, I hired several women from the Grace Hopper program for women that is run by Fullstack Academy. In that case I spoke with some experienced friends of mine who had either taught at the schools or volunteered as mentors at the schools. As such, they could point me to who were the best of the graduating class. As it was, I ended up with an unusually excellent team of novices.
We all have a professional and ethical obligation to be sure we hire a diverse workforce – the workforce must be open to anyone who has real talent. There is no contradiction between that obligation and a requirement that a candidate be recommended by someone we trust. Assuming you have friends who understand their professional and ethical obligations the same way you do, they should be able to give recommendations on people they know, or put you in touch with friends of theirs who can offer such recommendations. Within your extended social penumbra of friends, friends of friends, and friends of friends of friends, you should be able to find someone who can vouch for most of the candidates that you need to hire. You just need to put in the effort, chasing down those recommendations through extended chains of friendship.
Beware of fake, dishonest attempts at establishing an "objective" hiring process
In the tech industry, I've seen good people, full of good intentions, invest serious time in developing what they felt was an unbiased, fact-based system of hiring, but they were blind to extent their own preferences were being treated as facts.
A specific example of this: there was a CTO, a man I've worked with and who I largely respect, who put serious time into developing a code base, and then deliberately adding some errors and redundancy to it. This code base would then be given to job candidates, as a homework assignment. Could they find all the mistakes, fix them, and remove all of the redundancy?
Many people in the tech industry now rely on tests like this, which are seen as being more objective than older job interview techniques. But this overlooks how much of the assignment is actually subjective in nature. In particular, what does it mean to reduce redundancy in a code base? Anyone who's done much programming is aware that one can refactor a code base almost to infinity. One can create more and more abstractions. At the extreme, one can create a new programming language where the program is represented by just a single character, perhaps the letter "w"":
w
There it is, the whole entire program that runs a major website. Of course, you also need to create a compiler that knows how to parse that letter into a lower level language that would do the real work of running the website. But if you ask a software developer to remove the redundancy in your code base and they come back to you with code that has more than 1 letter in it, then they've clearly failed the assignment.
Am I being ridiculous? Yes, absolutely, because I'm ignoring nuance, subtlety, reasonableness and proportionality ALL OF WHICH ARE SUBJECTIVE. If you want a truly objective standard, one needs to accept absurd, surreal, and almost psychotic behavior, because that's what human behavior becomes when you try to remove all subjective factors.
Does this mean the hiring process can never be truly objective? Yes.
Does this mean the hiring process must be unfair, unjust, corrupt and cruel? No.
It's surprising how acclimatized people are to bad hiring practices that good treatment seems fishy.
We at UpSkillie, help companies hire engineers by certifying with a round of interviews. Candidates win because now they get someone vouching for them past the gatekeepers.
For a 1yr experience developer, one of our client just took a single round of interview after our recommendation and made an offer the same day, the exact amount the candidate wanted.
The candidate didn't join this company this company because he felt the HR process wasn't streamlined as he got an offer in just one interview. He settled for a 20% lower offer.
We asked him that if he wishes we can set a meeting with leadership if he wanted. But he just didn't feel it right because the process was fast.
There was proper introduction before the technical interview, so there is no chance of lack of familiarisation.
Funny. It's like people have been brainwashed into thinking you have to go through the whole "20 minute chat with recruiter, then phone screen, then 6 rounds of hazing" before it's a legit interview process or something. It's not like we're talking about some shady WFH scam or MLM where everybody gets the "job."
For technical interviews I've settled down and just ask the candidate questions about things _they_ are familiar with, so things they've done recently and then try to gather how much they really understand about that, if enough seniority then also how much they contributed towards decision making.
After all I'm trying to find, do they have initiative? do they care? do they make informed choices? do they think by themselves?
I was recently appearing for an interview and a fintech org did this. Wow that interview was so pleasant. I did not have to worry about forgetting where algorithm X is O(N^2) or O(2^N).
and since they asked all about my experiences and what was written, I was able to articulate more than I would in usual tech rounds.
Although we couldn't agree on location for personal reasons, that is an org which I would recommend specially as they really wanted to know the candidate's behavior and not whether he could remember some implementations which they're mostly never going to use.
> Forgetting where algorithm X is O(N^2) or O(2^N)
I find it absolutely shocking that you would consider it trivial knowledge whether an algorithm is low-degree polynomial or exponential. The pendulum is swinging way too far to the other end. If you can't remember/figure out whether the code you're writing is O(N^2) or O(2^N) you should not be writing code professionally.
In technical interviews I conduct I also include a system design challenge. I present a large scale architecture problem our company has had to solve and ask the candidate to take us through their process of designing a solution.
Excellent candidates are not the same as the ones who arrive at a similar solution to ours. The best candidates are able to ask important questions about the requirements, and when asked can provide rationale for choosing specific components, as well as other potential options they considered.
More often than not this kind of question is assessing your process, not the outcome you produce.
Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews.
The exact same pattern happens with product managers. There are very specific types of interviews and there is an entire industry built around preparing candidates for these types of interviews. At that point, is the interview process still effective? I'm certain there is a pool of fully-capable people out there being left behind in sub-optimal careers for no other reason than they've underestimated or are ignorant of the need to prepare for an interview exercise that is, at best, loosely related to the work they'd actually do.
I suppose the counter-argument would be that good candidates should be able to figure out what they need to do to successfully complete a task, and properly understanding and gaming the interview process showcases that skill.
> Much like standardized tests are meant to assess objective aptitude but invariably favor those who specifically prepare for the test, which diminishes their objectivity, these types of interviews vastly favor those who specifically prepare for these types of interviews.
But those who prepare for system design interviews are most likely better equipped to design systems in real life too, because they had to go through the different problems and types of systems and their requirements.
Now that doesn't mean they can implement it end-to-end, but you could probably tell those who are over-engineering it from those who actually either have experience or solid foundation to make good decisions.
> By this I mean that it should be obvious that they’re also screening for how pleasant you are of a person to work with on technical problems.
In what way should this be obvious? Do they insult you and see if you react poorly? Normally you do this by just working through a problem, and then after the interview you evaluate whether the person was unpleasant to work with. There is no unnatural process required, you get that for free.
I think a lesser mentioned topic about interviewing is that the expectations / rigor of the interview vary parabolically based on the tenure of the position and how many years of experience you have.
For instance, even if the interview prompt doesn't change - an interview for a mid to senior position expects far better communication and execution than that of a NCG interview etc etc. This is sort of a self-fulfilling prophecy for people with more than 2-3 years of experience who don't perform well or haven't grown.
Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc?
That seems to me to do away with the need for a coding challenge as well as demonstrating a lot about their approach and interests.
On the whole, I'm surprised by the number of people who think both coding challenges and whiteboard interviews are a waste of everyone's time. Is the employer not supposed to assess the candidate in any respect?
> Shouldn't candidates have portfolios -- i.e., examples of software that they have built, with a complete git history, etc?
Most career engineers (including myself) have worked on proprietary systems. I can't show you any production-level code that I've written in the last 10 years, because it's all proprietary and owned by the companies I've worked for. I don't even have access to my previous employers' code! So what exactly would I put in my "portfolio"?
If the answer is "open-source," then that presumes that the only engineers worth hiring are those who contribute to open-source -- which leaves out a ton of great engineers -- and those who have the extra time to contribute to open-source outside of their day jobs -- which can be a bias against those with life obligations (e.g., caring for dependents).
So the answer to your first question is: no, they shouldn't. If you have one, FANTASTIC. But it shouldn't be a requirement.
To your second question... Employers need to evaluate candidates _somehow_, so yeah, I'm baffled by that as well.
> If you can, schedule your interviews in the order of importance for what job you think you might want an offer for. This isn’t to say that you should in any way not prepare for those earlier interviews;
I don't understand. Does this means that I should schedule interviews for jobs I want sooner or later? The wording "order of importance" is ambiguous which order I should follow.
"In the order of importance" means ascending. Basically if you're applying to 5-6 jobs, try to schedule the one you want the most last, so that when (not if) you bomb some aspect of an earlier interview, it doesn't a) completely depress you for the rest of the interviews, and b) can be a learning experience for later interviews that you ideally would like to get offers from more.
Yeah, this was definitely lazy writing. I think the author meant to say that you should schedule real interviews you care less about prior to those you actually want. That way, you have a few warm ups with real skin in the game, but if you bomb it's not going to take away a serious opportunity. I usually do this with interviews at Amazon since it's fun to waste their time.
some job screenings are really ridiculous: coding is not rocket science, come on
(yes, I understand the need of filtering in case you have a lot of application, but how many have a lot of applicants?)
---------------------
Homework assignments and personality quizzes won’t give you excellence
This year I was once again hiring junior level developers, and the same dynamic was at work, but I got a surprising reaction from the person I spoke to. I’ll call her Zareen, who had just come through the Grace Hopper program.
Zareen had been interviewing at a few different places, but I assumed she was still open to hearing about the specific job that I was hiring for, so we arranged a phone call. We chatted for 15 minutes, and then I suggested she should come by the office and meet the whole team. She was just absolutely stunned.
"Wow, I didn't expect things to move this fast!" she exclaimed.
Let's think about that for a minute. She wants a job, I might want to hire her, I ask her to come by the office for an interview, and so she is stunned. It says a lot about how broken our hiring processes have become if what used to be the absolutely boring, dull, and standard process now provokes the response, "Wow, I didn't expect things to move this fast!"
Apparently other companies were giving her homework assignments and personality quizzes and phone interviews. “Please go to this website and take this test, we are trying to figure out what your skills are.”
At two other companies, she had already done 20 minute interviews, but never with anyone on the tech team. Instead she got a call from someone in the HR department, who read a checklist of words, which the HR person did not understand, but they were all requirements: “Have you ever heard of HTML? Do you know how to use that? What about CSS? Do you have that? How many years of skill do you have with CSS? And Java? I mean, Javascript? Are those different? Yes? Okay, I think we want Javascript. Do you have that? Yes? How many years?”
What an empty ritual; reading words that are not understood.