by nsainsbury on 4/10/20, 1:13 AM with 576 comments
by jackcosgrove on 4/10/20, 2:19 AM
You can be a nobody without connections or degrees and if you can prove you have skills during an interview process you may be hired.
Contrast this with other hiring processes which are more irrational, like med residency match, investment banks favoring "target school graduates", law firms favoring "top 14 graduates", etc.
I think whiteboarding is dumb and I'm increasingly unwilling to go through with it. That's a hurdle.
But in many careers the hiring processes are walls, as in there is 0% chance you'll get hired. Because you don't know someone, because you didn't go to the right school. The barriers have little correlation with ability to do the job, and more importantly after some milestone has been crossed it's impossible for you to improve your chances.
by asn0 on 4/10/20, 3:44 AM
So we added an option to interview by way of a paid trial period (work part-time nights/weekends for a few weeks with the hiring team). Figured maybe some people might prefer that, but probably wouldn't be feasible for most.
Every candidate since has chosen that route, with very good outcomes - so far, everyone who did well in the trial period has been a good hire. Some of our best hires did not interview well (and would not have been hired under our old process), but were outstanding in the trial period. And, a couple candidates interviewed so well we almost skipped the trial period, but they struggled to complete even simple tasks during the trial.
We've now optimized interviews for that process, where the decision is primarily about whether it's worth moving to a trial period. That usually only takes a short screening call and a 1-hour call with the team (we're a remote team, even before quarantines).
BTW, if you'd like to experience this first-hand, we're hiring - https://news.ycombinator.com/item?id=22753515
by dahart on 4/10/20, 2:37 AM
This seems to be a pretty popular opinion. It totally might be right, but it’s not my own experience, so I have a serious question because maybe I don’t know what’s happening out there with most hiring today - what are the broad-stroke outcomes that demonstrate that hiring isn’t working? Are there statistics that show that hiring has problems? All of the reasons given in the article are claims without evidence, nor objective comparison to hiring for other industries. When looking for jobs, I’ve never been evaluated on IQ or code alone, it has always come with communication and personality and culture fit evaluations, among many other things. When hiring, my own team does everything this article claims isn’t being done. So I might be completely unaware of the major trends out there... how can I see those trends from where I sit? Are people not getting jobs who should, has there been high unemployment? Are companies not able to hire people? If hiring is broken, what are the problems it’s causing?
> It's a disguised IQ test
It is amusing to me that many blog posts and comments around here argue for exactly that under the same banner ‘hiring is broken’. Lots of developers are frustrated about being evaluated by how well they communicate and not by their code. Lots of people here complain about in-person interviews and tests and argue that take-home coding should be the norm, or that coding tests should not used at all.
by Drecula on 4/10/20, 3:10 PM
by analog31 on 4/10/20, 2:15 AM
I have to say we do really darn well, especially given we're located in the Midwest and supposedly the brightest programmers have fled to the hot markets. One thing I like is that we get a range of ages, which is heartwarming given that I'm over 50 myself.
The thing to do is look around at your colleagues and ask if the hiring process is really broken. It may be that we've all been driven into a panic about hiring, by the hiring industry.
by sumanthvepa on 4/10/20, 1:55 AM
by theelous3 on 4/10/20, 10:20 AM
I'm not the worlds most experienced dev who's shipped multiple products, but for a relatively inexperienced (2y professional, 5y total), I feel I am overlooked for positions I would excel in because I am just plain bad at technical interviews.
I have a fairly impressive github, a creative cv and recruitment page, and a bunch of nice addons that show how much I care about programming both technically and socially. I have probably the best possible background for remote positions in particular. I get interviewed a lot because of all this, and then facepalm my way out during technical interviews.
I'm the kind of dev that can eventually solve pretty much any leetcode-y type problem, but it takes me a long time of sitting in silence and playfully experimenting with a repl or similar. This translates extremely poorly to interviews.
I have also noticed that my brain will just disconnect midway through interviews and I will fail something that under ordinary circumstances I would never miss.
A combination of my style of thinking mapping poorly to the interview format, and stage fright, means that my odds are poor; even against candidates who would be both technically and personably worse fits.
Not really sure how to tackle this :)
by renewiltord on 4/10/20, 2:25 AM
That's the thing, though. If you make a reputation as the kind of guy who can near 100% spot the good engineers, you will make boatloads of money. An employer will pay you more than $30k if you only do great hires. You do 10 of them with your conversation out to lunch and you've made $300k. That's the low-end.
But no one can do that and the few with high hit-rates act as executive-search agencies where they make a lot more.
But I think I would never interview anyone I've worked with. That just seems like a waste. I already either know that they can or can't do things.
by ransom1538 on 4/10/20, 2:54 AM
by unexaminedlife on 4/10/20, 1:49 PM
I decided to take a different route. Take the decent-paying, but average job at an average-ish company, which will require immersive experience in all aspects of running a web infrastructure.
The reason for this, I didn't see "getting a job at Google" as the pinnacle for me and my achievements. I saw "creating my own successful company" as the end goal.
Sooo many benefits to this I think. You'll get the IMPORTANT experiences and knowledge, which will benefit you regardless of whether you are able to achieve the end goal of creating a successful business. The ceiling in terms of compensation is SOOO much higher. And in this scenario you're ALWAYS doing the most important things. In my experience working for large corporations you will typically be doing things that are far less important and in most cases your job will not push your limits. You will be a cog in a wheel using maybe 20% of your capacity to do amazing things.
Worst case you go back to doing what you love making a decent living. Best case you far exceed anything any of the FAANG companies could ever offer you.
by mattbillenstein on 4/10/20, 1:56 AM
I think the biggest problem is actually whiteboard coding problems - nobody does that in real life.
by ChicagoDave on 4/10/20, 7:14 AM
I could care less about data structures and graphs. Do they care about code and can they learn and can they communicate. That’s what matters.
by 11thEarlOfMar on 4/10/20, 3:07 PM
1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with
2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much time in days as they need, and let us know when you're done. The candidate then comes back and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not do criticize their style and approach.
3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization.
This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.
by gregrata on 4/10/20, 3:17 AM
https://www.amazon.com/Whiteboard-better-hire-best-developer...
I've interviewed and hired a lot of people over the years, and have been interviewed a fair amount. The way a lot of companies do it didn't make sense to me, so 5+ years ago I decided to figure out a better way to do it.
My basic premise in the book is that in an interview when asking someone to show skill, it should be as close as possible to what the job is. Most interviews are just not anything like a whiteboard interview or algorithm question. I get that can show how someone thinks, how they ask questions, etc. - but to be honest I rather have them actually DO something as they would do if I hire them.
I've had a lot of luck with this way of interviewing. The reality is it can still be a crapshoot - you really don't know what someone is going to be like until you work with them for a while - but this at least gets closer to making a more informed decision ('cause you basically work with someone, in a small way!)
by wrnr on 4/10/20, 3:11 AM
There are too many smart people in this industry who won't/can't code but act as gatekeeper to valuable problems. My advice is to search out these problems yourself, its a much more challenging problem then any programming.
Or spend two weeks preparing for your technical interview to learn stuff you won't ever use again and then do the bitch work of someones over-engineered vanity project while the plebs are doing "research", "marketing", "design", and "business development".
by quezzle on 4/10/20, 2:17 AM
To be fair they said don’t put more than 2 to 4 hours in. However I’m not someone who can fail to meet the requirements so I spent 8 hours building it to meet the requirements exactly.
Heard nothing at all back.
Silence.
by ddrt on 4/10/20, 5:19 AM
So I did, they made fun of my suit, they grilled me and then acted like I was unsure of the job roles... however I’d gone over them many times in the listing, prepared, and had three successful interviews. The person I originally interviewed was there, I have him an odd look, he gave me an “I’m sorry” shrug. And I left, perplexed. I was polite and professional the entire time.
Then they called again, now the CEO wants to meet me face to face. So I did, the other person who was his partner didn’t show up until 40 minutes later. I was having a great time with the CEO and asked him a lot about how he built the company, what the future looked like, and what Em he enjoyed most about the culture. I was getting into my work and history when the second individual showed up. He arrived, interrupted the story unintroduced, made fun of my suit, looked at his watch, and gave me an annoying look.
I started from the beginning as requested, I got a sentence in and he nudged the CEO and said “were late”. And that was that.
While they were walking away he made fun of my suit again.
by papeda on 4/10/20, 2:31 AM
by pdimitar on 4/10/20, 5:26 AM
Several times in my life I've had the strange luck of being told the internal workings of a decision after I was rejected for a job. Usually somebody from the interviewers liked me but couldn't convince the others, and subsequently decides to find me on LinkedIn and send me a direct message.
The messages have been eerily similar and are usually like this:
"Hey Dimi, I want you to know that I think you would be a perfect senior dev for our team. But the other guys said you were awkward part of the time, you didn't feel like you'll fit with the rest of us, and one of them heavily emphasised that you hesitated before answering one question very specific for our work... and when I pressed them to elaborate further they just angrily told me that I don't get it.
I wish you luck in your future searches but you should know that if it were up to me you'd be working with us now."
You can lose your balance for a minute while being evaluated live by several people? You can hesitate before answering a trick question about a niche project? Imagine that.
It's really bittersweet to get these internal insights and can make you want to pull your hair out -- but it did give me the perspective that most of the people charged with hiring go by a gut feeling and personal sympathy.
by thaumasiotes on 4/10/20, 1:59 AM
> What's crazy is most people hiring will even throw away your ability to learn and adapt!
These conflict. At the very least, the second quote illustrates that the hiring people are not aware that the interview is meant to be a disguised IQ test.
by Drecula on 4/10/20, 3:28 PM
by johnmarcus on 4/10/20, 2:25 AM
by doorty on 4/10/20, 3:48 AM
by ccleve on 4/10/20, 4:05 AM
This is a joke, but uncomfortably close to the way junior people interview:
https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...
by louiskottmann on 4/10/20, 8:40 AM
I recruit for my company, and we don't do that, in fact we do quite the opposite. But I'm pretty sure that's how big companies see it.
by DeathArrow on 4/10/20, 5:29 AM
I am not saying that developers should be autistic and completely ignore anything that is not code related but it can be done. Google failed but others succeeded, see Adobe or Ubisoft.
I certainly like to code and like technical intricacies but I always looked to code from an entrepreneur pov: always trying to work on something which will be useful for someone and ask myself what feature is going to be useful, to how many people and in what way. I did my share of "inverting binary trees" but that was when I was a student and needed to learn. I always tryed though to use such a technique to solve a real issue.
Maybe CS programs at universities should start teaching not only CS and programming courses but also concepts about thinking products, understanding user needs, assessing user needs.
Architects are trained not only on visual and technical aspects of planning buildings but also on understanding user needs and making the building useful for a particular customer. It's useless if a house looks good, uses clever technical solutions but no one is wanting to live in it.
by screye on 4/10/20, 3:40 AM
It could not be more clear to me and their conclusion only makes me more sure of it
We need to throw away this idea that you can get the measure of a person just by subjecting them to a faux-IQ test.
We need to fully internalize that being a great software developer is holistic and draws on abilities ranging from, yes, technical skill, but also empathy, experience, taste, grit, perseverance, and independence.
Being a great software developer is multi-disciplinary and we need to actively and vigorously reject the notion that just being good at "cutting code" and inverting a binary tree is the end of the story
and is therefore the only axis on which to assess people who work in teams and build products for other human beings.
This is not a problem in the system. This is a problem of scale.
by peterwwillis on 4/10/20, 2:53 AM
I generally ask few technical questions because I'm mostly interested in everything other than your technical knowledge. I can find 50 people who have taken a coding bootcamp and memorized an entire language's inner workings. And I can usually quickly determine how deep your technical knowledge is by throwing stupidly specific questions at you. But I won't know whether you can apply that knowledge in a way that will gel with the team and the requirements of the role.
Which is why most quality candidates come from personal referrals. If you want to get a good job, develop good working relationships.
by OliverJones on 4/10/20, 3:08 AM
2. If you claim SQL: Explain LEFT JOIN ... IS NULL pattern. Do you know about little bobby tables (injection exploit).
3. "How does the internet work?"
4. "Tell me about a hard / interesting / instructive bug you had to handle.
5. What would you do differently if you were the lord high poobah on your last job?
6. Tell me about something you helped finish and ship to users.
7. What do you have to say about OUR product?
Those questions have helped me hire some great people. They apply to anybody from a fresh-out to a self-taught to famous programmers.
You CAN shove into their face some strange line of code that depends on arcana of operator precedence. But the only useful answer there is "I would never write something so obscure."
by bfrog on 4/10/20, 2:05 AM
by erdos4d on 4/10/20, 2:45 AM
by illuminati1911 on 4/10/20, 2:45 AM
Interviews I have attended might have included something like that, but it's usually 1-5%. Most of the interview is talking about my previous experience, "how would you design a system xyz", homework tasks, "Take a look at this piece of source code for 15mins and tell me what's good and bad about it" etc.
by cryptica on 4/10/20, 1:51 PM
Unfortunately it's too late to fix that problem now. If a top value-creating developer was hired by one of these companies today, their approach and thinking style would be fundamentally incompatible with most of the other people who work in the company today (due to the legacy of bad hiring). Moreover, their boss would probably be one of those textbook and process-oriented people who is completely detached from actual value creation; working under such people is deeply depressing for value creators who have developed a laser-focus "eye on the prize" and "simplest is best" mentality from years working in harsh startup environments.
I would argue that the "simplest is best" mindset is good at any scale but the corporate hiring process has systematically weeded those people out.
That's why corporate monopolies are harmful for society, some entrepreneurial people just can't fit in at the bottom of large corporate hierarchies but yet they are often left without any alternatives.
by tictoc on 4/10/20, 2:14 AM
by smilekzs on 4/10/20, 8:53 PM
It so turns out that simple technical problems that requires coding, in conjunction with active spotting for deal-breaking red-flags, can be calibrated well to achieve both fairness and desired selectivity. I can't think of anything else that can so conveniently satisfy the rather essential conditions above. Of course the devil is in the details... which lies mostly in the kind of technical problem you ask.
Personally I prefer handing out distilled real problems encountered at work, with a hint of realism, no dependency on know-how other than a solid understanding of CS fundamental, and reduced to be self-contained. Think of the "kinda smart" bits sprinkled across your codebase. This of course requires careful design and calibration, and risks spoilers online, but it's been consistently working well. Personal anecdote though so YMMV.
by ben7799 on 4/10/20, 1:36 PM
I've interviewed more people in the last year than any previous year of my career. We found numerous candidates cheating on online coding tests. Weak candidates that fall flat on their face when asked to do something super simple like a FizzBuzz problem list massive accomplishments on their resumes. Often it seems like they are listing everything the team they worked on accomplished, not what they accomplished.
And the weak candidates frequently list things like "Expert at Spring Framework" or "Expert at J2EE". To be an expert on those things is very rare since they are enormous frameworks. Not many strong candidates will list themselves as experts on giant projects unless they were one of the founders of the project.
He is talking about filtering out developers with good technical skills who have other aspects of their personality/behavior that don't mesh with his business. But the bigger problem seems to be finding people who actually have real technical skills. The things he's worrying about are easier for management to correct/control.
by sultanofswing on 4/10/20, 2:56 AM
This topic is trite. Furthermore no one seems to be able to offer up actual tangible suggestions as to how to fix this, or some objective 'better way'.
Disclaimer I work at a FAANG etc company: Also this has been distinctly "not" my experience at many FAANG type companies. Usually these interviews, even the one's I haven't done well in, have been highly conversational, and all contain a fairly in depth 'soft skills' interview as well.
Yes, your technical knowledge has to be good, but a good interview will keep pressing at the edge of your knowledge (not to make you 'fail'), but to see how you handle the unknown.
In fact for one of the companies I ended up working at I was called in for a second soft skills interview just to dig even deeper on the dimension the author claims is 'never tested for'.
Much like these authors I don't have a perfect solution to this, however I will say one of the most rewarding interviews I've ever done (at a well funded startup where I did NOT get the offer was comprised of):
- 1 Algo question (standard fare)
- 1 Architecture question (standard fare)
- 1 'find a bug in this mock part of the codebase / pair program with me' question. Implementation didn't necessarily have to be perfect, mostly was interested in diagnosing the actual problem and talking about 'how' we might solve it (very fun)
- 1 Product Sense (!) question with actual PMs (very fun)
- 1 General culture fit / experience interview
by deedubaya on 4/10/20, 3:18 AM
by hlmencken on 4/11/20, 12:08 AM
by starpilot on 4/10/20, 3:53 AM
by kcorey on 4/11/20, 8:12 AM
That's the good news.
The bad news is that tech interviews in the UK tend toward the same faux-IQ test mentality.
When are recruiters going to realise that just because you can reduce a person to a HackerRank score, that doesn't inform a good hiring decision?
I've often said the only way to see how someone is going to work out in an office is to hire them and let them work for a month on probation. After a month, if they've demonstrated an ability to talk, to collaborate, and to learn, then keep 'em. If not, cut 'em loose.
everything else in tech hiring is B.S. I have yet to see an alternative that can't be gamed, that takes in the holistic person.
And none of my jobs have really brought out the best in me. In jobs I've done well, I drove that myself. In jobs I didn't, it usually came down to bad communication (in both directions). Nothing to do with the recruitment at all.
by badrabbit on 4/10/20, 5:48 AM
by dfilppi on 4/10/20, 3:02 PM
by p0nce on 4/10/20, 5:39 AM
But one of the biggest reason to apply somewhere as a developer is precisely to get to know a problem domain. Money is not the only incentive, by far.
by austincheney on 4/10/20, 3:30 PM
https://news.ycombinator.com/item?id=22821318
I post a similar comment in this thread and it gets downvoted to user flagged:
https://news.ycombinator.com/item?id=22831474
Perhaps the largest handicap in developer hiring is bias as evident by the stark contrast in response to these two comments that convey identical sentiments about the same subject with slightly different language and yet receive opposite response.
A company is a absolutely not objective in their candidate selection if developers are the deciding factor in the hiring of other developers.
by 12yrprogrammer on 4/10/20, 3:03 AM
Maybe I'm asking for too much money? 90k/yr.
I want to switch from Engineering(120k/yr) to programming, but I've been unable.
SE Michigan.
by helen___keller on 4/10/20, 2:08 PM
Maybe a workplace wants someone who will conform to corporate culture and cheerlead for the company. Maybe a workplace wants someone who will learn a big stack of internal tools quickly. Maybe a workplace wants someone who will grind out intense hours without complaint. Maybe a workplace wants someone who isn't going to "waste time" paying technical debt and instead just ship an MVP as soon as possible. Maybe a workplace wants someone who learns new skills on their free time tries to incorporate them at work.
Workplaces don't identify or admit what they really want out of a candidate. And they certainly don't have a way for testing against it in interview.
Top tier (read: cash-flush) companies have settled for hiring strategies that effectively select for "yuppies" (I dont mean this in a derogatory way) who are willing to bust their ass and do whatever it takes to overcome any obstacle they are given. This mentality is common among top schools that are already intensely selective and competitive. People with this mentality are much more likely to spend hundreds of hours prepping for tests, such as the leetcode meta today.
Ultimately, while it's very annoying during a job search, I'm thankful for the fucked state of hiring because it means software engineers aren't commoditized.
If we were indistinguishable cogs, and any engineer with N years experience can be replaced by any other engineer with N years experience, that kind of dynamic ultimately results in a strong downward pressure on employee's power and wage. We are closer to a talent dynamic where every engineer is unique and some are much better hires than others. You wouldn't hire an actor just based on their resume. Knowing how many years they've acted or in how many roles isn't enough, you need an audition.
Software engineering is halfway between these extremes, and we should be thankful that we aren't (yet) indistinguishable cogs in the corporate machine.
by master_yoda_1 on 4/10/20, 1:57 PM
by wffurr on 4/12/20, 12:31 AM
Funny, an IQ test has one of the best correlations with job performance among all hiring methods; one of the few to do better than random chance.
>> Does this person have incredible grit and perseverance? Who cares! Does this person communicate and write well? Who cares! How friendly and amicable is this person? Who cares!
I specifically evaluate all of those things and write them up in the report after a technical interview. I don't know where this person is interviewing, but all of these do matter.
But it doesn't matter how friendly you are if you can't also demonstrate problem solving and coding ability.
Also, what a disaster these threads always are. Depressing.
by thomk on 4/10/20, 9:52 AM
ROUND 1 THE INTERVIEW
Step 1: Interview candidates for 'culture fit'. Chat on the phone, get to know the person a bit, ask questions about what they did before. See if they have a sense of humor, get them to relax. Don't try to trick them, just have a chat.
Step 2: Ask a few 'how do you think questions'. Why are manhole covers round? How many school busses are in New York City, etc. These are questions with no clear answer and missing input data (like real life). Listen to how they work out problems in their head. Then ask fuzzy questions with no clear answer, and relatively high consequences for rightness or wrongness. See how they deal with that. Ask workplace conflict questions and irate coworker questions, see how they respond. Give them all the time they need.
Step 3: At the end of the interview, send them some take home code projects without a time limit. Give them some toy software program and ask them to fix a few reported bugs in it. Then give them a small greenfield project and see how they structure and document their code.
ROUND 2: THE DATING PERIOD
If all of the above goes well; hire them on a 1 month trial basis and see how everyone works together. Maybe they don't like your company? Maybe they smell funny? Maybe you force everyone to do yoga? Maybe they MUST travel with their service chimpanzee? Who knows? Spend a month working together and find out. If either of you see a red flag; shake hands and go your separate ways.
- - -
My point is this; putting someone through a gauntlet of stressful, random interview questions and whiteboard coding issues makes people stressed and nervous so they do not act like themselves. If the job is a high stress job and it's important to handle a lot of stress; you'll see that during the dating period.
Imagine having to decide if you were going to marry someone based on a few hours of conversation and 'whiteboard coding problems'. It's too much of a commitment with too little information.
Hire people, not machines.
by joelbluminator on 4/10/20, 8:34 AM
by ggggtez on 4/10/20, 4:50 PM
> no data in the article to back up claims
Yet another person who claims that hiring is broken. If this is the case, then show me the company that is not using technical interviews, and demonstrate to me that all these other companies are failing to hiring the best people for the job.
The closest they get to evidence of their claim is that Google didn't hire 1 random guy 4 years ago. Oh, and that Google built Stadia (??? huh ???).
Did I just read an anti-Google blogpost disguised as an anti-interview blogpost? What does Stadia have to do with interviews?
by ojr on 4/10/20, 3:58 AM
by jorblumesea on 4/10/20, 2:08 AM
Whether you agree with the IQ test or not, it's not even a level playing field or merit based. It's about an elite club keeping things elite.
Half the engineers working for FB, Google etc would not get hired today. Yet they still ask questions that they would not be able to answer as a form of gate keeping.
by resume384 on 4/10/20, 8:55 AM
by danielscrubs on 4/11/20, 6:12 AM
We (me included) protect our egos like our lives depend on it. Very few people have the balls to just admit the interview went terrible because of themselves, it's always the person on the other sides (interviewer OR interviewee) fault.
by KingOfCoders on 4/10/20, 5:53 AM
by jppope on 4/10/20, 3:57 AM
It works remarkably well if you're flexible enough to follow it.
by chronofar on 4/10/20, 1:54 PM
by alkibiades on 4/10/20, 6:47 AM
1. if i got an offer from your company a year ago, why do i need to redo the phone screen and entire process?
2. if someone has 10 years of experience at google and is L6, why do they need to do the standard process to work at some rinky startup?
by ausjke on 4/10/20, 2:16 AM
by loup-vaillant on 4/10/20, 10:12 AM
Perhaps that's because programmer is not a white collar profession? Those who don't manage other programmers are naturally at the bottom of the hierarchy, just like a machinist (clearly a blue collar profession, though I would certainly show proper deference to them before I even dare approach a machine).
Never mind how useful, or how skilled, people at the bottom are. They're at the bottom, and that alone probably affects how they are treated. The hiring process is just an effect of this.
by globular-toast on 4/10/20, 7:42 AM
No. It also tests knowledge and familiarity with whatever technology is required. But yes, of course it tests IQ. What else is important? The way you look? The way you speak? Your background? I don't care about any of that. If you can express yourself in a technical context then you automatically satisfy all other requirements.
I like technical interviews. They remove bias. It means someone isn't going to get the job just because I "like" them or, worse, I want to fornicate with them. I've hired people of all ages, races, and other "identities" thanks to the technical interview.
by netjiro on 4/10/20, 12:07 PM
- Ask the existing team for a set of dude recommendations, and the reasons.
- Track down a set of dudes myself. Usually from publications, open source, or previous products.
- Discuss with the dudes regarding the greater project target, team, goals, initial tasks, scheduling. Ask the dudes for other dudes they can recommend, and why.
- From here on I pay the dudes for their time and effort during recruitment, always:
- Have the dudes look at previous problems and solutions, if available, and ask for feedback.
- Have the dudes spend time with existing team on current work and ideas. When populating entire teams I have dudes work with each other. I especially look for people who are freely sharing even with people they are (technically) in competition with.
- I always followup on my initial predictions over time, to see where I'm right or wrong, and what to look for in the future.
I often hire scientists or other people who do a lot of work out in the open. It's just so much easier to quickly get a feel for peoples' output by looking at, and discussing, previous work. And most of my projects require bleeding edge specialists.
I advertise <25% of my positions (guesstimate). This is a failing on my part. I have no magic lens to read CVs, so they carry no additional information value for me.
Hiring is expensive and often takes a long time, but hiring the wrong people is much worse.
Throughout my projects I have only had one person leave, and that was for a once in a lifetime offer. I very rarely need to fire anyone.
I would rather hire two excellent dudes than five good dudes. So I tend to have the budget to pay good rates. Then I call up temporary manpower to solve the more mundane tasks so I can keep my excellent people on the more difficult and interesting items.
Red flags I look for when I'm on the other side of the table:
- Who is doing the hiring? Some checkbox HR drone, the owners/investors, or the actual team?
- Hiring evaluation tools. Have they actually bothered to read up on the latest few decades of research, or are they just following dogmatic trends? Do they even track their own prediction skills when hiring?
- What is their understanding of the project, tasks, etc?
- Do they respect my time investment?
1) a "dude" is gender and ageless, of no persuasion, has neither skin nor eye colour, and so on.
by thorstenn on 4/10/20, 7:09 AM
by dudul on 4/10/20, 12:27 PM
by Lio on 4/10/20, 11:14 AM
Other than filtering out chancers with a lack of required basic skills, one thing that’s always bothered me is how my own personal Dunning-Kruger effect alters the interview process.
I obviously only ask questions I think I know the answers to otherwise how would I know if they were correctly answered?. So that may mean I miss out on candidates with a range of skills I lack and can’t detect in interviews.
Interviewing successfully, I suspect, is a ”difficult” problem if you take it really seriously.
Like those pointless “skills matrixes” that inexperienced managers like to set up for their teams. I mean you can ask me my skill level for a particular subject matter but how can I answer you with any accuracy if I don’t know what I don’t know?
by dccoolgai on 4/10/20, 11:11 AM
If only. It's more like a Wonderlic Test.
by rafiki6 on 4/10/20, 3:21 PM
And here is the real crux of the whole thing. Considering how standard it is, we might as well just make it a part of a software developer certification/license that you have to do once to break into the industry. The funny thing is, despite our best efforts to not become a real standard profession we are behaving a lot like one, except we don't realize it and keep making candidates jump through the same hoops repeatedly.
Now many of you will balk at the prospect of standardizing but hear me out. Are we really that different from any other profession? At the end of the day most CS curriculums are very much the same. Why can't we do standardized tests to "pass the bar" so to speak? And additional certifications can be taken for specialties (e.g. ML, Cyber Security, Finance etc.) like in many other engineering professions or like specializing in medicine.
Yes, knowing algorithms and data structures IS imporant to being a good software developer, even if you are building CRUD or mobile apps. But, how many times to do I need to prove I know them? Yes, showing leadership skills IS important to being a good software developer. But isn't being a leader mostly about conflict management, moral obligation and being ethical?
Maybe we can stop fearing becoming a real profession that is beholden to standards and public scrutiny and embrace it. It will end up being better for everyone.
For juniors (not in age, but in experience), it offers a consistent predictable way to learn and grow, and a set of criteria they can focus on learning to land junior positions. From there we can treat them like apprentices, and to get certification you need to spend x number of years being supervised. This allows companies to also retain their junior talent for longer and their investment in their training can pay off in the long run because even if they lose a junior who's now certified, they can hire a recently certified intermediate from another company!
For seniors, it means we can focus on demonstrating why we are seniors (i.e. I've built these systems, led these projects, etc.), and offers a real honest predictable path to becoming a staff or principal (i.e. a master).
For companies, it means they can focus on hiring PEOPLE, not leetcoding machines. They shouldn't have to worry about assessing the technical skills of individuals. The only reason they do so is because they feel they have to. If they had confidence that the people they are interviewing are likely qualified as it is, then they can actually focus their time and effort on more important things to assess such as if a person is a good fit for the mission. People assume companies do this because they want to haze candidates. The reality is, companies just don't have any better way of de-risking their hires at this time.
We can revisit the criteria regularly to make sure the tests we need to pass represent what it means to be do our jobs and do them well. We can have industry input, academic input and so on. We can even have the professional body accredit programs so as not to have candidates waste their time and to ensure academic programs keep up with the advances industry makes. Further, we can make this a global thing.
Rather than shunning becoming a true profession, let's learn from the mistakes of other professions and build a process that helps everyone.
by kafrofrite on 4/10/20, 10:28 AM
I agree with the article, and had my fair share of bad apples so my thoughts here. Unless the role was something that required dealing with incidents, there was no point on doing a technical interview onsite and seeing how the candidate reacts under stress. Generally, noone cares how well a candidate performs under stress. Instead, I'd let them deal with technical problems on their own time, if they wanted and tell them to spend no more than 2 days (I'd actually kill the instance to ensure that). For security positions, I ended up building a CTF platform and told them to solve as many challenges as they wish and send back a report.
For the onsite interviews, we did mostly cultural interviews. There was a bit of technical questions involved, mostly open-ended questions to see how they approached a problem. This usually was to design some system or, given a tiny codebase, how they'd go implementing a feature. Also, I did what we ended up naming "spirals". Successive questions, increasing in difficulty to see how much in depth they went during their research. E.g. Traceroute -> Ping -> ICMP -> Differences in Linux vs Windows. This had two benefits. It was clear how much in depth they would go and two, it was almost guaranteed that at some point they wouldn't know the answer, which is fine, but forces them to explain how they would go to find the answer. Almost always, I'd tell them whether they were on the right path and if they were stuck kinda help them. I'd give about 5-10 minutes for the candidate to ask me anything. Literally, anything. For me, this was important because I would get a sense for how candidates evaluated the company and what they were interested in.
Beyond that, at some stage, we added some questions called internally the "I read it on the internet". The questions were pretty straightforward, e.g. given a terminal, tell me how would you ssh in this box as XYZ user or how would you rm a directory. Fun fact. I initially made fun of the operations guys asking those questions until I interviewed a series of people where noone knew how to do simple stuff with their terminals. Btw, I didn't focus at all on technologies. Given the size of the company, asking "How much you know about $LANGUAGE" would be futile. I wanted to hire people who could pick up new technologies and, given the size of the company most of the tools were custom-built or heavily modified. It was pointless asking "$LANGUAGE" and then telling them "Well, great, just keep in mind we don't actually use exactly $LANGUAGE but rather our own version of it". Last, and probably the most important. I asked myself how I wanted to be treated during an interview. I kept in mind that I generally wanted to be treated with dignity and respect, I kept in mind that the resume is basically a snapshot of someone's life and the candidate is a human being and acted accordingly. Also, I valued for candidates who asked for feedback and actually I'd give them some and tell them stuff to read reg. things I felt they could do better. Btw, I also assumed that each candidate would get an offer and I didn't want them coming in and thinking "That's the idiot that was acting cocky during the interview".
by crimsonalucard on 4/10/20, 3:46 AM
I was overruled and he was hired based off of his credentials, resume and what he talked about in the interview with another person who just had a talk about "architecture."
Turns out the guy can't even code. He constantly just talks about architecture and tries to tell everyone to completely change the architecture to be event driven. But when given an assignment to work on the actual product he totally fails. It's crazy, the man is a complete clown.
Here's what I think. You can't hire a candidate based off of just a technical interview alone. But you can't just hire a candidate off of his credentials either. There's too much room for lies and deception in this area. You need both metrics in order to get the most information out of a candidate. It goes both ways.
The Technical Interview was invented because of too much of the above problem. People who are charismatic and exaggerate their resume and turn out not being able to code. Of course nowadays with canned memorization going rampant and technical interviews becoming IQ tests there's really no accurate way measuring a candidate.
I'll just say that as bad as an IQ test is in identifying good programmers who are bad at IQ tests, a person with high IQ is likely going to be a good programmer.
by non-entity on 4/10/20, 1:52 AM
At the same time, some of these guys are seniors. How on earth have you been in the industry for this long and not grasped what your job is?
by redis_mlc on 4/10/20, 1:51 AM
Both answers are wrong, depending on the interviewer.
If you say "yourself", you're admitting you're a lone wolf. If you say "team", then you were along for the ride, even if only two people were on the team.
by mberning on 4/10/20, 4:14 AM
by codeisawesome on 4/10/20, 2:59 AM
I disagree that it is a broken process. I do not want the software world to also start selecting for non-hard-work metrics like who your parents were.
by jmpeax on 4/10/20, 2:58 AM
Software is one of the very few industries where lying on your resume and lying through your teeth about your prior accomplishments can be very easily tested.
by ra5 on 4/10/20, 1:53 AM
by lazyjones on 4/10/20, 2:32 AM
When you compare IT with other industries like the author did, this is what makes hiring so different. Other industries are fine with hiring graduates with no specific experience and the candidates are eager to learn on the job. Whereas in IT, half the people will tell you "can't do this", "don't like that", "won't learn Java" ...