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.
The negative thing is that most tech companies heavily favor "top school" candidates and actively recruit for them. They would rather higher someone provably less qualified from a "top school" than someone else. They track and boast about how many "top school" candidates they hire.
Tech companies are hugely biased in favoring the upper class. And then they misguidedly try to pay a recompense for this unethical bias by discriminating on the basis of race in favor of "unrepresented minorities". Of course, they still really want those "URMs" to come from a "top school".
Their goal is to counter their active classism through active racism. As if they somehow cancel each other out.
Everyone said it was impossible.
She went to LinkedIn, found people with the right skills (strong data and ability to communicate), and had a massive fight with HR because none of the candidates came from "top" schools.
She won the argument, and all of the hired candidates did a great job.
People (especially US people for some reason) seem overly obsessed with the university someone attended, when it doesn't seem to be that predictive of workplace success.
Good job prospects upon graduation is one of the things that makes a school a "top school" and attracts smart students. If you wanted to hire people with no work experience, and money was no object, a "top school" would be the logical place to go to first. And I say this as someone who didn't go to a top school. So tech companies actively recruit from top schools only insofar as every other company in every other industry does. But that doesn't mean they recruit exclusively from top schools either. Stanford, MIT, and the Ivy League literally don't graduate enough students for that to be a feasible new grad hiring strategy.
You'd have to provide evidence for the first half of that statement though. My personal experience is after you've worked a few years, no one in software engineering cares where (or even if) you went to school. And any software engineer with a pulse located in the SF Bay Area can get at least a phone interview with any of the top tech companies.
Is this true? I can see this being the result of poorly implemented hiring processes, but I can't see this being the explicit goal at a reasonable company doing reasonable things.
It wasn't that there were not qualified people from each school, it was just easier to find them at schools with hard-<subject> educations.
There were other schools that were physically closer even within a few miles, but he could go all day without finding a promising candidate.
He hires many minorities, women, people of different orientations, so it wasn't that.
It was more like, "does anyone understand a linked list?"
Years ago, I had an interview for Yellow Pages. I know, who the hell still uses Yellow Pages? Well, this was back in 2014, though I'm still wondering this now. Anyway, the entire interview process was very depersonalizing. Nobody asked me about my background, why I was interested in working for them, or anything like that.
They had me go into a room and sit down at a computer with someone who was presumably an engineer. I had to solve several code problems in JavaScript and Ruby, each one having to be solved in under a minute. If you didn't finish one, it would just erase what you worked on and moved on to the next problem.
After those shenanigans, they brought me into a board room with 6 other people, and I they asked me to solve several brain teasers, including the "burning rope" problem. These people were stone cold! No humor about them. Fortunately, I memorized most of these brain teasers from the internet and previous interviews, so this part wasn't so much difficult as I had to act like I hadn't heard those questions before.
I didn't get hired, and it was for the best because I'm not a robot, and I don't like brain teasers.
YellowPages.com looks a lot better than it did in 2014, but let's be honest, it's a glorified ripoff of Yelp with shitty search results. In fact, it looks nearly identical to Yelp. I wouldn't have been proud to work on that.
The same with diagram drawing, 10 boxes and arrows, but missing most aspects of the architecture that actually matter. As a hiring manager I much more prefer to talk through the problem to see if the candidate can ask the right questions, thinks about NFRs, can suggest alternative solutions in light of new information.
As business gets more intertwined with tech, workers need more technical competency - in parallel with automation of traditional jobs.
My take is that the more traditional companies will have to compete with tech firms on attracting talent, which in turn means that they'll have to change their ways when it comes to hiring, on how they do their hiring.
I think the old days of "We only hire Harvard / Yale / Princeton / Stanford grads with 3.5+ GPA and top internships" are starting to die out. Yes - some of the most competitive jobs will probably continue to use proxies like that, but even firms with the worst gatekeepers are starting to see that there's talent everywhere, and that modern tools can help identifying them. (Remember, one major reason that prestigious firms only hire candidates from top schools and programs, is that they only do their campus recruitment at those schools, because it's a pretty labor and resource costly activity - you can't visit every school in the country, and check out the top students there)
Thats what we want to see.
That said it’s at least a partially objective skill check and I don’t know a better way.
Let's be honest. It totally helps to know someone even in tech even with technical interviews. If you know someone in a group you're interviewing in they'll often give you hints about what the questions will be. They'll even give the exact questions that will be asked. This helps a lot in narrowing down your studying for the test... err... interview.
My ability to do really well on written tests actually got me into Stanford, despite coming from a pretty normal middle class background -- my dad worked for suburban city government. If I had majored in CS instead of science, I would be a shoe in, but alas I didn't.
If they could just do the tests slightly differently I could ace them. Instead, I'm mainly just avoiding the FAANG world. If I spent another 80 hours practicing them I might have a shot, but eh...
I was stuck in stages 2 and 4 ( anger and depression) of 'unable to land a faang(ish) job grief' for years and would make angry comments on this weekly thread.
I think I've made peace with it and I hope to be in stage 5 acceptance. I've been leetcoding every single day for last 3 months, 300 problems in I can hit my target of one easy and one medium with 1 hr goal. I hope to reach my target of 1 easy, 1 medium and 1 hard within one hr. I regret not doing this sooner.
Even if don't land a faag job, this process has led to me accept the process and make peace with it. I really don't care if hiring is 'broken', it is what it is, its an obstacle i need to overcome. Bring on 'trapping rain water' , 'describe one time you had conflict with your team' garbage. I am ready!!
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.
Then maybe companies can actually focus on hiring for the job?
Even then, I've started to ask what "hiring for the job" means. General aptitude in our field should be a good indicator of ability to learn and pick up skills in different specialties.
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.
Getting many software jobs is still about network and recommendations.
Getting many software jobs is about a standardized base level skillset and knowledge (i.e. leetcoding).
Getting many software jobs is about specializing in a domain and skillset (for e.g. ML or finance or cyber security and all their respective languages and frameworks).
And as many commentors have mentioned we aren't as meritocratic as we would like to believe. We still bring our biases to the hiring process. We still hire people we like for subjective reasons over others.
My point is this. Maybe, just maybe, it's time we as an industry standardized the profession officially and codified what it takes to get certain positions. That's what I can offer to this conversation constructively.
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. Then 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.
Your credentials and political connections are what allow your resume through the ten arbitrary filters before you even get to the technical screen, collaborative coding, etc., and those same credentials / connections are what get you hired over everyone else who completed the technical assessments just as well as you did.
The tech screens exist as a political gatekeeper filter. It allows people who are fighting over petty authority among codemonkeys way down the food chain to enforce arbitrary and capricious standards, especially on cultural capitulation, to ensure they are hiring people that meet a good mix of (a) competent, (b) don’t know what they are worth, and (c) can’t quickly politically outrank you because you forced them to comply with your tribal pecking order bullshit on the way in the door.
That’s all it has ever been about. It has never ever been the least bit about meritocracy.
One of the best programmers I've ever met.
He couldn't do complex big-O analysis because he never learned it having started to work straight out of high school, but other than that, his code was meticulous, he gave excellent code reviews, and just had this natural understanding of technology and how to program. Probably the best programmer on our team, much better than me and I often sought out his opinion on things, even though I could have been his dad. I always learned things every time I talked to him.
He is a multi-millionaire now, and still works as a programmer but does it for fun.
And I do 3-4 hiring interviews a week here in NYC. What connections? First show that you can code; a lot don't pass this filter. Then show that you can architect a large distributed system on a whiteboard; a lot of people applying for a senior software engineer position lack the breadth of knowledge and the consideration required.
And after that you'd speak to CTO, where maybe you can say or do something so silly to be rejected; this happens very rarely.
You might find it as amusing as I did to learn that the word ‘meritocracy’ was intentionally coined to mean more or less the opposite of what you think and how you used it here — meritocracy was a derogatory word intended to highlight the social injustice of thinking that ‘merit’ is somehow fair and can be measured and used to rank people.
https://en.wikipedia.org/wiki/The_Rise_of_the_Meritocracy
Anyway, I’ve gotten hired into a good spot in a company without knowing anyone there. Maybe the dozens of responders are some indication it’s more than round-off error? Why are you so certain?
> Your credentials and political connections are what allow your resume through...
Wait, aren’t credentials one type of “merit”?
> 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.
I think it stops being seen as a breath of fresh air when e.g. Google's explicit expectation is that you will spend multiple months studying for the privilege before interviewing with them.
And that's after investing years and hundreds of thousands of dollars in extra schooling.
You also don't get to retake those every couple years.
Of course their bar to entry is very high, they are the one of highest paying employers in tech. If you want the pay and prestige, you have to play their game.
Where I would agree with you is when non-Google companies use Google tactics for hiring but pay like a mom and pop shop.
If you're not a fresh graduate, likely you've had much of the preparation as part of your previous job experience.
How was it in the 80s or 90s ? could you be hired just because you can fix or implement something even if you don't fit that well with a group ?
90s: we need to hire everybody who can code
Unfortunately, I have also found that looks impressive during interviews only to not work out in practice once being hired. Not matter what, as a JavaScript developer, people are scared to death if you write original code.
I've no doubt your code is the best in the world (have you a github repo?), but with that attitude you'd be shown the door quite soon.
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.
Whiteboard interviews are a skill unto themselves, with only a glancing relationship to day-to-day job content, artificially high-pressure, overly performative, etc. You measure hours invested in Leetcode, not suitability for the work.
Take home projects probably collect good signals, but present a high and (crucially) asymmetric burden on the candidate. No one wants to burn a weekend or vacation days pouring effort into something that the employer can just glance at for 5 seconds and throw in the trash. Also, many candidates would prefer to reuse their time investment over arbitrarily many interviews instead of starting from scratch on each company's assessment.
Interviews focused on personality, culture fit, communication skills, and "gut feel" overemphasize the interviewer's personal beliefs. Likable candidates aren't especially likely to be good, and good candidates aren't especially likely to be the kind of people the interviewer wants to have a beer with.
See I would much rather invest time and money into somebody that I like being around and who I think is capable, rather than have some jackass who is really really good off the bat.
Of course there are biases, but that's true weather you hire for skills, personality, or both.
I think a lot of programmers think that your skill level is the only thing you should be judged on, but I think thats mostly because there are a lot of very unlikable people in this field and they'd rather hide behind their perceived skill level than attempt to be a semi likable person.
There is a sweet spot, somebody who has skill but is also not terrible to be around, and can learn quickly. The problem is that most interviews swing too far one way or the other to properly asses for both.
Hiring software devs is a damned if you do, damned if you don’t proposition—somebody is always gonna bitch.
There's a problem at the moment in the market that there's a huge amount of pent up demand for senior developers. The market has responded with bootcamps and the like, and we have a ton of junior devs with very little knowledge and experience pouring into the workforce. The sad truth is that most devs fresh out of collage or a bootcamp aren't valuable enough to be worth hiring at large tech companies like Google. Most people who apply to any hiring role you advertise won't really be able to program effectively. (And if they can, they won't know the conventions of the language they use, they won't know anything about security, they won't be able to read code others write in order to debug it, etc etc.).
Programming is hard. It probably takes about a decade of practice to become good at it, and I don't think schools have figured out a replicable way to take someone off the street and teach them programming yet. (For example, most fresh grads have never had to read the code another programmer wrote. Imagine teaching people how to write without teaching them how to read!)
I think there's lots of angry junior folks out there saying "Hey, I can write a simple for() loop in python, and lots of people are hiring - but I apply to lots of jobs and keep getting knocked back! The hiring process must be broken!". And a few angry senior engineers out there saying "Why do I have to keep writing fizzbuzz? Its like I have to prove over and over again that I can program at all!".
Of course, nobody wants to admit that the reason they failed their 6th whiteboard interview in a row is because they aren't very good at system design. And the reason for that is that their collage didn't teach them any system design skills, and they have no experience, and they never learned how to use words to communicate technical ideas. And ArbitraryProductCo doesn't have the runway to train you up.
Of course there's the occasional person who is really skilled and somehow still manages to fail programming interviews all the time. But if the goal of a technical interview is "make sure we don't hire anyone who wouldn't be effective at the job", I think they're fit for purpose. I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.
.. which is really unfortunate, because those big companies are the ones that have the most resources to hire, train, and mentor juniors. At the opposite end we have small companies that can literally go bankrupt when their hire doesn't work out and is unable to deliver working software. Even if the hire works out well enough, they're not learning as much as they could in a well resourced team with enough serious talent & seniors to mentor them.
> I think the real sin is that we're afraid to tell people they aren't very good at programming yet, and we use technical interviews as a scape goat.
I don't know if it's useful to tell people that they aren't very good. It's a serious chicken & egg problem because everybody wants to hire seniors that can hit the road running and nobody wants to train the juniors. The juniors really don't need to be told that they aren't good enough, they need a place where they can get good!
So does this mean that programming education is broken? That companies should invest more in training? That bootcamps should revamp what they teach? That there should be industry standards for what programmers at different levels should be expected to know?
The most maddening thing about interviews imo is the opacity. There's always uncertainty about where exactly things went wrong, and how it should be fixed next time. It's almost a meta-engineering problem of its own. And it's a metaphor for the lack of software engineering standards.
1) Anyone with >0 years of experience outperforms a Waterloo internship candidate on the coding or algorithms round.
2) Anyone interviewing for a senior position performs well on the other rounds and fails only system design.
I'm pretty sure it's large companies that can afford to play long-term big-picture strategies with talent, and small ones that have such low-rent concerns as which languages and frameworks you know.
But is leetcode really the way to find them?
You didn't address this part of the problem. This friction is one of the reasons the job market is so distorted.
TripleByte ?
Have you gotten any actual work done in the last year?
> in the hiring space.
Oh wait. This is your job.
a) Open time. I give them a couple problems in the morning and they can take as long as they want to think about them before the interviews. This takes away the 'deer in headlights' situation that so often happens to people - all of us. I'm good on my feet, but 1 time out 3 'I just don't see it' immediately. But if I have some stress-free time, I usually do.
b) Don't test their knowledge of algorithms. Who cares if they've practiced certain things a lot? Doing homework is a small measure of what you want. I give them fairly basic problems that have nice side-show questions to ask and just have a discussion.
c) I try to test for knowledge where they should have it: if they've been on tools & build or dev ops they should have a good grasp of things there. Another way to say: you're looking for strengths not weaknesses. I keep an open mind and think 'how can we leverage this person's talent'? Maybe they're not good over here, but better over there.
d) Fairly simple code, idiomatic, etc. not rocket science.
e) Mature communicator and by that I almost literally mean not too crazy. I think most of us are 'abnormal' and that being a 'decent communicator' is a little bit rare. Companies are full of weird dynamics they have to be resilient a little bit.
I’ve definitely interviewed with companies where I was put in really unnatural situations that I struggled to shine in. For example, I bombed an interview in which I had to do a live coding challenge where I had to talk through what I was thinking while coding, which the interviewer insisted on so they could understand “how I think”.
I thought it was an incredibly cumbersome and useless request because I never talk when I code, and coding in front of others in an interview is tough enough as it is. I asked if we could discuss the solution once I completed the problem, but they declined that idea.
Needless to say, I didn’t get the job and the assessment felt like a huge waste of time. I think a lot of people see companies doing stupid stuff like this and get frustrated because candidates are often capable while being placed in high-pressure situations that don’t enable abstract creative thinking, which programming requires.
FWIW, there is limited time to collect data about a candidate in the context of an interview, and being able to observe a candidates’ thought process can help a lot with that. Obviously, this biases hiring towards candidates that are more observable, all else being equal.
I’m sure it varies between interviewers but the lineup I had at google clearly didn’t want to dedicate more than a minute or two to non-algorithm questioning.
Whenever hiring comes on up on reddit or HN I see a lot of posts that can only come from people who haven't been an interviewer much.
First rule of hiring: most of the people you talk to want your money. The candidate is selling themselves to you. They know firing people is hard and there are almost never consequences for misleading interviewers.
What happens when people are asked to talk about their prior projects, experience or really anything that isn't a highly controlled and repeatable coding question?
1. They pass off things they saw or read as their own experience.
2. They claim a team's accomplishments as their own.
3. They massively exaggerate or try to BS you in other ways.
4. They give uselessly vague answers, not necessarily deliberately.
Maybe you don't do these things, but back when I bothered asking these sorts of questions I did encounter such answers pretty frequently.
Companies have converged on live coding because that's something concrete, real and largely un-bullshittable. Yeah, toy programs in interviews aren't "real" programming but it's a lot closer to real than listening to someone ramble in a disorganised way about "their" previous project, and at the end realise you still don't know what that person actually did and what was done by others.
* they're not cheap (although not that expensive all things considered), assuming you spend say 10 person hours on two calls and an on site.
* they produce false negatives. on the spot exam style algorithms interviews don't reflect day-to-day work, and they filter out people who might be great at the job, but aren't used to the specific type of stress that interview creates.
* they can produce false positives. failure to check for interpersonal skills in leet koders can leave you wishing you had never hired them.
* they're painful for the candidate. ideally your role is the best fit for a candidate. people only have so much emotional and logistical bandwidth. they may take an offer after interviewing with a handful of companies before they ever find you.
now, I don't have numbers for those last three points. I don't know if anyone does. but we can look at most hiring processes and see that they are a problem, we just can't tell if it's a big enough problem to consider the process "broken".
I’m not seeing a compelling problem with the outcome. The question is: are companies not able to hire good people? And: are good people not able to find jobs?
Interviews are also expensive for a company. And I don’t really see a clear or compelling argument that interviews somehow cost the candidate money. How much money? If the candidate doesn’t have a job, then what exactly is money or time cost to the candidate? Doesn’t the eventual job with income outweigh all interviewing costs? Isn’t the cost somewhat irrelevant if it’s not egregious, and there’s really no choice if you want a job? Isn’t the alternative, choosing not to interview, potentially way more expensive?
If you’re going to frame it as expensive, I think it’s more than fair to counter with you need to average the cost of the interview over the time period that you’re employed. If you interview for 10 hours, and you work there for 5 years, the cost of the interview is 20 seconds per day.
> they’re painful for the candidate
I agree that interviews have a time cost and that candidates have a finite budget. That means someone looking for a job should invest wisely, figure out how & when to decline an interview, study the companies before interviewing.
This is subjective, and it’s not a solvable “hiring problem”. This is something the candidate has to fix for themselves. Nobody is going to give you a six figure salary and ask you to work with them for many years without vetting you. It will always take time, and it will always be somewhat uncomfortable and emotionally draining. Some people prepare for interviews, and some people like to interview. If you view it as a skill, one that you can learn and improve at, maybe it will become less painful for you. But don’t expect that companies are ever going to do that for you.
It doesn't matter what the process is, some form of song and dance is needed.
It would require some sort of longer-term data gathering around the rejection / ghosting process.
For example, Google claims to be very objective and data-driven about their hiring process, but once a candidate is rejected there is no further data.
How would one solve such a problem?
If we agree that it's just window dressing around a "song and dance" (I prefer to call it "the rituals of gate keeping"), there is no problem to be solved.
But I still feel like giving in to cynicism is the wrong answer.
I see it slightly differently; I think that 95% of the success of companies is driven by key moments or decisions by 5% or less of the work. (That’s usually by a similarly small slice of the workers as well.)
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
I would guess that most of your hires are single young people. And you are already kind of teaching them to work nights and weekends, which sounds like you are, again, choosing people who would not have a problem with a bad work life balance.
I also wouldn't be surprised if your process isn't teetering on the illegal side. Not on purpose, but it might be accidentally favoring or disfavoring a race/gender. Probably not enough to get you in trouble though, because those things are hard to spot. And unless your company is really big, probably nobody cares.
Contrast with the alternative: I'm a senior, considering switching jobs, but I have no real way to evaluate the potential new employer beyond word-of-mouth and interview experience. What if it turns out to be a place I don't like and I just gave up my former position for something worse?
Working a few evenings & weekends (and getting a little extra $$) to evaluate the new company sounds like a superb way to gain the confidence and jump ship without regrets. In best case, I get a new job I like. In best case, I get some extra money and keep my old job which is better than the new one proved to be. Win/win? What's the worst that could happen?
Everyone we have offered the option has taken it, and they're usually pretty enthusiastic about it vs traditional interview process. We're working with them a lot during the trial period, and after if they get hired - lots of opportunity to find out how they're doing, and so far no negative feedback.
At the point where we move to the trial, we don't usually know age (because we haven't even seen the candidate) or family status. From what I've picked up, it's a mix of ages (usually a bit older - we've found some experience is necessary to be successful as remote-only), and mix of single, married, and families.
For those who have ended up hired - I think most are parents with younger families.
Other than the trial period, nobody usually works nights or weekends.
Almost all processes do (though in this case, family status is probably the more relevant protected class it biases on.) That's not illegal, if it's sufficiently connected to the actual needs of the job, and they seem to have at least tried to evaluate that for their hiring process more than most places do, so they are probably less at risk of disparate impact discrimination than most hiring processes in tech.
Wow, if you say so, but that seems weird to me: every job I've ever had (and everybody else I've ever seen hired at any job I've ever had) it's taken quite a while before I was really able to contribute much productively. Just getting acquainted with the codebase, figuring out the deploy process, and learning all the unwritten rules about the company culture takes a non-negligible amount of time.
Also, do you give them tasks on your actual code base? If yes, you are likely biased towards people already familiar with your tech stack (getting really productive with an unfamiliar tech stack takes more than a week, but short enough to make hiring somebody from a different background still worthwhile).
Any thoughts on this? (I realize that some amount of bias in the process is OK)
We do a subset of on-boarding, just enough to get them running a local dev environment and able to push commits and connect with the team.
We pick real tasks from the backlog that don't require a lot of ramp-up to complete.
We assign someone to work with them during the trial period, help get their environment going and orient them to the tasks, help them if they get stuck.
Someone with experience with the technologies (Java, C#, Javascript, Linux) used in our stack can usually get up and running and complete a simpler task in the 1st week. Over 2-3 weeks, most people accomplish several tasks of increasing difficulty.
We discuss with the candidate how things are going each week, how they're feeling about things and how we think things are going. Usually by the 2nd week it becomes pretty clear if it's a good fit.
Since we are remote-only, candidates have to be capable of figuring things out mostly on their own - technically and organizationally, so we look for more experienced people - who probably are more likely to be successful with this kind of interview process.
IANAL, so some of my phrasing may be wrong.
I keep hearing about this mythical coding con man, but I've yet to find anyone that can both have an intellectually stimulating conversation about a technical topic while at the same time suck at coding. I can generally tease it out in 15 minutes tops.
It's pretty easy to tell if someone knows a topic or not by just asking increasingly more specific technical questions to follow up on their answers.
There's always stress for an interviewee, assuming they care about whether they get an offer.
I'm quite happy knowing people tried this.
I've never had a full afternoon with a candidate. Maybe if I did I could avoid technical challenges.
The only thing that really did bother me was two engineers showed me a game they were working on and asked me what I thought. We talked a bit and I ended up giving them a bunch of "here's what I'd do to make the game more fun/interesting" ideas, and everything I mentioned was at some point added to that game (these were fairly basic concepts such as level designs, so it's possible they had some thoughts on their own). I learned never to give advice to a company without compensation, at least.
I once had an interviewer with two (TWO!) PhDs. He made sure that I knew he had two (TWO!) PhDs by handing me his business card as we sat down and casually remarking that he had two PhDs (see, right there, two of 'em, yupperoo). This behavior ("he's kind of jerk, and he has two PhDs") had been accurately foretold by the prior interviewer (that session had gone great).
The guy-with-two-degrees asked, "What is the simplest way to synchronize two threads?"
Well, "simple" is pretty fluffy and subjective, so I asked what he meant by it.
"You know, the most simple way."
It didn't get better. I probably made a mistake, and started naming a bunch of synchronization schemes. "Mutex? Semaphore? Dekker's algorithm? Spinlock?". Each mention got a response like, "No, I mean simple. Simpler!"
I never got it. The rest of his questions were similar ("What is the best way to do RPC?"). His parting words to me were, "You need to go back to school."
The specific answer he was looking for was, "mask off interrupts". Doesn't work on multiprocessor systems, so I'd not even mentioned it. I wrote their hiring manager a polite email along the lines of "thanks for the interview, here's one question that I got wrong and why."
No surprise, I didn't get an offer.
Four or five months later the firm called me back, saying that they had fired the jerk and was I interested in interviewing again? I told them I was pretty happy where I'd landed. (I did not congratulate them on firing the jerk, and I suspect they'd had trouble hiring anyone while he was there).
We never made a no-hire decision based on one answer, and nobody ended an interview after one question, unless there was some sort of emergency. Site outage, fire alarm, that sort of thing.
> He went on to ruin digg.com (the rewrite everything guy)
I didn't ruin Digg. Ruining Digg was an all-hands-on-deck multi-year team effort. I wasn't involved in the decision to rewrite it and didn't agree with it. I don't know for sure who was, or what pressures were at work behind it.
What I do know is that our VPE came to me and said that we were going to rewrite Digg from scratch, and do it in six months, because the code was a mess and it took too long to do anything. Which was true.
I told him it was a terrible idea and we should figure out the end point we wanted to be at, then incrementally refactor our way towards it.
He said we'd tried that and it didn't work, so we were throwing away everything and rebuilding it from scratch. In six months.
I said that if we wanted the slightest possibility of success, we'd have to cut features to the bone and ship a minimal version we could quickly iterate on. I suggested cutting the ability to comment on stories.
He told me he didn't think we needed to do that, and we were going to ship a feature-complete version of Digg in six months, from scratch.
It was a completely bananas project, doomed from day one, and I wasn't shy about saying so — I told anyone who'd listen that I gave it a 50/50 chance of destroying the company. The promises made about what would be delivered & when were completely unrealistic and unreasonable. There was nobody articulating what we were supposed to be building, or to say no to what shouldn't get built. Into that leadership vacuum flowed a torrent of well-intentioned but (in my opinion) misdirected ideas for what the thing should be, which ate that first six months in the blink of an eye.
> I promised myself to never be a dick to people I interview.
I personally going through a personal mini trauma.
I don’t want explain what is it. But the way you think is very fascinating to me. I want to be a person like you. Not some asshole who literally ruined 1 year of my life.
Checking his LinkedIn it seems he works for what amounts to a modern payday loan (now the users pay with privacy loss and a monthly subscription instead of high interest) website now.
Sounds like the interview process worked for you. You found out that you don't want to work with him and didn't.
He's technically right though. For instance in postgres, you don't need to have a GROUP BY clause when using HAVING https://www.postgresql.org/docs/current/sql-select.html#SQL-...
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.
Some years ago, I was looking for a job, and an employed friend of mine sent me a problem and said "this is our hiring challenge. Try it out".
I completed it, and she asked for my resume, and turned in both to whoever the relevant person was at her company.
She then reported back to me "he said this is the best response he's ever seen to the challenge, but we're looking for someone with more experience". I was not contacted by anyone else.
And years later, when I ribbed her about this, she told me "he regretted that, later".
I note that by putting the resumé screen first, you're committing yourself to the idea that whatever you're looking for in the resumé screen is more important than anything you might learn in the phone screen or the on-site. Do you believe that? Are the phases looking for the same things? If not, is that intentional?
My theory is that the people who have the worst interviewing experiences are the loudest and write the most blog posts about it.
Just another facade perpetuated by VCs given too much money by the market, and tech companies "faking it till they make it" in regards to actually hiring all the smartest people.
You think they would learn that the actual smartest people won't fall for someone just saying "all the smartest people work here ...", and that they are effectively attracting naive people with that slogan instead.
That being said, the high-salaries of SV/NYC/etc. will attract some of the smartest people ...
It's also important to learn by failing (aka learn by doing). Like parenting, there are many things in organizational behavior that can't be learned until you experience it for yourself. Few of us can be told "don't do that" and will internalize it to the degree necessary, without experiencing personally what happens when you do "do that". These people graduating from top schools and going straight into FAANG are doing themselves a disservice of the worst kind, by missing out on important organizational learning experiences.
On that note, I recommend everyone either get fired from a job, or work for a company so bad you quit, at least once. I also recommend it at most once. :)
As for inverting a binary tree, with your experience you must realize that the very large majority of applicants are poseurs. You need to filter them with easy things like inverting a binary tree. Most companies need "doers" not "thinkers". Even at the highest levels of pseudo-management (staff and above IC), you really better be able to do this kind of easy stuff.
Lots of the consultant gigs that people do actually end up with being hired at the company they consulted for.
I expect the converse applies as well, someone who likes being an employee is unlikely to take up your offer.
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.
If only this were true. I've co-authored a (technical) book, edited another, have dozens of OSS contributions, and GitHub projects with hundreds of stars. Everyone still tries to whiteboard interview me. Usually I tell them to screw off, but still. My theory is that (a) people are too lazy to come up with better hiring processes and (b) there's a prevalent "if it ain't broke" mentality so there's little motivation to do anything about it.
If they want to know if I can code, I'm happy to point them to several git repos that I wrote >95% of, and send code samples of non-public code that I wrote.
I can make real tasks happen, like make a robot navigate a room autonomously, but I suck at remembering how to write quicksort or write a parser for some weird interview-specific language or all of the insane number of C++20 features. At most whiteboard interviews at large companies, I was asked to code things I have never done for work and will probably never do for work.
Machine learning interviews frequently asked me to implement NMS or gradient descent. Fine, I can do that, and fumble a bit in the process (and probably get docked points for fumbling), but NO machine learning engineer on the planet needs to do these things because there are excellent libraries that do them for you and it isn't the job of the ML engineer to re-invent them.
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.
For those coming into the industry from outside, the real questions may be less about what you're capable of programming, and more about your wisdom in producing code that works well with other code and with the realities of failure. It's hard enough to get a good sense of how much of that wisdom you have even when you are a software engineer...
There's also the fact that most jobs are looking for exact matches rather than someone smart enough to get up to speed on their tech stack. So they want to see X years with Y technology. If you're coming from a different field it can be hard to check those boxes.
I’m finally about to jump to a big tech company but up until now I worked for a small company on the east coast and don’t have a blog or any public projects on GitHub.
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.
I think this is actually getting at why people ignore work history and what projects a candidate was involved in.
When you get into these places you realize how little that name brand means. There are a lot of not particularly bright people at those places. Or more charitably, maybe bright people but not particularly skilled at software engineering, for some definition thereof. Sometimes those people can attach themselves to a well known project name. But what did they do for that project? Were they constructive or not? You can't really tell based on their word alone. Maybe they can charm their way out of that discussion. It's also not unheard of that they could be taking some credit from peers.
So people come up with the quizzes and IQ tests, however flawed, as a way to "verify".
I thought people jump around a lot these days.
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.
If you worked in a team you should be even more able to explain your individual contribution & the context in which you worked.
This is not a trick question. A good answer is "I did x, y, and z tasks, which required a, b, and c interactions with the world around me to make sure I was doing the right work and meeting expectations".
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" ...
They do a lot of the same things, just the incantations are different.
I do have more non-coding hobbies now and other responsibilities sucking up more time than when I was young, so I don’t have as much time to learn them on my own, but I still can and do learn them, especially if needed at work.
I think the biggest problem is actually whiteboard coding problems - nobody does that in real life.
We have a question on a quiz that we give to every potential employee that very reliably tells me early on whether someone is going to be a potential hire. It looks super technical, but in reality anyone should be able to work out a reasonable solution logically. I always ask the same question in the interview: "Walk me through how you solved the problem." Good candidates think past the problem to things like maintainability, really good candidates tend to ask for feedback on what the answer is.
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.
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.
Anyway, my anecdote: we were interviewing for a C developer position. The next candidate was in his 50s. Our project leader took a dislike to him the moment he saw his resume. No idea why but I assumed it was either his age or that this project leader knew him and didn't want to work with him for some personal reason.
The project leader arrived to the interview at least 40m late. In that time this candidate impressed me (as the C guy) very much and I said 'hire' immediately. However, as presaged, the project leader said no.
This candidate had no way of knowing what had happened. He definitely could tell I was impressed so he probably assumed it was his age. Just imagine how he must've felt. I probably should've contacted him to let him know how messed up the our process was.
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.
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
There are other professions with models of credentials that could be adopted to software given some time and adjustment and faith. Then we could shed our current technical interviews in favor of shorter interviews overall. You naturally need more people to handle interview bandwidth as your company grows.
People want to show some credential and not have to deal with technical interviews at every potential opportunity. We've learned enough about technical interviews that we should be able to make this kind of widely-recognized credential. We just don't want to do it. We'd rather keep recruiters employed and force developers to budget large blocks of interviewing time.
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?
The startup doesn't trust that Google's process is absolutely infallible, presumably. For good reason, probably; a bad hire is much more of an existential risk for a small startup than for Google.
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 :)
Either you will learn the skill enough or you will find a position that fits your current skillset along the way. Being understood by other people is where the rubber meets the road for ideas having any impact and communicating your technical ideas is an important skill in general.
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.
You make it sound like being a web developer at a non-FAANG is somehow different than being a web develiper at a FAANG. Regardless, you are going to be working on some permutation of a CRUD app.
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.
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.
No, really. In my case I went with white-green because I liked it. It was quite obvious that it made the bank employees feel unsure if they should mock me or if I was some sort of secret celebrity.
Every time I've seen this, the decisions to hire the outsourcing firm never really made sense, so the easiest guess to make is the managers were receiving some kind of kickback, but we can only guess.
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."
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.
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.
Never. If tech people can't find a way to do it there is no way a non-technical person will be able to. Pretty sure this is why Google has its own recruiters. Your average recruiter has no clue how to grade candidates. For other companies it's probably best to find a way to apply directly.
I recently went through the process and got a job from a direct application. I dealt directly with the tech lead. The process was entirely devoid of BS. We understood each other right from the beginning---perfect clarity. After the little bit of time I spent looking through job ads and dealing with recruiters I am endlessly thankful that I got this job before having had to deal with all that for longer than a couple of weeks. The difference was stark.
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.
Have them map out the answer on a whiteboard for one person who knows how bittorrent works and can nudge them along if needed. The idea is to see how well they communicate complex ideas, not how well they have memorized the bittorrent protocol.
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.
- 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.
In that case, s/dude/person/g
Language affects thought, right?
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?
Honestly I agree with your pain because the above situation is also not completely tied to how much you care. Luckily though, most of the time it is.
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.
When was the last time you worked within Google?
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.
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!)
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".
> 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.
This is a joke, but uncomfortably close to the way junior people interview:
https://www.reddit.com/r/ProgrammerHumor/comments/4k994j/if_...
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
It works remarkably well if you're flexible enough to follow it.
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.
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?
If only. It's more like a Wonderlic Test.
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.
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".
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.
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.