Hello fellow travelers, I'll do my best to keep this brief(ish).
I've been in IT professionally since Y2K, data entry->QA->SysAdmin->PM->consultant->founder->sold and with the money took some years off, bought some property and a fixer upper and went to school and got a BSBA degree (never graduated from high school but wanted to show my kids the importance of a degree). I missed working and creating things with people so decided to reenter the job market in the PM space. So now that my hat is in the ring I have been told by recruiters what I need to "expect" in this "new market."
I was told "5 to 7 interviews is normal". What? I genuinely feel like I'm having a 'Blast from the Past' moment in this whole thing (good 90s romcom kids, look it up).
When did a hiring manager lose their authority and the trust of the organization to do their job? Am I just out of touch? How is a process like this in any way shape or form efficient or productive? Am i missing something? HN, please help!
First: we no longer trust the hiring manager alone, because probably they aren't a strong developer. We instead trust strong developers that are well trained at evaluating good devs. At the same time, we don't want to thrust a dev onto a hiring manager, so they also need to interview you too and have a say.
Second: Is it really fair to have just one or two developers evaluate you? When I first was an interviewer, I liked everybody! I would have hired them all. So getting multiple data points matters. Best to have at least a couple dev interviews.
Then there's the whole problem of needing to evaluate you on multiple dimensions. Can one interview really tell if you're good problem solving, coding, algorithms/data structures, and any specialization the role has? What about the soft skills aspect? We're going to need to have at least 3 or 4 interviews to cover all these aspects. These roles pay a huge sum of money, so there's a lot of worry that someone will be hired who doesn't really meet the bar, you know?
But now we have a bigger problem: if we're going to invest 4+ people to spend an hour of time with you each, we'd better have some data points that you're worth that investment. So maybe we need one or two initial interviews ahead of time to weed out any obviously unlikely candidates.
After that, it's every other company going "Oh shit, Amazon does 6 interviews? We should do that too!".
Scaling any process to thousands of people is always hard.
Is it annoying for candidates? Yeah, but we pay you a lot of money, and it does actually work for us. Is it perfect? No, but it does work.
“Hire and Fire fast” doesn’t actually work well if you want to give people a chance to succeed. Also people tend to keep low performers around too long. Best to avoid this as much as possible.
The interview process asks a LOT of the interviewee and then does not provide anything that could help the person improve next time, so the entire process feels like a complete waste of time. In my case, I was also disrespected by the recruiter.
The next time they reached out, I failed the phone screen somehow by someone who sounded 20 years younger than me (which is frustrating when you have already passed these same steps before). I don't respond to Amazon recruiters anymore.
The truth is that nobody likes being interviewed. Getting tested and judged by strangers isn’t fun.
But developers also really don’t like being surrounded by unqualified developers who slipped through a weak interview process. They also don’t like having significant numbers of their teammates fired and replaced all the time because the company had “hire fast, fire fast” interview styles. It’s miserable and slightly terrifying to work at a company where nobody really wants to invest much time into building relationships with new hires because many of them are going to be PIPed out before the year is over.
So while the interviews may not be fun, the reality is that strong developers really appreciate the outcome of such a rigorous process. It also helps protect people from becoming false negatives because they didn’t mesh with a single interviewer or struggled with a single interview problem.
So now we’re at this weird equilibrium where devs simultaneously hate the interview process for themselves but appreciate it being applied to everyone around they (even if it’s not immediately obvious).
And then on the flip side - if you are really a star, and you are interviewing at a small company you should want 5-7 interviews to gauge the caliber of people you will work with.
In my opinion this is a big problem. I wish there was a stronger culture of letting low performers go quickly in tech. This would reduce the need for exhaustive interview loops and ultimately make the industry more inclusive because you could afford to take a chance on someone without being chained to them for years to come.
I had to go through 8 interviews for a senior position at Facebook and ended up not getting the offer. I wasn't paid a dime and had to use a few vacation days at the job I had at the time in order to take the interviews. Technically I lost money interviewing at FB.
Since you have a chance of getting cut at each round as an interviewee you are left hoping not to run into: some esoteric corner of programming you could learn in 10 minutes but haven't seen before; an interviewer who always asks a pet question (even if told not to do this); a personal dislike that is illegal but not challenged (age, gender, race, etc., waved away as "a bad fit").
If multiple interviews were used only to strengthen assumptions about a candidate and each interview had a narrow intent, they COULD help companies avoid more bad hires. But after interview #3 you are probably just filtering reasonable or even exceptional candidates based on random chance.
On the other hand, this may be a fantastic method to strengthen a "hive mind" culture, but that doesn't sound like a worthy goal.
I can guarantee that you will never see me in one of your interviews. Would I be valuable to your company? Maybe, but we will never know because the process is too long.
On the other hand, I struggle with impostor syndrome. While fairly successful in my day-to-day, I will likely fail whiteboarding sorting algorithms etc. Imagining a series of five interviews stresses me out and I’m not even looking right now :)
What makes you think that the process provides an accurate representation of the skills needed for the day to day job? In my experience it simply tests whether the candidate has invested lot of time cramming for that very specific type of test. If I was running a small company I would much rather discuss a candidate's experience with them and leave them the time to build useful skills, not worthless ones for passing a test.
The best candidates can get jobs paying the same or more money with fewer interviews, so the very best aren’t going to pick you.
I've never been paid for interviewing. You mean you pay the successful candidates well, which is what? 10% of the people you subject to this obnoxious process?
Well, no you don't. You pay a lot of money only the people you hired.
I had more than one interview, where the things I discovered during the interview made me reconsider my options and go for another company. Not because I wouldn't have fit with the team or my skills were not there, but because this kind of thing tells me how processes are organized or not organized within your company, how people treat each other etc.
What candidates does a hiring process like this drive away? Are it specific character traits that pass through the sieve? If yes, how will that shape your corp and the culture in it in the long term?
I just want to highlight that this works specifically because there are a very finite number of these we pay you a lot of money companies competing for talent and that's the primary reason candidates put up with this [expletive deleted] treatment. And the result are beneficial for these companies, yes.
In a previous company we pair interviewed, 1/2 hour screen + 2 one hour slots. I liked that format a little bit better.
I've been interviewing people for about 40 years now, I was just reflecting on my first ever interview that I participated in when I was still a teenager.
I would say there are some factors that are not going to come out in any number of interviews. Conversely there are factors that are immediately noticeable.
I can tell in 10-15 minutes how strong someone is technically. At least I can tell the difference between "weak", "maybe", "strong" in 10 minutes.
Going back to my first ever interview. The guy was brilliant. He was technically good. He ended up being a not so good hire for reasons that would have been very hard to discover during the interview. It was partly the intersection of very smart without the experience to match and partly that he was just weird in some other ways. He was hired, he left within a year or so.
I think the science says the best predictor is an IQ test. The rest of our practices are not really evidence based. We tend to want to hire people that are like us, that know the things we know, we have all sorts of biases during the interview process, and throwing more people/time at it doesn't really seem to make a big difference.
I would say the most important thing you can do to get good people is to make your company a place that good people want to be. I.e. what matters is more what enters the pipeline then the interview process. I would bet that having 7 interviews vs. 3 has a difference that's completely in the noise and that at least there's no solid evidence that it gets you anything re: the quality of people working in a company. Every company says it has the best people. Mostly channeling Joel Spolsky here but I've seen this principle in action.
EDIT: Another random thought is that there are other factors that influence whether someone is going to be successful in a given role. Even the best software engineer can fail if the conditions for him to be successful aren't there.
How do you know it works?
> I don’t want to hire the wrong person, it’s expensive and it makes my job awful for a while.
There we are. It is all about you.
No need to say anything else - your life is all about you, so of course if it works for you, 'it works'.
Dead Comment
This is a huge problem IMHO. I topped out at L7 on the FAANG EM track, but that’s dozens of ICs and a few EMs in your org and I still think you need to be able to build the software and review diffs and write serious ones now and again. Clearly this is now only part of your job, not the focus of it, but it’s very difficult to manage a process that you don’t understand with some sophistication.
In everything from law to management consulting to steel fabrication: the person in charge is the most knowledgeable person. Carmack is the best hacker, Mike Krieger wrote code. Hell pg wrote this site and the language it’s written in while building the most successful early-stage investment firm in the world.
Obviously directors and VPs and CEOs are delegating the details at same point, but this idea that an L6 manager shouldn’t need to seriously understand the subject matter seems wrong to me both in principle and based on watching it go to hell countless times.
If an L6 manager could keep all of the details of all of the things all their reports are working on organized, they aren't handling enough scope. Imo that's the difference between 5 and 6. You can no longer track all the details in one person's head.
I've had some good managers that could do that. But the people management skill set is so much more important to their job. And it's a very different skill set to being an IC.
I wouldn't argue in favour of engineering managers with no technical skills at all, but I also don't think it's fair to demand they be masters of both the IC skills and the people management skills too. It's very difficult to be good at both.
Maybe they should ask to implement a feature or fix a bug in some huge OSS project. That would evaluate skills relevant for a job in FAANG more closely imho.
I think there is also some kind of survivorship bias - you don't hear from the people who tried it and failed.
But it is for sure, a completely different skill from leetcode style stuff.
In the app code there should be one or two very obvious bugs and easy optimizations to make, and then put more subtle and challenging to fix issues there as well. And ideally make it something where a really sharp and experienced developer would identify some high-level architectural flaw and they would know how to rearchitect it.
Everyone knows that the leetcode-style questions are contrived and don't usually reflect real world work but we continue to do it anyways.
We showed them our website and asked how they'd investigate/troubleshoot a complaint that the site was "slow."
Then we kind of role-played the troubleshooting process. Ideally I wanted them to determine if the site was slow for everybody, vs. just the person that reported the issue. If it was only slow for a single person, was it their account, or many just their internet connection? How would they determine that? If we determined the issue was happening for everybody, how would you determine which part of the stack was slow? Etc.
To add more: a single person (HM) might have biases for or against certain candidates. More people in the loop brings in diversity and helps to keep interviewers honest and consistent.
Also these roles are usually high stakes and the cost of a bad hire is too high.
Really? High stakes? This fucking site.
Have you ever worked as a software developer at a corporation? Nothing about it is high stakes. You spend most of your time dealing with useless idiots who report to other useless idiots, who report to other useless idiots, about a useless product they think is a great idea that every non-idiot knows is useless garbage.
That's how you get Google not creating a single non garbage product over the past 15 years.
When they did Google Maps, did they have 7 interview processes? I bet you they didn't.
Here is how the real world works - 0.0001% create something, then 99.9999% turn it into what 99.9999% of people are. What that is - I leave to you as an exercise.
"Why do you think this person 'isnt a good culture fit'? Oh because the team you run are all 20-something male brogrammers and this candidate is a 38 year old woman with kids? Hey cool, that's illegal discrimination."
You obviously haven't worked in finance. Google is as far from high stakes as you can get.
That would be true for all organisations. You could do 6x more interviews if they were all a single round.
> Also these roles are usually high stakes and the cost of a bad hire is too high.
Hiring a brain surgeon is high stakes. I don’t know a lot of software positions where it is true.
Dead Comment
That said it was mainly because they said after several interviews oh you just have one more to go but then the next interview said you have one more to go and they would also say you will be hearing from us in a week but it turned out I heard from them in two weeks.
But in the end, actually, both jobs paid the same, but one of them seemed to me to value my time more.
Except FAANG interviews require excellence on almost all of the interviews, so the extra people only represent further opportunities to be denied.
Sounds to me like the format isn't worth keeping; time to hire more, and fire fast?
I can't even fathom in what ways you think "time to hire more, and fire fast?" is more "effective and equitable"? You just shove even more risk onto individuals who might be getting their footing still.
You're just turning a 8-9 hours commitment to an interview into a 6 month commitment. Sure, you get paid but you also have to deal with churn and burn.
I mean, did you think stack ranking was a good idea?
2. Hire more, fire fast sounds good on paper but will destroy morale as the team identity will be constantly influx.
3. Engineers will spend less time onboarding newer engineers to the detriment of everyone because well, they might not just last.
I’d also like to add that having multiple interviewers, if they have diverse backgrounds, is more likely to be equitable than a single interviewer.
I’d much rather not get hired then get fired “fast”.
Look what that did to their reputation and company culture.
Netflix is a little more successful at this, but they have a much smaller eng footprint and much higher compensation in order to attract and retain top performers.
The last company I worked at had 8 interviews, which I thought was a lot. My current company (about 100 people) had no less than 11 scheduled interviews!
Of those, only the first 2 were with people in my department — my manager first, then my manager and immediate coworkers. There was another group call with people in a related team I might conceivably be expected to liason with eventually. Fair enough.
The remaining 8 calls were with leadership in every other division in the company, most of which I would never work with. People with jobs where I don't even know what they do, and I'm sure they had no idea what I do. I just politely made conversation with them and answered their (very general) questions.
Now that I've worked there a while, I have never spoken with these people again, or worked in any way with the teams they oversee.
I've also participated in a few interviews at this company now, from the other end of the Zoom call, and I know how it works: literally every branch of the org chart gets a meeting for every interviewee, regardless of what they're applying for. Everyone has a chance to say "no", but in practice nobody outside the relevant teams is going to exercise that veto, because they are well aware that they are unqualified to judge the candidate's skills, and will never have to work with them anyway.
It's just a big waste of time for everyone involved.
(Also, nothing is as expensive to a dev as a manager with too much free time. Spending a little on HR may be a QoL improvement even if we never hire)
I am also exceptionally fond of being a silent party in an interview.
Nobody wants to walk into a room with four people who are all asking questions, but I can learn a lot about people just by watching their interactions. Indeed I learn more about secondary characteristics than the interviewer because they’re wrapped up in the answer, not side comments the candidate makes about development philosophy.
Additionally, it takes less investment in an interview to ride shotgun like this. So jumping from 1 to 2 is not twice as expensive, and it protects you from hiring decisions being made with only one employee having been privy to the conversation. Especially with all of the EEO concerns that come from he said she said situations like this.
Three is the most I would put in a room, and only if two are asking questions and the third only answers them.
But you can still easily get seven people in front of the candidate with only 3 sessions in this way.
No, I don't. Making the wrong hire is costly not because of the total annual compensation, but because of the upfront cost which is realized the moment the employee signs the offer letter.
All the admin stuff.
By your logic you shouldn't fire someone either (at least not that easily) and maybe that's why so many FAANG engineers end up "cruising" because the company is so scared of hiring new talent.
We decided to ignore this protocol and hired a senior lever manager from IBM. After the next two years, we had an IBM fiefdom. This person hired his IBM buddies, who hired their own IBM talent.
None of these people accepted our culture. It reflected in the organization’s output. Turns out, when you bring in people from these legacy companies where people seemingly coast by and don’t actually produce out, and you have little oversight on what they actually output, it just turns into an inefficient and ineffective mess.
This went on for a while until the entire org was gutted with over half the people fired.
And fixing a bad commit doesn't require 6 months of emotionally draining work.
Except that now of course the practice has been by companies offering roles that don't pay huge sums (and at the end of the day are more or less standard CRUD roles). For the reason you cite at the end of your post
I've been interviewing for a long time and I _still_ really like everybody. I want everyone to join and even if they're not a fit I want them to join and want us to spend time on bringing them up to speed and nurturing them. Of course I'm aware that an org isn't always able to do that.
[1] https://students-residents.aamc.org/applying-medical-school/...
Output of multiple interviewers are combined by AND'ing, so when any one interviewer has even the slightest hesitation, you are out. Because of this, more is not necessarily better
I don't live in the US but I think even different US companies has different needs. Our current problem is that it is very hard to find developers. A small or medium sized company may not get many candidates to interview, the problem then changes from finding the best in a large pool of candidates to finding anyone that can do the job. Scaring people off with 7 interviews would probably get us even fewer candidates.
Probably would have worked out just as well as the current system if not better.
Therein lies the problem. Doing things because someone bigger and better is doing it is not the right decision making process
So do roles in medicine, finance etc. Do they also go through 7 interviews grilling them about material from their bachelor's or asking random logic questions? Why don't we test doctors "problem solving" skills by asking them how many cars are in Manhattan, don't doctors need good problem solving skills?
Sorry, but if it can't, aren't you doing the interview wrong?
Tech companies have the lowest infrastructure costs of any industry, and so they have no place to hang their risk aversive paranoia except on personnel (the safer you are, the more trivial the things you fear).
There's nothing logical about it, but since they have to fear something, it'll be whatever some douchebag with a following puts in their next "XYZ considered harmful" blog post.
That, or we’ll have some representative from the big 5 saying “Hey guys, Jayden from (x soulless Silicon Valley company) here. Not speaking on behalf of my employer but actually at X Corp(tm) we’ve found that anything less than 37 interviews (+tip) isn’t enough to let the real stars shine through. We’re all about finding the true team players who are a good culture fit” within 2 minutes of the post going up.
I'll get cracking on it. It'll be my next hit after my last blog post about tech hiring "Hiring Developers: How to avoid the best" - https://www.getparthenon.com/blog/how-to-avoid-hiring-the-be...
So, we switched to "here's a short test, go in this room and do the test". Then we'd look at their answers. If the answers were wrong/poor we'd thank them for their time and excuse them. This way, less of our time was wasted. That test included an extremely small task like FizzBuzz. If you can't answer it you can't program, period! It filtered out the 9 out of 10 applicants who should never have applied in the first place and saved us a bunch of time.
At a big company the phone screen is supposed to do that but phone screens still take a hour or more of some engineer's time.
I remember about a dozen years ago taking one of these tests at an interview. Interviewer takes me to a room and says "We've got this little test, I'll be back in 2 hours.". I take the test. Guy comes back in and says ok, we'll look this over and let you know... Crickets. Didn't hear back so I figure I must've bombed the test. 2 years later that guy calls me up and asks if I want to come in for an interview. I say "I never heard back so I figured I bombed your test" He says "No, you did great, we just got kind of busy". I politely declined to interview with them again.
We would give them a quick screen of “write in one of the languages this position requires a program that takes in a string, reverses it and prints it out.” And we changed it to any language once we started working with novel stuff like JavaScript that any programmer could pick up.
It was so weird how many people would fail this test.
I always wondered how other industries dealt with people just flat out lying on resumes and applying for positions they shouldn’t. Programming is lucky that we have some litmus tests.
I feel bad for people who freeze up and can’t even write a three line program on paper.
I do generally agree with the cargo cult sentiment, but not in this case.
The main thing I dislike about the 7+ interviews is that I dislike interviews and there are 7 of them to get through. I once did four in one day, back to back, and I was extremely tired afterwards. So my big fear as a candidate is that either 7 interviews will happen over 1-2 days and I'll be absolutely fried after the first 2, or they'll be so hard to schedule it'll take 6 months just to have them all. I'm also a bit afraid they'll cargo cult some of the interview questions and I get a bit sick of "please recite 1st year CS algorithm" questions (I never ask these personally) but otherwise 7 interviews is fine, if they accept I am a human candidate and I'm not really comfortable in the process anyway.
It literally takes a few minutes and is great for weeding bad candidates. It is a win-win for everyone involved.
Now, everything sucks. People who only know the tech they trained for. Tools are written for idiots, and the only thing even more written for idiots than that is the code we're supposed to be producing. Teams believing whatever stupid fad some trendy consultant prepared for them. Way too much support staff when I used to be able to call the stakeholder up directly and square any issues, now I have to go through like 4 idiot nontechnical PMs.
One of my previous managers compared us to a basketball team. Ew ew ew ew ew ew EW!
Tech sucks now. Get the business and nontechnical people out! All they contribute is bloat and mediocrity. The only people who should be in charge are those that have been at this for life.
Similar stuff happened with other technology too. A couple people could build an early airplane but a modern jetliner is so tremendously complex that you need years and a full company to get one out the door.
Amazon literally has a research team focused in hiring, and they run A/B experiments to continually improve the process. The current interview format is not a cargo cult, is a high refine process through the years.
Is it perfect? hell no, but it isn't the mindless copycat people make it to be. They have actual data to back up what works and what doesn't, although it might take several years to happen (like when Google finally dropped brain teasers).
The median time an employee stays there is now under 2 years. Clearly Amazon isn't hiring the calibre of people they need.
Well it's been a while for me, but "we just do what the other guys do" was the impression I got when I interviewed there. Except they added a lot more "here's a terrible workplace situation, how would you handle it".
I'd love to know what their research is revealing, beyond questions like the latter case being emphasized.
Yeah, sure. We got all these smart people in a room. They can't be wrong. /s
I'd actually say the opposite. These researches are probably making hiring worse.
Resumes suck, take-homes suck, interviews suck, nepotism sucks; yet people still need to invest $x00,000 based on something. I don't have the answer, but let's not pretend it's not a hard question.
The straightforward, obvious answer of: maybe it makes more sense than you think has no appeal to it, but I think it's closer to the truth.
I'll let you answer for yourself if the answer had insight or appeal. Both tickle that novelty button, but only one has (elements) of truth.
I think it's time we accept that the person we are talking to is who they say they are on their resume. You don't see accountants balancing books before they get hired. Why should this be any different? If you aren't who you say you are, its either blatantly obvious in the interview or we'll find out when you join and we'll try to correct or part ways. This is like pretty much any other job out there.
You sure do, and not just by a hiring manager's whim, but by law. Accountants have occupational licensing.
> I think it's time we accept that the person we are talking to is who they say they are on their resume.
This is a straw man, I have never "caught a liar" on an a coding exam. What they are helpful for doing is judging the quality of what it means to be "proficient in [x]".
If there's anything I have learned from giving coding exams to candidates, it's that the ability of a candidate to verbally sell themselves in an interview has a weak correlation to their ability to produce quality work.
Forgive my ignorance, but is this during every interview? If I am reading this right this is a certification they'd need to get which would be on their resume. Do they need to re-prove those skills every time?
- HR call 30 min.
- Talk to hiring manager (me) 30 min. Get to know each other and feel out if there is a mutual fit.
- Technical panel 1hr. Speak with several engineers on the team who share your discipline (front end or back end for example). Again no live coding. We just talk through stuff.
- Talk to the team PM. 30 min. Get a sense of how you collaborate with our product team partners to build new features in our application.
After that it's the usual comp negotiations, background, and reference checks. Assuming all that works out then hired!
We're hiring so, if anyone is interested in finding out more, contact info is in my bio.
Once you get past the first screening call, I find you on social media, blogs, forums and read your posts, and see what questions you're asking on stackoverflow. Then we might move you to the next stage. All in all, you get a pre-screening from our recruiter (about 15 to 30 minutes), a screening call from a technical hiring manager (30 minutes), and then you talk three or four principal engineers (45 minutes each). This happens in days.
The only person that doesn't talk to you that is highly technical will be the recruiter. If you're hired and start work, we watch what you're doing, mentor as necessary. If you have the right attitude and are coachable, so long as you can string together coherent lines of code then everything else can be taught.
And what if my social media presence is minimal or not public?
Yea because we live in a place where everyone is super honest and no one is going to try and take advantage of that to make 500k a year.
IMO, it doesn't work. Talk is cheap.
I wouldn't have a job if I had to talk my way into any company, I'm an introvert, I suck at communicating orally. But I can solve problems and write really good code. You throw problems at me during an interview and I'll solve them. Ultimately your company's code is not going to write itself.
I would be THRILLED if I was put into some kind of a short probationary period, with limited access (and potentially restricted salary, with retroactive reimbursement) while I showed what I was worth. I personally have a hard time demonstrating that in short interviews, and it's only once I come in contact with the shape of the company's problems do I show my value. Imo it would lower the stress and paranoia on both sides over a candidate's fit.
You are right that there is more risk with this approach. I honestly think that its a better, more humane way to do things though. Anecdotally, I've hired a couple _really_ solid developers via this methodology. At least in my case, it's been working out well. As always, you try stuff and iterate.
> I'm an introvert, I suck at communicating orally.
I get it. So am I. Its actually very hard for me to reply to these comments b/c of my general aversion to putting myself out there! I don't think there's a one size fits all solution. At my company at least, being able to communicate effectively both orally and written, is important. We do a lot of pairing and documentation etc. Thats not for everyone. YMMV.
Lack of communication skills is a bug not a feature.
With respect, it sounds like you had a bad manager. Underperforming teammates are your managers responsibility. They should be working to address that issue with said teammate or part ways. Sucks. Not fun. It's the job though.
It is absolutely absurd some of the study plans that people go through where they are trying to study over multiple months. In order to truly memorize all the solutions, most people need these programs. Otherwise, it's just a luck of the draw. I actually got stuck at an interview because I forgot the nlogn solution for two sums. Absurd!
My favorite interview so far involved opening a raw TCP socket to Postgres and sending a query (Actually relevant to the job). I was given the prompt ahead of the interview and spent about 2 hours figuring it out. I learned something valuable and demonstrated an ability to expand my knowledge base. This interview has been the only one even remotely close to demonstrating my abilities to work at the job.
I literally copied the questions verbatim into a search and found the solution to all 3 all over GitHub in multiple languages. How is this an appropriate evaluation? Certainly a candidate could simply copy the answer in their chosen language, tweak the structure a bit and call it their answer.
I contacted their recruiter and told them I was no longer interested in interviewing. I told them I couldn't take them seriously since all they did to invest in the interview process was to steal questions from other hiring managers.
If a company wants an efficient, honest and quality interview process it needs to go both ways.
So what?
Let's say you know nothing and just copy somebody else's code. Good for you. The next step in the interview process is that you have to do a code walkthrough explaining what you did and why. Do you really think someone can get past this stage with a code they just copied from github?
I can even imagine that someone finds this existing code, and then they copy it, then they improve upon it, and present it as such. If they are open about it, I'd have no problems from the interviewing side. In fact, it could even be better, because the more complex the code is, the easier it is to talk about it (and gather information about the candidate).
For me it's the complete opposite. What I would consider demeaning is to spend 30 hours across two weeks interviewing for just one company while they don't even bother to send more than one interviewer.
I love these take homes with discussions/presentations but companies keep insisting on the zoom coding over google docs route.
The reality is this profession isn't that hard, and majority of people working in it are pretty much just plumbers using the innovations of true computer scientists.
We've managed to created a much more inefficient gatekeeping mechanism than just creating a proper certification process and commended ourselves for it and pretend it's somehow more meritocratic than just getting a comp sci/eng degree and license.
Furthermore, evaluating anything other than "Do you want to work with this person?" (on a scale of "I'll quit if you hire them" to "I'll quit if you don't hire them") is a waste of time.
But, as you see, people absolutely adore wasting their time and yours, as if no one has anything better to do.
Hire people that your people want to work with. Put them to work and see how it goes. Let go of people that didn't work out. There is no further secret sauce for hiring in nearly every ordinary circumstance.
IMO.
A proxy for that kind of tolerance is whether the candidate will jump through an inordinate number of hoops while being hazed by future coworkers.
If I ever got into a situation where I was hiring, it would start with a 2 hour conversation. No coding questions. I want to get to know you and also talk shop about applicable technologies.
Then after that is simple. I would hire you to do 5-30 hours of contract work where we pair program on real life things. The interviewer would do the driving to eliminate large amounts of ramp up time. This could be anything from R&D to implementing something real that'll ship to production. This would be paid work of course and the schedule would be based on the interviewee's availability, hopefully at least a few hours a day. The duration depends on how well of a match they are, a better match would have more hours just to filter things over a longer sample size.
The person pairing with them (a currently employed dev / tech lead / CTO, etc.) would be doing this work anyways so it's not a time sink, as opposed to them stopping their "real" work to do 5 technical interviews.
I'm guessing this would give both a good assessment of how the interviewee thinks through problems and you can get a good sense of where they're at technically. Also you get to see how well you mesh together from a "do I want to work with this person every day?" standpoint. It's also super low risk for the company because you don't need to go through the entire costly hiring process up front. It also lets the person interviewing for the job get a better sense of what it'll be like to really work there.
It's a win / win. Why isn't this more popular?
You say this as if most (or any) candidates could do this.
If you currently have a job, then you almost certainly won't have time for this, unless you're single with no hobbies. If you do have time, you may not be allowed to moonlight under your current employment contract.
And if you don't have a job, you _still_ may not have the time or desire to do this!
I'm currently jobless (by choice - I wanted a break) and I started interviewing a few weeks ago. It's exhausting! Even if I could squeeze in 30 hours of work over a couple of weeks, I wouldn't want to. I had 11.5 hours of interviews this past week, and now you want me to spend another 10-15 hours pair programming with you? Absolutely not.
If you spread those hours out over many weeks (6 weeks at 5 hours per week) the candidate will be done with the process everywhere else much sooner and they'll just accept an offer before this process finishes.
If you want a trial period, make an offer and have a 3-month probation period during which you will give the new hire regular feedback (at least once a month but more often is better). Doesn't every company do this already, at least implicitly?
You have to understand that, as an employer in the current market, you do not really hold any of the cards if you want to hire talented developers.
It's not a win/win. Nobody with options is going to accept multiple weeks of limbo in exchange for maybe having a job.
Let's say it does take 2 weeks to do 20 hours (2 hours a day), you would be compensated $4,000 for working 2 hours a day. Or if you're in between jobs you would have the time to do 20-30 hours in about 1 week and get paid $200 / hour.
I guess I'm just picky. I did freelance work for ~20 years and worked on 1 contract very part time for 2 years before deciding I wanted to try something new and work there full time. There was no interview process, I just signed a document and that was it.
I couldn't ever in a million years think about joining up at a place based on a few short interviews where 90% of the time is answering their interview questions. As someone who would be hired I really care about what I would be doing most days and what it's like to work there. Of course salary, benefits, TC, etc. is all important too but those are only numbers in the end.
I think this short contracting approach looks out more so for the interviewee. This "talented developer" can now pick and choose based on really knowing what it'll be like instead of hoping it's decent based on a couple of interviews.
I would have thought a highly talented person isn't concerned about jumping between interviews, getting hired, quitting after 3 weeks because it's not a good fit and repeating the process until they find a good match. Am I just way off base here? Do most folks bounce between jobs every few weeks (going through 5-7 interviews per job) until they find something they like?
I have successfully used this hiring method. To say "nobody with options would do this" is patently false. In fact, it can be a great way to get in with people who have a LOT of options, but they aren't sure they want to work for YOU.
Every single time I've used this hiring method, I've gotten some of the best developers I've known. They weren't even looking for a job at the time. They just wanted to hustle a few extra hours to make some play money. I'd give them as much work as they wanted. Some of them stuck to just a few hours a week. Some decided they liked the project enough they wanted to do more.
However, this is exactly what I did to hire the first few employees of my startup, because those initial hires are really critical. I was willing to limit my choices and take more time in order to avoid false positives. Also, that was ten years ago in a somewhat less crazy job market.
If it's clearly not a good fit then this wouldn't be offered. If you are doubting then this could be a good way to make a decision with the most information you could possibly have, low risk for the company, the applicant gets paid when they might otherwise be between jobs... there are the caveats mentioned in sibling threads, but in some cases, yeah I can see this being a good idea.
We recently rejected someone and I still think that was the right decision, but there is still a chance it wasn't. I wouldn't have minded giving them some contract work to find out if they were competent and just terrible at showing it in an interview. I didn't realise this was even an option. Though in this case it probably wouldn't have worked out due to them currently having a job.
It would work for people without a job or contractors, but in the latter case, they probably are looking for contract work not W2 employment, so you’d be better off with contract-to-hire.
Works great for students or people unemployed or just graduated, not so much for older people with e.g. a family.
So they have to be unemployed while interviewing with you? Companies these day seem to be completely oblivious to the candidate already having a job but it's usually the case.
Other than that it doesn't sound bad, but it's kind of a big problem.
If you're doing 5-7 normal interviews that could end up being 5-15 hours worth of interviews. The time issue is shared with both styles of interviews.
I know I said 5-30 for contracting but at this point if you're doing 15 hours of normal interviews it's not really much different to do 20 or 30 hours of contract interviews. It's just a longer process, which IMO is beneficial because you (as the person being interviewed) get to see a better picture of what it's like there. Plus this 30 hours isn't set in stone, maybe after 5 or 10 hours you find out you're a perfect match and now it's the same time as standard interviews except you've gotten paid for it too.
The differentiation between good and great doesn’t come into play on the average workday.
I don't disagree that 30 hours is way over the top for an interview question unless you happen to find it as much fun as <insert your favorite hobby>, or if it's somehow usefully spent time for other reasons, but your response seems to be at an equally extreme end of the spectrum.
The alternative isn't much better. The current standard interview process leaves your employees going behind your back to interview for jobs with better compensation and the moment one of those offers materializes they put in their 2 weeks notice without blinking an eye.