đŸ Archived View for dioskouroi.xyz âș thread âș 24911758 captured on 2020-10-31 at 00:44:59. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
I disagree with the article because author seems to miss the point of a lot of comments in here and is reaching simplistic conclusions.
Lots of people don't nag about whiteboard interviews at FAANG, I think a lot of people who are commenting here don't even send their CV to any of those companies. People nag about other companies using whiteboard interviews as some kind of "silver bullet" of hiring. Most of the time I see negative comments about it, it is that some small startup which is trying to get people to work below market price is grilling people on interview like Facebook or Google. (as a side note there is whole list of bad stuff that medium/small companies do just because "goog/fb does that", but they should never do)
Other negative that I see in discussions is, technical interviewers are assholes that want to show you how smart they are. Which FAANG interviewing style is helping to spread. Asking random algo question, that you know answer to and the person you are interviewing does not, makes it easy to feel superior.
Being thoughtful about hiring... Yes if hiring manager has resources to do that then he might build amazing hiring engine. Again most of the companies have scarce resources, and entrepreneurs probably spend more time on sales than on hiring, because you should hire only if you really have to. Probably hiring is also not their core business.
> as a side note there is whole list of bad stuff that medium/small companies do just because "goog/fb does that", but they should never do
Indeed. There is a great post about this mistake causing companies to do wrong technical choices titled "you are not Google". Worth a read if you're not familiar with it already (already been on hn twice as well).
https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb
Well, all that said, it's been interesting that no one has wanted to work with me. Frankly, it was shocking, as I definitely have the skills, experience and "soft" skills, like Accountability and Responsibility, as well as years of experience at selling difficult projects to real hard-nosed, empirical managers.
I also would have been quite willing to work for a fraction of what people that don't have my chops would want.
The worst was working with recruiters. They are downright insulting. Quite jarring.
Whiteboard/LeetCode tests are a flat-out insult to me. I won't do well at them, and I'm quite aware that people spend _huge_ amounts of time, practicing for them, so I don't have a chance.
I do have a few hundred thousand lines of code, dozens of blog articles, dozens of repos, and a decade or more of checkin history. I've been told that I "faked" it, which would be hilarious, if it weren't so insulting.
In the end, I just decided to stop looking for work, and I'm working in a small startup team, writing some fairly powerful software, for free; because I enjoy doing this stuff.
It's pretty odd that the current scene is actively hostile towards folks like me. I feel that it's fairly self-destructive.
I'm a little confused by your post. Why do you think you've been singled out and nobody wants to work with you? Simply because you don't excel at whiteboard coding or leetcode questions?
I'm honestly curious. I have never had to really do either of those things in order to get great jobs that pay quite well. Granted, I don't work for a FAANG, haven't even interviewed for one, but I don't feel any less successful even so.
I'm tempted to think you come off as difficult to get along with, but this is entirely based on your writing style here and may be entirely unwarranted :). I've always found that being agreeable helps an awful lot.
I'm a bit embittered. It was a real shock, encountering the new environment. I rapidly learned that it's important for hiring managers to establish dominance in the relationship, which doesn't work so well with people like me.
I made the mistake of working for a company for 27 years, and the culture changed drastically, during that time.
I am a very good person to work with. My LI profile is filled with testimonials as to what kind of person I am. I just believe that humans are very important, and that seems to be an "outlier" philosophy, in today's tech scene.
You and I would be fast friends, I think. I've been talking about empathy at work, and I feel like it's a new concept for some.
In a normal friendly conversation itâs very rare for someone to openly accuse another person they just met of faking their job history or something similarly serious.
"Normal, friendly conversations" don't seem to be normal, in today's world.
Things have changed.
https://www.youtube.com/watch?v=L9EKqQWPjyo
I've also been accused of faking things that I definitely did do myself, sometimes I find myself unconsciously playing down accomplishments so as to not to be accused of fakery.
What you can keep in mind is that there are very large amounts of money at stake for software engineering jobs. So it is magnet for every kind of faker you can imagine. So don't take it personally, just be thankful that you are qualified for a job that many people _wish_ they could do.
And yes the whole thing is a game. The people who are good at the game are most likely to win. So just learn to be good at the game.
I hadn't thought of tech jobs being a target for fraud but it makes sense. Candidates will always test the market for how much they can inflate their experience.
Iâve been a hiring manager for a few roles. Every one that was posted publicly received approximately 20 applicants that were obviously not suited to the role for every one that was.
This is exclusive of any level of seniority, which I like to be flexible on where I can.
While I wouldnât say this is fraud per se, the candidates were obviously using a shotgun approach to apply to any job in the industry.
I was a hiring manager for 25 years.
I never gave one single test, and I could usually weed out the spammers from a quick glance at their résumé. I often hired folks that didn't "hit all the sweet spots" on their CV, because I found them to be eager, energetic and curious.
Had a couple of bad decisions, but very few.
For the opposite perspective, I work at one of the FAANGs and I've given about 200 interviews. A mix of initial screening interviews and full evaluative interviews. At the screening stage I've interviewed several people who looked great on their resume and were really good about talking about programming and what they liked, but couldn't code even my warm-up problem on the whiteboard. These weren't people who were too anxious to code well in this setting, [1] these were experts in BS. Because the company is very careful/ slow to with firing people, which I generally think has really positive effects on employee well-being, hiring someone like this would be really bad.
Much less extreme, but I've also seen many people who looked very similar in their resumes but were worlds apart in how the coding interview went. Some of them could quickly flush out specifications, asking good questions, talk about why they want to solve the problem the way they did, and fluently write code, while many others struggled in different areas or sometimes all of the areas. This is also really important for figuring out which of them we want to hire, and how badly we want to hire them.
How the interview is run matters a lot, and also what sorts of problems you choose. I think it's really important to choose problems that aren't essentially spending 45 minutes on one narrow knowledge test (especially of the "have you already seen this before" variety), but instead test as many aspects of the person's skills as possible. I want to see how they handle incomplete requirements, simple design, thinking about how to create an output format that is maximally useful to a consumer on another team, naming things, thinking about the runtime of different approaches, thinking about big-O space usage, thinking about back of the envelope space usage in bytes, coding, thinking about edge cases, etc. If I had more time I would want to check code reading, testing, and debugging as well, since these are so important to being an effective programmer, but they're unfortunately much slower to evaluate.
[1] I've interviewed people like that as well, and within the confines of the interview I've been asked to run the best I can do is note that I don't think we're able to evaluate them well this way.
Thanks for sharing that. I am most interested in working with folks where I can make a difference; not just be a coding cog.
I'm spoiled. In my open-source work, I've done some fairly significant (but still below-the-radar) stuff, and got used to basic, simple, respect; without people trying to wrestle me into some kind of subservient role. That's not to say that we didn't have disagreements. Quite the opposite, in fact. I've done Service for some of the most disagreeable people that you can imagine, and left them happy and enthused.
So I actually looked at a few startups. I have a fairly unique conflux of skills and experience that could make an _enormous_ difference in small teams. What I found, is that they imagine themselves to be "mini-FAANGs," and treat their prospects pretty badly. I know that startups tend to have rather chaotic, personality-laced workplaces (see "working with difficult people," above), but if they can't keep that crap out of their triage interview, then the place, itself, must be a nightmare.
I'm working for free, for a friend. I stepped in, because I watched him being set up by contract houses that were obviously going to do very bad work, for lots of money (they barely hid it; I guess because he's non-technical, and doesn't know better). Since he's doing an NPO, and looking at grants for funding, he can't afford that kind of object lesson.
Instead, he's getting a platform that would make a lot of "big houses" green with envy. For free. This is something that I have a lot of prior art in. It's already pretty awesome, and I've only been working on it for a month.
There's a lot to be said (and gained) by simply treating people with basic respect, and motivating them. The workplace is not the military. If we treat our employees and co-workers badly, they won't stick around. If we treat them well, they could do some pretty amazing stuff.
I'm curious as to whether other roles and industries see a similar signal to noise ratio. I wouldn't be surprised if a lot of people are just applying to every job that's listed in their current location or where they want to live.
Recruiters and LinkedIn make it worse. LI has some very spammy features they sell to recruiters, based on keywords and tags.
I'm a native Swift developer, with over 30 years' experience programming Apple devices, but I have also written a lot of PHP (backend) stuff, and Web sites.
A few years ago, I spent a few months, learning Android, and decided I didn't like it, but I do have Java and Android Studio in the mix.
I often get recruiters, trying to match me with Web design or C# (nowhere in my stack) jobs.
I spent the first part of my career as a network engineer, moved into management, started doing "cloud" stuff for whatever that means, and have very obviously not been an IC for a long while. Been in the bay area tech scene for over 20 years.
I'll still get pinged by recruiters for a senior network engineering job in Idaho or some such.
I'm in somewhat the same circumstance. Have had a very successful 15 year career until this last iteration of job seeking. In all this time I never bothered learning the grab bag of tricks for mathematically optimizing recursive algorithms because it never came up in the many thousands of lines of codes I've written or code reviewed. I've learned many other hard problems and I can usually run circles around all the super smart new grads with their memorized algorithms, but it doesn't seem to matter now.
> I'm working in a small startup team, writing some fairly powerful software, for free
If you don't mind my brusqueness, how are you feeding yourself?
Savings (not like I have choice). Iâm also looking to establish some cred that just canât be ignored. Iâm fairly good at that kind of thing; it just takes time.
In the USA, do most companies whiteboard/LeetCode? In Canada, it seems that only a minority of (admittedly top) companies do. At least up here, not being able to do algos is a barrier to top tier employment, but certainly not employment in general.
In the SFBA, it's almost mandatory for every company that I've interviewed at. (100+)
The rest of the country has high variance. It will also depend on the company you're targeting. A lot of target companies have a leetcode interview style (I presume every other interview style has too high of a pass rate).
The ones that matter do.
Why not try to get better at whiteboarding?
Not the OP, but I've reached a similar place to the OP (I've given up looking for paid software engineering work for now). Why not get better at whiteboarding? Because it's only useful for getting a job in certain types of companies. It's not a useful skill in doing the job. People spend hundreds of hours practicing to answer whiteboard interview questions - more power to them if they actually need the gig really bad. I just don't want to play the game anymore. Fortunately, there are companies (usually small ones) that aren't obsessed with whiteboarding - my last few gigs have been at places like that. Usually the hiring folks are older (as am I) and they remember what hiring and interviewing were like 20+ years ago.
Some sort of peacocking isn't useful for maintaining a good relationship with a mate, but it's usually important for _getting into_ a relationship... The same thing goes with whiteboarding and interviews.
Because every second that I spend on small-batch academic exercises, is a second not spent working on ship code.
Here's how I spent today:
I woke up at 5AM, like I always do, and did my two-mile walk. During the walk, I sorted through today's job. I'm working on a social media app, and I'm setting up the baseline (admin) stuff. I needed to add the capability to convert "standard" users to "manager" users (and vice-versa), and I'll also need to add UI in the app (native Swift iOS/iPadOS/Catalyst app) to manage permissions.
I figured out how I would do it. It was a combination of work on the backend (I needed to add some functionality to the admin user layer), the SDK (I needed to add a couple of methods to funnel the UI requests to the REST API), and the app, itself (I needed to add a button to the user edit screen). The tricky part would be the backend work. I needed to do this in a manner that would not invite any security compromises, and would catch errors. I also wanted to leverage the current structure, as opposed to introducing new structure.
Also, I was a dumbass, and used Git submodules in the backend (it's a "layer cake" model). That makes modification a pain.
I don't write stuff down, if I can help it. After my half-hour walk, I knew what I needed to do, and, by 7AM, I had the basic framework in place on the backend. I couldn't test it until I also had the work done on the SDK, so I started that (it wasn't much code).
Since I wrote the backend a couple of years ago, I also spent time, groping around, re-learning it, and getting my head out of "Swift Mode." The biggest mistake I make, is forgetting to end lines with semicolons.
This is where my extremely disciplined coding standards pay off. 99% of the time, I'm the poor schlub that needs to relearn the code, so I make sure that I structure and document very well.
By 9AM, I had the whole stack in place, and there were a number of bugs. I like to test, so I was able to figure out where they happened. Most were in the backend, so I spent a lot of time with Charles Proxy, examining the exchange. Some of the bugs required a fairly substantial architectural change. That's pretty common, so I write in a layered, modular fashion with lots of hooks. Makes that kind of refactoring go smoothly.
By 5PM, I had it all working, but I need to make the app UI better. It needs a confirmation alert. Otherwise, it's pretty much done.
Tomorrow, I'll add the confirmation, and do a lot more testing. This is fairly critical stuff. I can't afford any security lapses here, and I need to make the UX as smooth as possible. Because of the nature of the work, I need to figure out the best way to provide instantaneous user feedback, while waiting for the server to do its work. I'll hammer that out in tomorrow morning's walk. I still need to do the permissions UI, but I won't get started on that, until I'm satisfied that the privilege swap works 100% (I don't move on, until I'm satisfied that my work is at "beta" level, or better).
And I spent absolutely no time at all, practicing LeetCode.
why is shipping code more important than practicing leetcode though if your goal is to get a FAANG job?
if you're struggling to find even a non-FAANG job but no one wants to work with you - perhaps you aren't as good as you think you are at the things you've mentioned.
not trying to be hostile at all here, just giving you my honest take.
> perhaps you aren't as good as you think you are at the things you've mentioned [...] not trying to be hostile
I am trying to go through _every_ possible interpretation I can think of in which saying something like this to _anyone_ isn't hostile, and I'm coming up empty.
Could you elaborate how it isn't?
It's confrontational, but there's a big difference between that and hostile.
If a person is consistently upset about not getting what they want, but also not willing to change what they are doing, that person needs a breakthrough. "Maybe you're not achieving your goals because you're not as good as you think you are" can be really useful feedback for someone who is stuck like that. I've both received and given that feedback in an athletic context, for example. It's rarely welcome in the moment, but that doesn't mean it is intended to cause harm; quite the opposite, usually.
I don't need a "breakthrough." Accepting the status quo was one of the happiest moments of my life. I really don't want to work with people that don't want to accept me for who I am; which is a person that will deliver _extremely_ good work, for fair, respectful treatment. I'm an outstanding team member (you don't last long at a Japanese corporation, unless you do "team" well). I'm optimistic, energetic, and affable.
I've found people who want to work with me, working towards laudable goals, and I do work that I love. I won't starve to death, and there's the very real possibility that what I'm doing will end well. I'm pretty good at what I do, and what I do, is make stuff that works.
It gives me the luxury of saying "Guv! Why's that chap in the crown starkers?".
Whenever there's a back-and-forth about LeetCode tests, it eventually gets down to "Well, I was hazed, so you get hazed, too."
That sounds like a sensible baseline for selecting engineering staff.
My God. Why would I want a FAANG job? I'm quite aware of the environment. I'd rather bang rusty carpet tacks through my thumb.
I like coding. I want to enjoy what I do. That's the single most important thing in my life. I spent thirty years, dancing to the organ grinder. I spent most of that as a manager, which wasn't fun.
As for how good? Feel free to look for yourself. I am an open book.
I think I'm starting to understand.
:)
Feel free to write me off. You probably wouldn't like working with me.
Why do you feel whiteboard problems are an insult? And why do you feel you don't do well on them?
Just because others spend a ton of practice on them, didn't mean you don't have a chance.
Because most are "young-pass filters," and that makes itself obvious, as soon as I see them. I've learned that when I see a binary tree question, I might as well just wrap up the interview. They have no intention of hiring me.
I am mediocre at them. Most represent stuff I haven't done. A lot of it is common sense, but I'm solving them for the first time, so my approach is usually sub-optimal (I tend to start with naive approaches, then refine, if necessary). The testers are usually looking for a formulaic approach. A lot of my approaches are orthogonal to the "classics." I started as an EE, so I'm pretty good with things like drivers, SDKs and APIs, but they aren't really something that you can do in a 50-line test.
What's really insulting, is that when I'm asked, I usually send links to relevant gists or repos; often focused on the exact method that addresses the question asked.
It's ignored (so far, 100% of the time -the "faker" comment was made by someone that was explaining why they ignored it).
Diversity. We really, really suck at diversity. Weâre getting better, but we have a long way to go. Most of the industry chases the same candidates and assesses them in the same way.
What about neurodiversity and hiring neuroatypicals? "Culture fit" is often a euphemism for discrimination against them and others with poor social skills.
Also, call me cynical, but I've come to view blogposts like this as little more than marketing for the author and whatever company they started/work for. They're always vague, self-congratulatory, studiously avoid saying anything genuinely controversial, and to the extent that they're critical, it's often just as a way of contrasting themselves with the competition.
Cultural fit sucks, but working with developers who cannot communicate clearly and effectively also sucks.
The "how to interview" discussion must always focus on what sucks less as the whole framework of thinking sucks here.
There are plenty of neurotypical developers who can't communicate clearly or effectively either; I've sat through enough presentations and design meetings over the years to attest to that. Therefore, it's not a good disqualifying criterion.
While of course there are limits, why turn away a good engineer when all it costs you is a bit of patience and accommodation? It's not like talented people are easy to find.
Everything I've seen suggests that neuroatypicals are over-represented in tech relative to the wider population. I'm not saying there isn't anything more to be done for them, but I expect they're still going to have a more welcoming environment in tech than just about anywhere else.
The industry isn't nearly as accepting of them as it was ten or twenty years ago.
To those downvoting: if Linus Torvalds was 30 years younger and just as competent, yet completely unknown, do you really think he wouldn't have a lot of trouble getting hired at a FANG company because of his poor social skills?
If you mean that the industry is less likely to allow a self-diagnosis of "it's the autism" as an excuse for sexual harrassment, sure.
Why do we need diversity if it is more or less the same job? you need people who can do the job and it is likely they will have some common traits
The article explains in detail how a pressure difference can create a force, and how the process generates these differences and how the force is felt as suction, but still argues that the process doesn't suck.
A process good at testing applicants should 1) identify the good ones and 2) identify the bad ones. The standard whiteboard interview makes no attempt at (1) and works by throwing almost everyone in bucket (2) regardless of potential.
This is plainly, in general, a process that sucks. It just happens that the way it sucks is not a problem if you're FAANG.
You're exactly correct, and the complete lack of attempt to do (1) means that if you're a perfectly qualified candidate, then getting an offer is very much a crapshoot. It's actually quite easy to get into _a_ FAANG company overall, it's just difficult to get into a _single specific_ FAANG company on a single try. The interviewers are mostly not good at interviewing and they'll just let you in as long as you can solve their little toy problems the way they would solve it. Sometimes it's easy enough, and other times your luck runs out.
>means that if you're a perfectly qualified candidate, then getting an offer is very much a crapshoot
This is the most annoying thing. I've got a code test on Friday. This life changing pivotal moment comes down to little more than whether or not I've seen the problem before. If I have, great I nail it and get the job. If not, well, I don't. So arbitrary.
As an interviewer at one of these companies, I try really hard to only ask questions that people will not have seen before. I agree that if you're asking a question which some of your audience has heard and some hasn't, that's terrible for the interviewee, but it's also terrible for the company.
But you can't really. There's what? Hundreds or thousands of these tests happen everyday. It's impossible for each one of them to be unique. They're all just variations on maybe a few dozen to a couple hundred core questions.
All design-algorithms-code questions are variations on a few dozen to a couple hundred core questions? In a way that regular programming is not?
For most programming very little time is spent on actually implementing algorithms. It's more about designing and organizing your code and data. Few people are sitting down for 8 hours a day and banging out leet code style algorithms.
The fetishization of Google (specifically their interview process) has really hurt the industry and caused a lot of unnecessary stress for a lot of engineers.
Agreed, lots of companies have Google style interviews when they are clearly _not_ Google.
You better have quality work to do and equivalent perks as Google to put candidates through their style of interviews.
Otherwise those companies are delusional and I have the world's smallest violin for their recruiting woes.
If you interview like Google, you better pay like Google.
> pay like Google.
So notoriously low that the CEO had to approve a company wide raise of 10 percent one year?
To "pay like Google" compared to industry in general and to "pay like Google" compared to the places Google is competing for hires with are very different things.
is great for understanding what statements like "pay like Google" etc mean.
(I've entered my comp there)
I guess people didn't quite get the reference:
https://www.cnet.com/news/google-gives-employees-10-percent-...
From 10 years ago?
I think one of the main points of the article that the discussion here misses is that whiteboard interviews can be seen two ways: as an 'exam' where there's a 'right' way to behave/solve the problem and as a 'simulation' where the point is to simulate a situation of working/problem solving with the candidate.
If the interview is explicitly run as a simulation, where the hiring team looks for good _behaviors_ (both in attitude and in problem-solving) and not necessarily good _outcomes_, whiteboard interviews work well, because: a) they scale and, b) they can actually be good simulations of a high-stress environment. The downsides are that they become subjective, unless the hiring team is experienced/has been trained well.
I want to be clear that by "the standard whiteboard interview" I mean a certain format that's been roughly standardized at FAANG and copied out-of-context by a major chunk of the industry. It's a starter question, then a harder question, then another if there's time; each is answered with an algorithm written on the board in mostly-valid code. Your on-site loop (pre-2020) is four to six 1-hour sessions back to back, plus a lunch break.
The only work environment it simulates is one where every feature is developed in a 15 minute sprint that's literally overseen (like over your shoulder) by a boss who's put you on a PIP; there's no collaboration and no google; nothing is expected or allowed from you except a working output; and you're fired if there's any issue raised in code review.
It's more like an exam, but it's not even that: exams are meant to see what you know. The whiteboard interview just offers you as many ways to fail as possible and sees if you make it.
I wouldn't really say it's either one. I hesitate to call it hazing, but... as a trial to prove your dedication to the group by doing arbitrary and unpleasant things, for some it feels similar.
Maybe we need to shift focus to lowering the cost of False positive? The industry is willing to skip ton of great candidates that fail the "audition", just to avoid false positives. Otherwise great people and employees are ruled out, just because they can't reflect their true value at work in a stressed 1-2 hours interview. Cheaper false positive hiring may ease the pressure on the companies side to let them in. Having said that, because of stress, questions on interview should be 50%-60% difficult since the interviewee is not at 100%.
> Maybe we need to shift focus to lowering the cost of False positive?
Other things being equal, I would rather more stress in a handful of days of interviewing than more stress about whether I keep a job I "have".
The author contradicts himself in trying to argue that hiring isn't a crapshoot. On the one hand, he says the best hiring managers "didnât chase the same pool of candidates everyone else was chasingâinstead, they found non-traditional ways to discover really talented and motivated people who werenât in the pool of usual suspects". But then in the _very next paragraph_ he cites Google, Facebook, Stripe, and Dropbox as examples. Huh?
It's so misleading to cite BigCos as examples of excellent hiring, because the founders of the companies and the initial employees are never hired in the same way that their engineers are currently hired. They're usually just people who happened to know each other in a dorm. It's only after the company gets a bunch of funding that they need to fill seats with a bunch of warm bodies. But the success wasn't because of the assembly-line style hiring, it's the product idea and the personal qualities of the founders that drove the success of the company. Engineers throw themselves at those companies because of the compensation and prestige. It's not because they have a magical snowflake hiring process.
I think he's saying that Google at a certain point in time managed to hire the talented & motivated people. So it can be done, because these companies have done so successfully at points in their past.
> Google at a certain point in time managed to hire the talented & motivated people
Google started with talented and motivated people.
They also hired talented and motivated people, but that in itself is not proof of anything. Did they hire talented and motivated people _because_ of their hiring process, or for other reasons, such as that Google is a place where a lot of talented and motivated people really wanted to work?
There are different spins you could put on the hiring process: (1) it's extremely difficult in order to pick out "the best" engineers or (2) it's extremely difficult in order to pick out the engineers will do anything to work there.
> "_Did they hire talented and motivated people because of their hiring process, or for other reasons, such as that Google is a place where a lot of talented and motivated people really wanted to work?_"
I might be misremembering but I seem to recall that Google's hiring bar in the early '00s, before they grew into a behemoth, was even higher than it is now. If you weren't from an elite CS program with near perfect grades, they wouldn't even look at you.
> Google's hiring bar in the early '00s, before they grew into a behemoth, was even higher than it is now
My point was that why would any candidate put up with Google's hiring crap if they weren't already extremely motivated to work at Google? Especially if you had other choices.
No-Name-Company could have an equally high bar to hiring, but they wouldn't be able to fill any positions, because candidates would just tell them to get lost.
_My_ point is that Google wasn't special or a clear winner in the early '00s and there were plenty of other equally hot choices, like Yahoo, so Google's candidates weren't "highly motivated". Contrary to your assertion, their early hyper-selective hiring process worked just fine for them in getting them the highly talented engineers they needed.
> there were plenty of other equally hot choices, like Yahoo
That's one. And if you admit Google was a "hot" choice at the time, that already makes my point.
> Google's candidates weren't "highly motivated"
No?
> Contrary to your assertion
I'm not sure what you take my assertion to be, but let me clarify. My assertion is that if a workplace is "hot" for whatever reason -- rapid growth, high compensation, world-changing product, number of users, prestige, etc. -- then a large number of good candidates will apply there, and almost any hiring method will probably work out for them.
When you talk about Google hiring only from elite CS programs, it's crucial to note that Larry and Sergey came from Stanford specifically, so of course they're going to hire people from Stanford. That's always how it goes, as I mentioned earlier with founders and early employees. Let's not pretend that's a "hiring process". It's a personal network. A number of other people from Stanford were also early Google employees. Scott Hassan, et al. They got seed money from the co-founder of Sun Microsystems. The next year, they got $25 million in VC. When I was in college in Wisconsin, there was nobody around to fund anything! Almost all of the big tech companies were built from informal personal networks, and they only institute a rigid hiring process after they're already somewhat successful. Again, any no-name company can have an ultra-high bar for hiring, but that doesn't magically attract candidates willing to apply and put themselves through hell to get hired.
Another benefit of whiteboard interviews that I often see left out is how well they scale.
You can train a lot of engineers in how to conduct these interviews fairly quickly and you tell them what information to focus on and how to document it. You can then pass this information to a hiring committee that has a _lot_ of experience in evaluating candidates. Having sat in on some hiring committee meetings I can see how little weight is given the algorithm _if_ the candidate has a good reference or highly relevant experience.
The issue with the interview alternatives that most people suggest is that they would require your most senior engineers to spend a really really large portion of their day on hiring which can burn people out quickly.
My main issue with whiteboard interviews is that they often ask you to code something that is completely unrelated to the job, and is not representative of your normal work efficiency at a task that is within your area of expertise.
For example, I've had several machine learning engineer interviews in which I was asked to write some variation of NMS (non-max suppression) or gradient descent on the whiteboard. What machine learning engineer writes that kind of code anymore?
I can write it, yes I can fumble (a lot) and figure out how to optimize it, but in reality these are the type of algorithms that you _almost always_ use some library that someone has already written for you for that kind of stuff. They spend the entire hour nitpicking at your implementation of NMS, base their entire impression of you on that implementation of NMS, and never in your entire interview ask you anything about, say, what the state-of-the-art object detectors are, what their breakthroughs are, how their networks are roughly structured, what you might think about doing to improve on them, what you could do if you only had limited annotation data, and other real machine learning questions.
Actually evaluating your knowledge is hard. Picking something to be a rough litmus test and testing that, despite it not being directly related to the job seems reasonable.
It has been 3 years since I interviewed somebody for a ML position. Mostly I focused on knowledge of model execution. Most ML libraries were horrible for use in production at the time and I was more worried that a candidate wouldn't be able to productionize a good model than I was worried they wouldn't be able to build that model.
> "_Having sat in on some hiring committee meetings I can see how little weight is given the algorithm if the candidate has a good reference or highly relevant experience._"
I've sat in on a fair number of hiring committee meetings over the years and have only seen the opposite; poor performance on the testing is a disqualifier no matter how good their references or credentials are. Even the FAANGs make hiring mistakes so credentials don't mean much.
As somebody who's somewhere between mediocre to good at whiteboard interviews (passed the loop at 1 FAANG, rejected by the rest), I think they're pretty solid. Most programming challenges, even at FAANG-scale, ultimately decompose into some family of classic interview problems (usually a graph or a hash table.) Everything else I do at work is implementation or stack specific. The average programmer will pick it up with enough exposure. But problem solving is somewhat binary (yes I realize thats an oxymoron) and not easily pick-up-able, at least on the time horizon a hiring manager wants to deal with.
I realized this when I got a lot better at whiteboard interviews after a FAANG job for a couple years. A coding challenge that I took the full hour on and bombed out of college was now done in twenty. I just picked up the problem solving intuition by writing a ton of code.
How much code do you normally write on whiteboards in front of people? It is such an artificial and for some, confrontational, way of problem solving, that it just filters for people who can stand in-front of whiteboards. It's a discriminatory process that shows pretty much nothing about the individual's capacity to function as a software engineer in a team.
I disagree. It doesn't have to be confrontational if you don't want it to be. As a manager whose used it plenty in the past, I've found it to be an excellent tool to filter out people who were smooth talkers and seemed "clued in" but didn't have the technical chops to do anything. I didn't care at all about syntax, language of choice, or anything superficial like that. All I wanted to see was how they approached a problem, not that they simply memorized a piece of trivia. Also you can ask design or high level architecture questions during a whiteboard-interview too. I have found that simply trusting someone's word is not enough, you need to verify that they can actually back it up. In the end, resume, grades, side-projects, whiteboard code, style of problem solving, feedback from previous co-workers, etc, etc, are all signals that you have to absorb and make a decision. You can't just rely on one signal.
I realized 4 years of teaching in grad-school precisely prepared me for whiteboard interviews. I literally spent 3 days a week working out problems on whiteboards in front of bored/annoyed people.
Good practice, yes. However what if those bored/annoyed people decided you were a failure and couldn't feed your family if a single unseen problem is not done in 15 minutes?
Ultimately, I'm not sure what form of interview process would satisfy you.
A work sample test set that is restricted to material relevant for the job you are doing? Only writing code on a laptop text editor?
Ex: Code this mini app, code this mini api, figure out why this code is buggy, design this app / backend service that does this, why did you choose that, etc.
When I started my career a simple interview and can you start Monday sufficed. Youâd be be let go by Wednesday if you couldnât produce. Iâd return to that, it worked. Perhaps with a few harder questions about hexadecimal and a code review.
Many people move across the country or even between countries for these jobs, especially to the SF Bay Area. You want more assurance than that before you uproot your life.
Additionally, the time to spin up at a mature company with it's on tooling and enormous amounts of existing code can be really long. I don't think you can generally tell in two days whether a person is going to do well.
If you can do common things well, you can learn a codebase.
Remote contracts are a thing as well.
I'm not sure international hires are relevant to the discussion, they are at best a sliver of the whole.
It's not a question of whether it provides a perfect signal. It's a question of how the signal it provides compares to alternatives. Say what you will about whiteboards, but every other interview structure has its own issues, including being artificial, particularly at scale.
Not every approach is bad. As an interviewer myself I find that just talking to the person as a human being and asking them about their current work, previous work, and interests tends to expose nearly everything I need to know. I initially just want to see if the person is likely to be a good fit for the company. This can be triggered by attitude, arrogance, etc.
Engineering-wise I can focus on any one thing they bring up and ask them to explain in more depth, this then becomes a dialogue, which is vital I think, because they're interviewing me and my company as much as I am interviewing them. I intentionally don't try to catch them out, in fact the opposite, a candidate at ease is the one that opens up more and will give you more insight into who they are and what they are about than any whiteboard exercise.
I'll then talk about the requirements for the role they're applying for and try to see if their knowledge covers what we need. Again, just a dialogue.
If that first interview goes well, then I will ask for examples of code they have written, or set them a test to do in their own time if they have nothing of their own to show. Granted that takes some of their time, but it only happens if they're being seriously considered, and importantly (I think) allows them to use their own tools, in their own time, in their own way, this gives them a chance to shine.
This might not work at FAANG scale, I dunno, I find the idea of working at any organisation like that a pretty miserable one. But talking to someone in a respectful way, rather than putting them in an uncomfortable situation that bears no resemblance to what their day-to-day would be, shouldn't be hard to scale.
Although, I suspect much of these issues come about because of the inadequacies of the interviewers rather than the candidates, they're hiding behind tricks, gotchas, and memory tests, because possibly they don't have the range themselves to extract something meaningful from the candidate in order to rank them.
Exactly this. This has been my approach for a few decades and it works wonderfully well. Making the interview cooperative instead of confrontational is important. The key to success is evaluating the person based on their actual experience instead of their inability to do some whiteboard monkeydance that's completely unrelated to the job.
This is almost exactly my approach. Iâve interviewed 100-200 engineers in my career and hired 10-15 of those. Not one of those hires was a failure and I didnât need to incorporate puzzles as part of the interview process. If youâre an experienced engineer with a history of designing and delivering business solutions for multiple domains you should never need to ask trivial data structure and algorithms questions that can be easily looked up if theyâre ever needed.
If a doctor can be interviewed without being asked to operate on people, or an architect without being asked to build a home, can we not interview without asking someone to write code?
I'm not super familiar with doctors' career progression but as I understand they have a residency which is basically a super long training / interview. And I bet to become a surgeon at an elite institution you have spent a lot of time being watched doing your job.
Also another good example is cooks, who get hired based on working a shift unpaid to see how they fit with the team.
Asking for a hands on demo is pretty common.
The important distinction here is that a doctor has to complete a residency only once in their lifetime, not every time they apply for a job.
Sure, but residency lasts 3 to 7 years and it is often harsh. I'll take the whiteboarding anyday.
Moving to a doctor-style credential model would probably make the interview process less intense. But it also adds years of additional education and certifications. And it's unclear whether it would cause a net reduction of stress and pointless studying: pre-med and medical students aren't known for their laid back progression to gainful employment. A lot of the people here would clearly be shocked to discover just how adversarial jobs outside of software engineering can be.
Honestly I think this is a poor analogy. It's considerably easier to verify the work history of a surgeon or an architect. Their work is prominent and difficult to plagiarize.
Trades might be more applicable, and in trades you likewise have certain kinds of certification or even a guild-like system to keep skills and performance visible and consistent. There's not really any equivalent in programming (though there is in IT more broadly). Even a university degree is not really any particular proof of an ability to code, a lot of programs can be taken without having to write much code solo.
Programming is usually done collaboratively, either implicitly (through the use of base libraries) or explicitly (coworkers, group projects) and there are definitely people who freeride on those collaborations to a great extent.
> Most programming challenges, even at FAANG-scale, ultimately decompose into some family of classic interview problems (usually a graph or a hash table.)
Most problems decompose into _using_ a graph or a hash table (or an array), not implementing one. And the hard bit is usually things like translating the business requirements, architecting code to keep it maintainable over time, and dealing with buggy / opaque 3rd party systems.
Classic whiteboard interviews don't test these things at all.
One way to look at it is that your ability to contribute is one part familiarity with the stack, the problem domain, and the company's development process: one part "generic ability/competence".
You're going to learn the first part on the job. It's rare - especially in Google's hiring - that you want to hire someone for their deep familiarity with the tech stack or problem domain. So you select for the second part.
But your test for the second part still involves specialising in some process. Take home tests or pair programming exercises aren't "culture-blind" any more than whiteboard tests. So a large important part of the industry standardised on a "development process" of writing code on a whiteboard, a "business domain" of advanced-undergrad-level data structures, and a "tech stack" of "pick any language you want, or a reasonably rigorous pseudocode". If everyone learns that to the same degree, the remaining differences between the candidates are mostly in part 2.
There are some downsides that get trotted out on HN every time: you may reject someone who's really good but didn't take the time to focus on undergrad data structures, you may reject someone who is particularly bad at whiteboard stuff (typically due to nerves), your process is easier to train for recent CS grads from good universities. But every system has downsides. This one is reasonable for Google and not-terrible for you, but you may be able to do much better by focusing on one of the sets of people Google's process underrates.
So, in my job, I've had a few, rare reasons to actually push into developing new algorithms for problems nobody has had to solve before. Literally nothing I've had to do for leetcode or whiteboarding has been useful there.
The more common instance I've had to do is plug-and-play existing algorithmic design on existing data structures that are well-represented in libraries. Need a hashtable or an auto-growing array? That's in virtually every standard library. Balanced search trees are also pretty common, although (in my experience) actually quite rare in practice. Graphs are usually not in standard libraries, but graph libraries are pretty standard in languages: there's petgraph in Rust, Boost has graphs in C++, and Python has networkx. Just pop those libraries in, and you don't need to bother implementing anything basic like traversals.
The only things exotic enough that I've had to personally implement them myself are Johnson's algorithm for elementary circuits and the union-find datastructure. Both times, I've had the algorithm in pseudocode right in front of me when writing the code, so I've never had to actually memorize how these things work.
> I realized this when I got a lot better at whiteboard interviews after a FAANG job for a couple years. A coding challenge that I took the full hour on and bombed out of college was now done in twenty. I just picked up the problem solving intuition by writing a ton of code.
Were you perchance interviewing others while at FAANG or doing anything related to interviewing (speaking with coworkers about it, etc.)? I've seen plenty of people come out of FAANG worse at interviewing than they went in.
The problems I've heard most of my peers solve at FAANG are not really that relevant to interviewing. At least, none of them are like, "Yeah, man, totally kick ass at leetcode now that I've been at Facebook for a year!"
My interviews were far and away the least thoughtful hiring experience Iâve ever had. It was clear each person was filling out a form while I was talking, and followed up with pre-written questions. There was nothing non-traditional, and the 6 hour loop definitely did not respect my time. ~50 hours of prep, 10 total hours of interviews ( 2 hours of screening, 6 hour loop, 2 additional interviews for other roles).
I had really great interactions... after the forms weâre filled out. Interviews went well - I was put into the ârecycleâ status but never found a role there that really fit my experience.
Nontechnical but still tech consulting, not aws.
I passed the phone interview for an Amazon position a few years back and when the hiring person told me that before the next interview I'd have to come up with stories for 14 principles (I thought it was 14 not 12?) I thought in my head "This is a cult" and then politely told the hiring manager no thanks.
I donât work at Amazon, but have many close friends who do. The 14 LPs are a strong attractant to me, especially since itâs obvious how they actually use them day-to-day instead of just being posters on a wall somewhere.
find a friend whoâs spent time on hiring, and ask them for their favorite battle story.
Anyone here have good hiring stories?
A former job of mine forced candidates to fill out a form for one of those abominable HR candidate tracking sites, maybe ICIMS, and I saw the following gem from one applicant:
Q: "One of CompanyCo's core values is Openness. How have you demonstrated openness in your career?"
A: "I am open about my contempt for bullshit questions like this one."
It's a story I've been told. Candidate is being interviewed for a senior position, there are three employees conducting the interview: one HR rep, one (non-technical) manager and one senior engineer.
The engineer supposed to help with the interview arrived late so the HR rep and manager briefed him, basically telling him the interview was going well and that they were considering hiring him unless he had any objections.
Going back, he asked the candidate a simple Fizz Buzz question, something like finding the largest element in an array. All hell broke loose suddenly. He was outraged and started telling them that, back in his country he was a university professor and that this was beneath him. The interview ended with the candidate arguing for 10 minutes that he shouldn't have to do this test. If I recall, at this point the senior engineer just left the room and didn't bother with the remaining 15 minutes of the interview.
Needless to say they didn't hire him. HR was shocked as he seemed to be a great hire.
Fast forward a few years later, I'm the one interviewing and I systematically get great resumes who can't implement a simple version of word count in 30 minutes.
We make business cards sold online. _~Half-billion-USD/yr_ of them. Literal sheets of uncut cards are under glass in the interview rooms.
Final round with a candidate whoâs ânear the bubbleâ. Me: âDo you have any questions?â Him: âYeah; have you guys ever thought about selling business cards online?â Me: âUh, weâve uh, given it some thought.â To this day, Iâm not sure what he thought we did.
At a university recruiting event I asked one candidate if he was willing to move to NYC to work with us. Most people say yes, a few say no thanks and move on.
This candidate said "Well my partner is considering a job in Texas."
I asked candidate if he preferred Texas to NYC.
"Not really, they have scorpions."
Yes!
I moved internationally in 2012 and, knowing no-one in my new city, promptly volunteered to organise the local chapter of a popular developer meetup. I met dozens of friends and future colleagues at those monthly meets. Almost immediately I got a job with the outgoing organiser, and a couple of years later I recruited the core of a greenfield team from the regular attendees. One of them wasn't even working professionally with the language, but it was clear from talking to them and seeing their code they had potential. Moreover they were a really decent yet introverted person who just needed a break. I loved working with them and was proud to watch them grow into a truly accomplished yet extremely humble engineer. I'd hire them again in a heartbeat.
Another: my department was made redundant in March (great timing), but I immediately picked up contract work with a friend I first worked alongside many years ago. I've hired him into multiple roles in the interim with great success... and now I get to help build his business. We trust each other to be candid and know each others strengths and weaknesses (technically and personally) and he pays me on time. It's great.
Another: we needed a QA for my last team and one of our senior devs recommended someone from an old workplace. Feels bad saying it now, but with no experience of our toolset or domain we'd never have given their resume a second look. But good QAs are hard to find and we were desperate, so after a promising interview we hired them on a trial. Couldnât have gone better - obliging, a quick study, and a knack for surfacing esoteric bugs. They went on to lead QA for our company.
Referrals and âthe networkâ can work to your advantage.
Yet... when growing my last team Iâd exhausted that network, so we advertised on StackOverflow. Amongst many applications were from two "developer famous" people I knew by reputation (twitter, conference talks, blog posts, book authorship etc). Our whiteboard-free process was a friendly interview followed by a small take-home code challenge. One came was arrogant and dismissive and said had neither the time nor inclination for take-home projects. While the other was gregarious, gracious and completed the task without fuss. Guess who we hired? They were technical mentor to virtually everyone on the team (myself included) and were instrumental in laying a solid architectural foundation of our product.
While Iâve plenty of âwar storiesâ, it really is nice to remember how many gracious, friendly and deeply competent people Iâve worked with over the years.
Here are a few, and this is just at the offer stage (at which point you and your team have spent a lot of effort on a candidate):
* Candidates reneging after accepting an offer (current company made a bunch of concessions to keep them)
* Candidate reneging after accepting offer and my company getting an H1B approved for them (turns out they had interviewed with and accepted offers at multiple companies, to get multiple H1B petitions filed and maximize probability of at least one getting accepted... of course they didn't disclose this)
* Candidate accepting offer then simply vanishing
I don't have good stories (or rather, none that I would want to share), but I do have battle scars. Hiring is hard. It's really complex to get right, and I spent years tuning the process.
Having done both, I'd much rather be on the hiring end than the candidate end. But as the hiring manager, I mostly just felt weariness at the process.
The biggest revelation of being on the hiring end is that we generally know whether we want to hire someone a second after the interview ends.
The most interesting thing Iâve heard I guess has been the guy who replied âWell, theyâre all idiots thereâ when asked why he wanted to move.
Like someone else said, hiring is mostly just tiresome.
They've spent hours trying to convince people to talk to them. They've spent even more time getting candidates to the offer stage, only to lose out to the FAANG / startup-du-jour.
Maybe they should ask themselves why they ended-up losing?
One thing that most people, including the OP, don't seem to understand is that the heavy process and rigid structuring of the FAANG interviews is to transform the "Optimal Stopping Problem" (aka the "Secretary Problem") from one of of ordinal evaluation to one of cardinal evaluation.
Extracting a cardinal evaluation goes a long way towards solving the "Optimal Stopping Problem" more tractable and efficient.
Didn't find this one compelling. "Some truth to it..."! Please, it's an industry-wide disaster, aka billion-dollar mistake.
Granted some of the test fashion is useful for computer scientists and the fraction implementing algorithms. But the other 80% are being selected for the wrong thing. These other folks that are curious could be trained on the job (the growth mindset) in a few weeks, if that were still a thing.
On the other hand, if youâre a brilliant engineer who struggles with being told what to do or doing work that you canât immediately connect to something intrinsically motivating to you, that FAANG interview just did both you and the company a favor by weeding you out of the process.
Or maybe the candidate is willing to do that type of work during work hours, but lacks the time and motivation to do it at home after work.
I made way more money practicing interview questions than I did working for a shit company. If I didn't practice I would have stayed at shit companies and continue earning half the salary I got at Google. In the end when I look at the difference in salary progression between me and those who didn't join Google I earned around $300k after taxes for practicing algorithm problems for a few months so far. I'd say anyone who don't want to do that is just plain stupid.
When people say "work smarter not harder", practicing algorithm interviews on your free time instead of trying to get a raise at shit companies is exactly the smarter thing to do. By choosing not to do this you make your life way harder.
300K after taxes? In california, that's practically 600K gross. Well done. Considering you mentioned you doubled your income, does that mean boring corp was paying you 300K gross? That is pretty impressive and honestly, I didn't think broing corp paid this much.
> I'd say anyone who don't want to do that is just plain stupid.
Please elaborate.
You have two options for a job:
A. Boring big corporation paying $80k.
B. Boring big corporation paying $160k, but you need to spend a few weeks practicing to pass their tests before joining.
Many people say they choose A since they don't want to waste their free time coding, like the guy I responded to. That is just plain stupid. Money is ultimately free time, you don't have to work as long as you have money, and many of these well paying companies lets you go down in time.
Consider it an entertaining exercise to try and come up with a way of looking at this which doesn't involve people who don't think like you do being labelled stupid.
One way to find at least one promising line of thought in that direction is to consider that every choice has a cost and not just a benefit.
I see where the author is coming from, certainly. But, you have to realize, most hiring discussions on HN end up emphasizing the candidate's perspective. From my POV as an interviewee, I don't actually _care_ about any of these myths. What I _do_ care about is being tested fairly, using problems and scenarios that could come up in real work, not whether I can regurgitate some DP algorithm.
IMO, this is what's lacking in most interview processes I have participated in, and most of these issues can be fixed by following a structured interview process. As a side benefit, you may end up with better candidates, as well. At the very least, you can actually _tell_ if the candidates you choose to hire are as good or better than other people who have gone through your interview process, and that's worth something.
Can anyone comment on the authors book?
https://www.holloway.com/g/technical-recruiting-hiring/about
Lots of criticism of various points in TFA here. I really need to make a senior hire. Where can I learn to do it right?
Hiring is not broken, it's just a two way filter, tried to be cheated both ways.
One side has a way bigger pump
I'd give FAANG more credit if they had better track records of producing good products with good design and good engineering, but the track record is mostly a trail of failures in terms of bad design and bad engineering.
Facebook has largely stagnated aside from acquisitions. Most of their scaling issues were resolved a decade ago. If you consider the repeated, practically universally hated redesigns, how is their hiring process working for them exactly?
Amazon has numerous, obvious, long standing problems with their web store and cloud services. Maybe they are engineering toward higher profits instead of satisfied customers. Fire stick and amazon video UI is a trash fire. Regardless, I don't see any amazing engineering coming from amazon. Maybe its all in fulfillment? From what I can tell, Amazon just finds okay engineers that are willing to be exploited until they run away when they realize how awful it is to work there. When you consider the fulfillment employees things don't get rosier.
Apple basically forces a curated design aesthetic down their users throats. Some like it, some hate it. I use a mac and android. As a user, iOS and macOS literally sicken me; I have to go into the accessibility and turn off all the animations and transparency. Apple's software has notoriously gone down hill for many years in terms of bugs and performance. I'm sure there's a lot of great engineering work that goes into a lot of what apple does, but it's almost all throw away. They focus on trendy features that no one wants. It sells a new year of iPhone upgrades, then it's abandoned because no one used those features. I still feel bad for all the companies that have been swindled into adding touchbar support and all the users that were swindled into paying $200 for the touchbar they won't use.
Netflix hasn't changed in a decade. Maybe their backend systems have improved? I still regularly encounter buffering issues and the UI has been terrible since the first iteration. I still get DVDs in the mail and they visually downgraded the UI for that a few years ago but otherwise the feature set has never changed. The quality and selection of the petrol-disks transported using petrol is still superior to the largely-free-to-them transmission of the digital versions. I presume their hiring is largely focused on content creation at this point. Maybe their backend systems are more reliable now through engineering?
Google is so infamous for product failures theres a metaphorical graveyard. How many times have they tried on the messaging front? I think we are at iteration 6? That's 5 failures in a row. The things they've succeeded at like search, mail, and maps were all done over a decade ago. Since then it's just been repeated downgrade after downgrade. Maybe all their engineering work is going into search rankings and anti-spam which are decent but not obviously better than its been in the past. Point of diminishing returns probably.
I'm sure there are brilliant engineers working at all those companies, but it largely isn't demonstrated in overall output from the sector. Now considering the _quantity_ multiplied by the quality of engineers, it's truly shocking I can't reliably send a text based message to an arbitrary person in the same city.
I think FAANG's success is more easily attributed to non-engineering related choices that have hurt users and the industry to a much larger degree than it has benefited them.
All things considered, the efficacy of their hiring practices can't be too far ahead of the industry average so I don't think it's fair to hold them up on a pedestal and claim 'Regardless of how bad you think they are at hiring, FAANG's hiring practices are effective'.
This is a really good overview, one of the better things I've read about hiring in a while. I led engineering hiring at a ~25 person startup last year and I strongly agree with the authors description of the differences between FAANG hiring and smaller company hiring. The part about fit resonates with me as well---everyone we recruited and hired with specific ideas about how they'd mesh with the team outperformed the hires who were closer to just "filling seats".
I don't see how it's a "myth" that "whiteboard interviews suck". You never write code on a whiteboard in the course of your day job. The obsession with whiteboard interviews is absolutely idiotic IMO, as is the obsession with asking deep algorithmic questions which the candidate will definitely not be able to answer convincingly if they didn't encounter them before.
It's idiotic that someone has to prepare for a month to do a 5-7 hour whiteboard interview loop that has no relation whatsoever to the job duties. You don't quiz a barbecue chef on Michelin star molecular cuisine, yet this is considered totally normal in our profession.
At a minimum, ask questions that one could figure out without knowing the answer beforehand, and at a minimum let them use their text editor. Better yet, don't do this shit at all, and ask people to solve a _practical_ problem similar to ones they're likely to encounter if they take the job. It still provides a good filter, arguably better even.
As things are now, interviews test for academic credentials, memory, and lack of flight response from candidate's amygdala, not practical technical skill per se.
> As things are now, interviews test for academic credentials, memory, and lack of flight response from candidate's amygdala, not practical technical skill per se.
Those sound like they might correlate well with the traits desired.
I wish I could quote some paper or otherwise confirm this for you, but when I was at Google, Google itself has disproven this by hiring a cohort irrespective of their interview outcome (you can imagine what this did to googlers' impostor syndrome when they shared the results), and then tracking their performance for a few years. They did about as well as people who were subject to traditional scoring in interviews. Now granted, this is not a viable option for all of their interviewing, but at a minimum it suggests that interview scores aren't as strong an indicator of future job performance as people assume.
There is a myth that such a study exists but I never saw any evidence for it when I worked there, seems like it is just a meme. I mean, just because you saw people talk a lot about such studies on memegen doesn't mean that they were ever done, I never saw anyone seriously believe in them just posting about it for fun like "what if I'm the one they let in with failing scores?????". However Google definitely did studies showing a decent correlation between interview scores and future job performance, I read them myself.
_Diversity. We really, really suck at diversity. Weâre getting better, but we have a long way to go. Most of the industry chases the same candidates and assesses them in the same way._
I would pass this buck way, way earlier. Many diverse future candidates (non-white) are educated at awful public schools. When you begin your education at a miserable daycare-school then you are far less likely to make it all the way through the life-pipeline and get in front of a high tech recruiter. I have hired diverse candidates and they are great just like all candidates I hire. There simply aren't that many that apply, and the pool of diverse candidates is sucked up by way better-funded FAANGs and similar.
I would argue we need to completely reinvent our primary education system from the ground up to offer more choice and make them way less depressing for lower-income students. You can't expect a tech recruiter to fix 2 decades of mistakes through their hiring system.
I have some insight into this.
My schooling was in eastern-ish europe growing up in a low middle class environment. My girlfriend grew up in SFBA and went to high school in Palo Alto.
The difference in perspective is astounding. Even simple things like what you consider normal.
Like, I grew up knowing that The Boss is someone you hate and despise who makes your life miserable. Becoming the boss is villified. Rich people are bad. Everyone is out to screw you. That includes rich people, poor people, the government, the police. Everyone. Itâs you against the world. The forgotten class everyone exploits and nobody helps. High taxes, no help.
Oh and teachers are all dumb. Otherwise they wouldnât be teachers.
By comparison the normal for my girlfriend is âYou invent google street view or cofound the next ebay, obviously. Thatâs just basicsâ. At the least you do well in school, get great grades, and climb a corporate hiwrarchy to near top. Thatâs the failure mode if nothing else works.
Learning the US corporate/business culture has been imo my biggest challenge moving here.
While attending a poor school and growing up in a poor environment gives you a completely different life perspective than growing up in a rich one, it's worth noting that this isn't what people mean when they talk about "diversity".
I know it isnât and that makes it even harder to talk about. Classism is understood and recognized in Europe and people are working on it. USA is still stuck pretending it doesnât exist.
Similar to how 50 years ago it was pretendint sexism isnât a problem.
Imo itâs important to talk about all types of systemic issues, not just the popular ones. And to quote one of my well meaning friends: _âOh pfft your issues donât count because you can pass (look white and male)â_
It's what I mean. It's not only what I mean, but that diversity of viewpoint is incredibly valuable when trying to solve problems as a group.
I grew up in the Bay Area and went to school in Cupertino; the number of people who are of the perspective you described your girlfriend having are in the minority even here. There are a handful of schools across Palo Alto and San Francisco that enable that kind of thing.
Minority of the overall population in SV that went to schools here? Yeah, probably. Minority of the people who end up in tech in SV and grew up here? No. I've met too many people in SV that are in tech and who grew up here to come to that conclusion.
I am in tech, as you might guess ;) I know the type of people mentioned in the parent comment, they go to a handful of schools I could name specifically, and the reason they are that way is that they are either the children of multi-millionaires of billionaires, or are friends with someone who falls into that category, or at the very least go to the school and benefit from the parent donations and atmosphere. That isn't to say that there isn't a drive to do well at other schools in the valley, but it's nothing like "I'm going to start the next big thing", it's more like "I'll make good money at FAANG someday" for most people.
For the record: My gfâs parents went out of their way to ensure she went to that specific school. Iâm told it pretty much broke them financially to have the correct zip code.
Indeed it's common for parents to go to great lengths to put their children into the right school. It's a bit sad that there are so high differences between quality of schooling in the US. Having the right/wrong friends can change entire lives, as can the teaching. That being said, telling kids they either start the next facebook or they are losers and have to take a loser FANG job is a bit bit overdone though... But I guess it all depends on perspective. If you are already in the upper class, you want your children to get upper class jobs and upper class success as well.
(Author here)
This is the "pipeline problem" debate. You're right, it does start much earlier than tech companies, but also, it's too easy for hiring managers at tech companies to just throw up their hands and say "we can't do much, it's just the pipeline that isn't giving us enough diversity." There is plenty of evidence that it's not just a pipeline problem.
One of my co-authors wrote a really solid piece on this:
https://www.holloway.com/g/technical-recruiting-hiring/secti...
Why is that "solid piece" acting like stereotype threat is an actual thing, and not the totally debunked replication study failing pseudoscience that it is?
> Overreliance on requirements like four-year degrees from the same few top schools, and on referrals from current employees, limits the number and kind of people considered âqualifiedâ for technical roles.
It's a simple signal to noise ratio issue.
Sure you might be leaving out "diamonds in the rough" candidates, but how many mediocre interview will it take to find one?[0]
[0]
https://blog.codinghorror.com/why-cant-programmers-program/
I agree with you that tech companies can do better and have done better. But this is like, they are doing 1.5x better. To do 10x better the educational system needs to be totally reworked.
I think it's far more likely that there are numerous 1.5x improvements to be made along the entire funnel than that there exists a 10x solution at any one point. Making each person who 'owns' a piece of the process accountable for optimizing their portion is going to yield far better results than passing the buck.
There's a reflexive tendency for people to assume that a problem manifests at whatever point it is measured. It's an easy assumption to make.
However, estimating malnutrition by measuring the heights of adults is not a great way to get a read on current food supplies.
You make a fair point, but it is very hard to snap my fingers and make more competent programmers of all races that perfectly align with society's representation of them.
While that does explain part of the issue for racial discrimination, gender discrimination is much less well explained by gaps in public school systems.
The medium- and higher-income districts are all still close to a 1:1 gender ratio but tech companies are really, really far from that.
It doesn't have to start early in the pipeline.
https://educationdata.org/number-of-college-graduates
It's only relatively recently that female graduates even reached parity with (and now outnumber) male graduates. It will take even longer for the male:female divide to be closed in STEM.
I'm convinced that the best way is to have a beer with someone and to get them to start ranting about the bugs they've had to catch and resolve. The more swearing about the technical stuff, the more confident I am about that they solved it. I'm more interested in hearing about the problem solving in the contexts that they've worked through, what they learned, and their experience over all. Experience is universal.
Telling someone to get 3 values of a list that create the high product isn't going to solve your production issue on a saturday night.
Generally there is a disproportionate dropoff among minority and female candidates at every stage of the career pipeline, not just in the pre-interview parts.
Non-white is an interesting definition of diverse.
Explaining things as problems of lower-income students doesn't really work, and "solutions" built around this assumption will fail, because even if you consider higher-income subsets of the racial demographics, or otherwise control for parental income, you still get huge disparities in the numbers of high-performance students.
As far as I can tell White Americans are a super-minority in Silicon Valley hiring pipelines. Of the 100 or so interviews I've done in the past few years I'd say about 2% were White American, 5% were of East Asian origin, and the rest of South Asian origin. Fact is if Silicon Valley firms actually want to be diverse, that is to say accurately represent the demographics of the USA, they need to hire more White Americans, not fewer.
You're saying that you interviewed 100 people and 93 of them where South Asian? That seems insane unless you're actively hiring talent from India.
I've observed similar demographics in North Texas, consistently over a 20-year period.
For meat processing plants?
Yeah, this doesn't seem believable at all. East and South Asians are definitely overrepresented (compared to US population) in tech but not by these numbers. Luckily some big companies do publish diversity reports which will easily give information about the actual stats.
FB's diversity report.
https://diversity.fb.com/read-report/
White Americans make up 37% in tech, 63% in leadership positions in Facebook.
GitHub is 70% White and 15% Asian.
https://github.com/about/diversity/report
Apple is 50% White and 23% Asian.
https://www.apple.com/diversity/
Yes, it's pretty obvious that management at this company and org is actively and preferentially hiring talent from India based on my lived experience. And note there wasn't a single Black or Hispanic American candidate in the pipeline that I got to screen. Not one.
2%? There is no way unless you were specifically setup for that by advertising exceptionally low pay and willingness to sponsor visas, and even then that seems off by 10x or more from my experience.
Certain companies tend to create ethnic clusters, and this person is probably at one of them. Ex: One 50-300 person place I worked at had a much higher rate of chinese & jewish people than other typical tech companies for example. It started because the first staff members were of those groups, and then they reference more people from those groups and it creates a network effect. I was a recruiter hire so I wasn't part of the trend. Companies only start reverting to the mean once they get so big that the reference network effect is too slow.
If the ethnic clusters have bad english, you then start getting language and cultural comfort effects and people not of the ethnic group have a much harder time getting hired.