I often think what would Google/Facebook would be like if they hired in some experienced engineers that may not be able to whiteboard a BFS tree or can tell you Djikstra's algorithm, but have proven business track records of getting projects done, on budget, and on time. Real, pragmatic, get-it-done types of engineers. (That's not to say whiteboard expert engineers can't also be this way - it's just that whiteboard interviews don't hire for this in particular - technical expertise comes first)
There was an excellent comment on another thread yesterday (that I can't find) that basically said something along the lines of "If I'm asked about BFS trees in an interview I'm going to tell them I'm just going to google a library that can handle it - I've got more important work to get done"
> I cannot help but think that these big tech companies (FAANG, et. al) are missing out on diversifying and increasing their engineering expertise by passing over developers like you.
I think this is certainly true.
> I often think what would Google/Facebook would be like if they hired in some experienced engineers that may not be able to whiteboard a BFS tree or can tell you Djikstra's algorithm, but have proven business track records of getting projects done, on budget, and on time.
Well... how do we find these people? By looking at their resumes where they claim this? By contacting references who will attest to it? By trusting the intuition of subjective evaluators of the candidates?
Practically speaking, FAANG companies do hire such individuals, they just do it through acqui-hires. If a person works at a company that is good enough to be worth acquiring, then we have a good signal that they are effective employees even absent a direct evaluation of their technical abilities.
there's a huge pool of employees that are in companies which aren't potential acquisition targets.
> Well... how do we find these people? By looking at their resumes where they claim this? By contacting references who will attest to it?
internal references? if you've got a couple of internal folks who are doing good work, and they all worked with and vouch for old bob, maybe that's better than anything you're going to find out from <8 hours of whiteboard scribblings?
> By trusting the intuition of subjective evaluators of the candidates?
even the faintest whiff of implication that FAANG interviews might not be subjective is hilarious.
At each place it was people from other teams completely unrelated to that team who interviewed (or would interview) me and eventually turned into a decision panel where everything about me would be considered by these people who really knew nothing of my character/skills aside from the resume and white boarding.
Between that and the amount of times I heard "Stanford" tossed around in a way that put down other schools (while not having a degree at all myself) I decided to give up on ever working at any of these places without being an acquihire. It just seems like a far fetched pipe-dream and I'd never check the required boxes that they expect for someone to sit in the same building with them. And honestly, none of that sat well with me.
It was an interesting time and I got to finally experience SV and realized it's likely not a place for someone like me.
First of all it sounds like your interview experience was unpleasant so if this was at Google I apologize.
Secondly, I can totally relate to feeling like I don't belong having also come from a nontraditional background (No college degree).
> At each place it was people from other teams completely unrelated to that team who interviewed (or would interview) me and eventually turned into a decision panel where everything about me would be considered by these people who really knew nothing of my character/skills aside from the resume and white boarding.
This sounds similar to what we do at Google; people who know you actually aren't allowed to interview you because they will be biased. We try to make the interview as objective as possible. Note that information from anyone who knows you or referred you will be shown to the hiring committee though so it's not as though that feedback is not used.
> Between that and the amount of times I heard "Stanford" tossed around in a way that put down other schools (while not having a degree at all myself) I decided to give up on ever working at any of these places without being an acquihire. It just seems like a far fetched pipe-dream and I'd never check the required boxes that they expect for someone to sit in the same building with them. And honestly, none of that sat well with me.
I understand why you feel this way but that's definitely not true! I don't think you necessarily should want to work in FAANG but I strongly think you should believe you are capable.
It's weird that it's that skill, and only that skill, that gets evaluated. I did another interview at a different one where there was at least a design interview (though I flubbed it and wound up being incoherent).
It really feels like they aren't even trying to evaluate anything other than whiteboard coding. Accepting that it's not a great signal and yet fully investing in it.
It's such a weird skill and it's so easy to perform badly; I'd be kind of shocked if the test/retest validity wasn't very low.
Also... I mentioned that working on teams with other women was important to me... but every technical onsite I've had has been given by a man. They've pitched teams led by women, and my HR/recruiting contacts have been nearly all women. But for the interview itself? All men.
It's absolutely very low, and they're okay with that. One of the things recruiters at these companies will tell you if you get rejected is some variant of, "Don't worry, you can always try next year." These companies fully understand that they're rejecting good engineers. They don't care, because, historically, the number of engineers applying has been so high that they could reject 75% of the good engineers and still have enough to fill their headcount.
We'll see how that attitude towards interviewing changes when high Bay Area/Seattle housing prices make it more difficult for them to recruit.
At big companies this is hard to scale because you have to protect against nepotism at the top layer. This forces policies protecting against the bad outcome.
At small companies this does happen.
Get a sense of the projects they have worked on if those skills relate to the position. Make a decision based on that.
Random coding tests, whiteboarding, buzzword dropping are only helpful to a point.
However, OP was talking about internal references. This would be a situation where I work at Company A, but I know you and trust your work. Therefore, I refer you to Company A, big up you a little and suggest that they pursue hiring you.
The difference is that if you suck, it reflects poorly on me (and quite likely kills my dreams of upward mobility). Normal provides references don't have the same motive to be truthful!
I’ve never heard of any other company doing this, but I haven’t been looking especially carefully.
From FAANG, to start ups, to established traditional engineering companies.
Just curious, because again, I’ve only ever heard this from friends that got bought by Google. I’m not saying others don’t, just haven’t heard of it from folks getting acquired at other places.
- If they decline, you usually get a very generous severence package
- While sometimes technical, there is usually significantly evidence of your abilities from the acquired company's records.
- In my experience it's usually a cultural test more than any other.
- Interviewing is part of the evaluation. If the hiring company thinks everyone is grossly incompetent they can reevaluate the acquisition or call it off entirely.
While not perfect I wonder if a person's projects are a good signal for this. There certainly are those who have developed a significant open source project but who get rejected by the FAANG companies, the author of Homebrew being a recent infamous example.
As an interviewer, I can definitely say that GitHub has become a bigger part of helping to evaluate people.
Many people can’t work on open source, either due to a lack of time or corporate policy.
Not to diminish his accomplishment... he could be a good candidate for PM but his tool is more of a dev-tool (so I suppose this is a niche-ish?)
> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested.
But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that.
Having worked with people who are dicks but make really good things...I wouldn't want him on my team either. There are plenty of people who make really good things and aren't dicks.
It’s always possible that Google felt he wasn’t what they needed. And keep in mind that Howell ended up being hired by Apple and working there for a while.
I mean... Yes?
This system, backed by "trusted recommenders" is exactly what academia uses, and they seem perfectly capable of discovering Higgs Bosons and whatnot.
This is inherently biased and proven to be the worst way to hire people.
I would argue that pair programming or take home projects do a far better job than the standard Whiteboard Algo interviews. In fact I don't think it's even close but SV engineers have been captured by this Whiteboard Interview Stockholm Syndrome/Hazing and continue to perpetuate the insane idea that there is no better way.
How does one not have time for pair programming? It's the exact same time commitment, from both the interviewer and interviewee, as a whiteboarding session. It's just a different format for the interview.
I don't think it's the case that people don't like interviews. I think you're making a strawman. I'm not going to go and say that you're part of the cycle of SV engineer being hazed, reproducing it and exhibiting a sunken cost fallacy/bias towards the way you've done it, but it's possible. I don't think this is the ideal way to interview.
What's more, I've been seeing actual improvement on the state of the art in this area. Platforms like Karat et al (not sure if Karat is the best in this area but I did have a good experience with a company that used them and interviewed me well) are actually incentivized to minimize false positives and negatives rather than just one. You might be surprised at how much better a good technical interviewer can be than an average strong engineer.
And their education, previous employment, etc.
No one makes a neuro-surgeon perform a surgery before hiring them.
True, but I also know that a neurosurgeon graduated from an accredited school, did an internship at an accredited hospital, and then passed a standardized licensing exam.
If we had that for engineers we wouldn't need to test their skills either.
When I was doing hiring, I would see resumes of people with 10+ years of experience who couldn't write a simple loop in their favorite language. If you've been coding for 10 years, you should be able to write a simple loop. That's the problem we're solving for here.
What you are asking for, is a surgeon to retake the boards every time they change hospitals. Or a licensed professional engineer to retake the PE exam everytime they change jobs.
The algorithms asked in interviews are rarely implemented in a job. All they prove is how much you studied and the author of the article proves that.
What our industry is missing, IMHO is required certification and training. Doctors and nurses have yearly training and related exams to keep their certification. That's why a hospital can hire staff based on a license...Not becsuse the items you mentioned. But our industry would never go that route, which is a longer rant.
Also if peope who can't write for loops are passing your phone screen... You might want to update your phone screen.
Yes, just as you retake your driving exams every five years, you should retake your engineering exams (unless you are an accredited engineering instructor, in which case the license becomes permanent) every ten years.
Uhh... I haven't taken a driving test in 17 years (and two states ago, to boot).
While I agree with this, the FAANG interviews take it too far. Simple fizzbuzz is enough to weed out these completely incompetent engineers. If they pass that, accomplishments and experience are going to be a much better indicator of engineering ability imo.
That's the problem some interviews solve for. FAANG interviews take it to another level.
The bar is being raised all the time as much as it is painful and hard for me to see/experience this :(.
We have that for "real" engineers. Doesn't stop many of them from being atrocious at their job. Doesn't stop doctors either, for that matter.
...and meets ongoing continuing education requirements.
> If we had that for engineers we wouldn't need to test their skills either.
We do have that for professional engineers.
We don't have it for people working in software whose job titles have become (but largely weren't for similar roles a few decades ago) "engineer".
Which are a joke. Attending conferences and weekend workshops take care of this.
Sure, professional licensing provides fairly weak guarantees, but it's more than exist in software, hence FizzBuzz.
I think we will, eventually. Other fields of engineering already do, of course. Software is new and not that many people have been killed by bad software (unlike bad buildings), but I think we'll get there.
Unfortunately, this seems to be poorly correlated with whether people can actually code.
There is also an experimental virtual surgery simulator for objective evaluation - https://www.ncbi.nlm.nih.gov/pubmed/26153114
Google allows you to write code on a Chromebook instead of a whiteboard (don't know if it's for everyone or some people). Is that pair programming? Or do you mean actually working with your preferred IDE/text editor, terminal, browser to look stuff up?
I think they weed out a few, but completely ignore practical development skills, work ethic, soft skills, design and architecture skills, etc.
Of course maybe this explains why most of the big tech companies have seemed pretty stagnant for the last decade, largely failing with products and decisions that have poor execution and market fit outside of the products that made them big in the first place.
Has anyone actually studied the best way to hire devs? Like a real, independent study that measured and compared results across, perhaps, a wide array of metrics?
I don't know how you would ever strive to do such a thing when people can't even agree how to measure productivity.
> Of course maybe this explains why most of the big tech companies have seemed pretty stagnant for the last decade, largely failing with products and decisions that have poor execution and market fit outside of the products that made them big in the first place.
In most large companies these things have nothing to do with programmers; the decisions are made by management and products are designed by PMs. Hell, you can't even necessarily blame buggy products on programmers: I've been on projects where everyone realizes things suck but if you don't get funding or agreement to work on infrastructure projects what can you do?
This is the whole point of the non-coding portion of the interview, and while it’s not possible to get a full picture of this in the short amount of time allotted, it is generally enough to throw out the obvious ones.
> maybe this explains why most of the big tech companies have seemed pretty stagnant for the last decade, largely failing with products and decisions that have poor execution and market fit outside of the products that made them big in the first place
I think this is unrelated to hiring and more a result of corporate policy.
Tech interviews are not solely whiteboarding. Even at FAANGs there are system design and hiring manager interviews designed to ask about those sorts of things.
Also, what evidence is there that these high-false-negative practices are actually reducing false positives by a significant degree? In these kind of threads I read the same arguments and assertions, with the same lack of evidence, as I hear from people trying to defend airport security theater. I should start calling these practices "interview theater".
In my experience (hired 10 engineers), yes.
It's technically easy to fire people, but it's emotionally draining on the team and on the manager in particular. Every time you fire someone, the team's morale takes a hit, and if you were firing people often, folks would begin to feel insecure and you'd struggle to keep good engineers.
Smart, good people want to work with other smart, good people. If you're constantly bringing in bad hires (even if you later fire them) then your good engineers will get fed up and leave.
The net value of a bad hire can easily be negative, if you consider the high onboarding costs to get a new engineer ramped up and trained. (Of course, the very best engineers basically sit down and start coding as well as your existing good engineers, but these true outliers are by definition uncommon). Not to mention the cost of the bugs and rework that bad hires produce.
If you use a recruiter, you're typically paying a large fee that you can get refunded after N months (details vary, 3 seems common), so you'd have to be making your assessment in the first N months; that's a lot better than trying to make an opinion on the first day, so if all of the above wasn't true, in the abstract, it would be great to be able to hire aggressively and fire likewise. However, good engineers balk at the concept of a "trial hire"; understandably, as personally I'd refuse to work somewhere that didn't have conviction that they wanted to keep me.
I imagine the relative significance of these points varies between companies and stages; all of these points are from early-stage (<25 person company) startup life; YMMV.
> (something you won’t get from a whiteboarding challenge).
I agree with this point, though I think it's orthogonal to the question of false positive vs. false negative cost optimization.
I know Google does a lot of metrics on hiring. Have they correlated their practice with IQ anywhere? Guessing nothing public as that would trigger a firestorm.
At the end of the day it’s just the cognitive elite trying to hire the cognitive elite.
Conformance too (due to the prep time)
It is instead the opposite. These companies are testing the quality of "who has practiced the most for these types of questions".
It has nothing to do with intelligence. It is instead almost directly correlated with how much time you have spent practicing interview questions.
Those people generally also do well on those whiteboard questions.
I think this happens less than people think. I've been at two big tech companies and interviewed people while at both (and obviously was interviewed myself).
I think what trips people up is that many questions have solutions that are given by "named" CS algorithms like the ones you listed, but also have simpler solutions that are fine too. And honestly, candidates that invoke named algorithms and (maybe eventually regurgitate the textbook algorithm) are often not the good ones (to me at least). Most problems like this often have simplifications that good candidates take advantage of to do something custom (and much simpler) than the "named" algorithms.
Basically, if I'm interviewing you and you regurgitate a famous algorithm... well I'm not going to ding you if you do it correctly, but in my experience, I'm much more likely to give a good review to someone that methodically works out a simple solution instead. Often the people that successfully dig up a named algorithm and apply it can't talk about it very well.
So, I suspect that a lot of the people that complain about not knowing a famous algorithm in an interview simply failed to work out a simpler solution to a simpler problem and didn't realize it.
I'm not talking about brute force solutions. For many problems, there are things in between <famous algorithm> and brute force. Some problems offer simplifications over more general problems where <famous algorithm> is strictly worse than a simpler, more customized solution (same efficiency, but simpler to write and understand).
Can you give a few concrete examples of how a deep understanding of BFS that can't be googled and read in 10 minutes at the time you need it can help you ship profitable software products faster than your competitors?
Indirection is great in this trade, a lot of what I "know" is just an index key/search strategy to go look it up again. But a lot of what I "know" I know directly. According to this old paper[1], for many fields including software you need to directly know about 70k±20k random things in the field to be in the running for expert status. Proficiency is also related to how many things you know directly. Thus you can't do an index lookup for everything unless you have no constraints on time and/or don't care about improving your level of expertise.
For me, it always goes like this:
* Am I iterating over a list multiple times?
* Am I iterating over a list and comparing it to some elements in another list?
Turn one of them into a map and continue. It's pretty simple.
I usually find DFS/BFS applicable when I'm dealing with data that forms relations like "children" or "neighbors" or "connected". Sometimes that's explicit because the data is already in a tree or graph structure, sometimes it's not. And often rather than looking for a particular element, I want to iterate over all the data connected by the relationship to do something with after as a list/set/map of the data or some of its properties.
A concrete example from a side project (it's more fun than Real Work examples, and people have given other examples in the thread anyway), I was writing a client for the board game Go. If you're not familiar, the data is just a 2D grid (easy to interpret as a graph), black/white stones get placed on coordinates like (3,4) marking intersecting lines. A single stone forms a connected group with another stone if both are the same color and separated horizontally or vertically by one. Groups have a count of "liberties" representing the number of unoccupied points the group can expand to if a stone of its color is played there -- a single stone by itself in the middle of the board will thus have 4 liberties, if you connect a stone then that group now has 6. If you cause an opponent group's liberties to go to 0 by surrounding it, the whole group dies, and its stones are removed from the board with those points becoming unoccupied again. Suicides (causing your own group to hit 0) are ok only if they capture the opponent first, otherwise are invalid moves.
Handling the game rules is easy with DFS/BFS. All you need to start with is a function like get_neighbors(position) which on a grid is trivial, being the 2-4 surrounding points depending on whether position is an edge/corner. Then you can use DFS/BFS (doesn't matter) and several lines of code later you've got a function like get_group_member_positions(start_position) that gives you every member stone's position no matter which one you query first. Now you can make a function count_liberties(group_positions) -- which can be solved as another depth-first traversal problem over the neighbors of each member of the group that are empty and haven't been counted already.
Even less code this time though; have you ever had to write 4 lines of code like "for el in list, for child in el.children(), if child blah, do something"? That's a DFS, just not a general one since you know how many layers there are (or that you care about), and it assumes children aren't shared between els.
From all that you can then have a function like get_stones_captured_by_move(move) that tells you what (if any) stones need to be removed if move were to go through: for each neighbor of the move, if any are the opponent's color, count the liberties for that neighbor's group and if it's 1 then those will die when the move is played (takes the last liberty). If it's all one big enemy group around the move you'll have to account for duplicate positions to remove, but those are minor optimization details. Similarly the fact that everything is recalculated all the time, that could be optimized with more storage.
BFS/DFS are just basic building blocks here.
You will be asked to find the biggest file in folder structure, find largest modúle in dependency tree or the person in data structure that has no department and thus caused null pointer exception.
You also won't google it, because it is simple and ylnormal programer don't need google for this.
I think the HN crowd is heavily inclined to web apps and also front end. I can't tell you how important fundamental CS knowledge is for backend. I bet you can't use a library or API for how caches work or when paging happens. Knowing these things makes you a well rounded engineer ready to tackle different problems. I can trust you to write a mobile app or work on some part of a self driving car because you have the building blocks to do so. Most of the comments in such threads have no interest in interesting and diverse jobs because "why bother, when will I use this". To any new grad, yes the interviews can be better but please spend time on these things at school. They are an investment in your career's stock.
And I don't have this kind of fundamental, "what do you mean 'google it' are you a complete and total fucking moron!?" attitude about anything in software. I routinely browse through google results (mostly SO/Medium) about very basic concepts just to read the words again and re-warm those caches in my brain.
These questions come up all the time. You just need to be proficient enough with algorithms to identify them.
would go even further and say that you could easily have installed something like https://oracle.github.io/opengrok/ in three commands for your organization and extract a lot more value while resolving the issue.
10 million lines of code fits in RAM pretty easily. You could use the worst algorithm in the world and still complete that whole task with just a few seconds of compute time.
I think that's the point. You don't really need to know about BFS in most cases, because in most cases you can solve the problem with any old search in just a few seconds.
It's not a question of speed. It's the fact that tree traversals are the best way to analyze parsed text. Although, it was quite resource intensive and we ended up distributing the workload among multiple computers so we could scan all pages at once. Luckily this was easy because pure functions are trivially parallelizable.
I thought you were talking about actually using BFS on a data structure, in which case I'd use a library to do it so I don't have to reimplement all the loops and because there are modern libraries that would take care of the parallelization (like this one[0])
[0] https://github.com/arjun-menon/Distributed-Graph-Algorithms/...
On the topic of my example not constituting "knowing BFS", the BFS I shared is just a slight modification of what most students are taught and is close to the second method for level order traversal of a tree on geeks for geeks[1]. If you don't like the BFS usage because it isn't on an explicit tree (although nested HTML templates most definitely form a tree), the result of parsing an AspxFile in my gist returns an explicit tree data structure[2][3] and the helper method[4] at the bottom does a standard preorder traversal[5] on that linked structure. That feels like "actually using DFS on a data structure".
[0] https://twitter.com/mxcl/status/608682016205344768?ref_src=t...
[1] https://www.geeksforgeeks.org/level-order-tree-traversal/
[2] https://gist.github.com/tohsa/2d906942f8712abdfc7df72128479c...
[3] https://github.com/PositiveTechnologies/AspxParser/blob/mast... (AspxParseResult has a reference to the root AspxNode, and btw I didn't write this parsing library)
[4]https://gist.github.com/tohsa/2d906942f8712abdfc7df72128479c...
[5] https://www.geeksforgeeks.org/dfs-traversal-of-a-tree-using-...
For BFS? Almost never, no. Libraries are generally useful for reference implementations data structures and algorithms that work on collections; I have yet to find an algorithm that works well for graph problems or when you need to subtly tweak the data structure (for example, a binary tree that counts the number of elements on its left and right). The issue with libraries is that they are built for the general use case, and a lot of time in the real world it is non-trivial to transform your problem into the format that the library will expect, so you end up having to do this yourself.
I wouldn't hire an electrical engineer who complained that he shouldn't have to know Ohm's Law, either.
...And how you are keeping track of that and other such minutiae. What data structures are you using and why? And how about if X which would invalidate your approach.
Also, it's not about "knowing" it. It's about implementing it in such a way as to please the interviewers.
It's pop quiz nonsense.
As for pleasing the interviewers, of course it is about pleasing the interviewers. They're making the "buy" decision on the talents you're "selling". Of course the seller needs to please the buyer to close the sale. I don't know how it could work any other way.
This is a good question, IMO, because it tests “I need to do this, which data structure would work well for it”, which does come up often in real life.
doesn't everybody?
Sorry, past midnight here after a busy day at work :-P
I know. These people are expecting to be paid way above the average salary - I'd expect them to know the fundamentals, or (more importantly) be able to figure it out.
"BFS?? I'd use a library for that" - well, thanks for that... instead of hiring you I'll just download some libraries instead.
DHH's tweet https://twitter.com/dhh/status/1085987159406927872
1. Creator of top software project can't pass whiteboard interviews.
2. I can't pass whiteboard interviews.
Therefore, they are stupid for not hiring me.
It strokes everyone's inner narcissist--why spend the hours on leetcode, they are stupid anyway.
Edit: Typos.
My above comment was strictly related to the idea that DHH shouldn't be considered for a job over anther candidate who is an unknown quantity simply because DHH apparently is not good at algorithm problems in interviews.
I know that sounds rude... but one seems better to be a leader while others are better engineers would you agree?
I'd totally fanboy and hire Jeff though if it came down to just one though.
I also don't get why people like DHH is assumed to be a "miss" for not being hired by some of these company...
DHH is a unique individual with his own way of thinking. He wouldn't be DHH if he works for someone else (or under someone).
What DHH does could absolutely be incorporated by Google. Angular => RoR, GCE => Saas, conference speakers => conference speakers.
Anyway the point is that even at a company like Google there's plenty of room for people that haven't memorized algorithms and data structures but companies that only interview on these sorts of things are missing out on them because they seemingly don't care or haven't figured out how to interview someone substantially different from what they normally hire.
I find the skillset required to build Basecamp differs greatly with building AWS/GCE portfolio (with over hundred different services that can be combined to deliver solutions for multiple ranges of companies...)
I don't think Google was looking for someone to build RoR or Angular. Those were merely side projects that came out once every few years. No offense but some of the key components of RoR were implementation of Martin Fowler's Enterprise Application Architecture patterns.
Such a situation would show me that he either does not care about getting the job, or is so arogent that he automatically expected that people who throw job offers at him.
That shows that this person has horrible personality problems and that I would not want to work with him, no matter how much he has accomplished in his life.
I think the phrase "jack of all trades, master of none" is overused and doesn't hold a lot of truth. It's very possible to have a lot of experience and skill in many different areas. Maybe there's even a positive correlation between being a very good programmer that can pass whiteboard interviews, and being a pragmatic, get-it-done type of engineer.
There is still so much stupid money out there that it doesn't pay to do this. Literally immaterial, and it's more cost-effective to hire for a narrow-but-consistent set of requirements.
I bet you're quite good at something (perhaps multiple things), but they don't value it. Their loss. I'm glad you found something that works for you.
Why? It's not so clear to me that it's not working right now. These companies seem to be doing completely fine.
If hiring programmers who aren't good at programming puzzles is a competitive edge, I would expect to see other companies hiring these programmers and succeeding.
It seems more likely to me that there is (at most) a very marginal loss from hiring this way. It's not the fairest way to hire, it's not the most equitable way to hire but the evidence doesn't suggest to me that it's not working for these companies.
You're begging the question. Other companies do hire people who are excluded by a certain class of employer, and that's exactly why some get outraged by the types of quizzes that are used. The difference between the standards creates cognitive dissonance over one's ability and status. It's effectively a caste system, and it involves persistent blind spots about discrimination, whether towards protected classes or not.
I can't pass an Amazon or Google phone screen - both of them invited me to try, and they then made me feel very out of place. I'm not a software engineer per se and I didn't get my CS degree from a top school. Yet I have worked for a company that Google outsources important work to, proving I can do useful things that Google needs done and maybe isn't even able to do in house.
I don't go around raging against Google hiring who they want, partly because I'm probably better off not working there anyway. But I understand where people are coming from when they do get angry, even if it is the sign of an imperfect character.
From an employers point of view, they just want to grab the employees that are suitable for their goals and jettison the others. But from a potential employee's perspective, it seems like if I'm not good for one job at a company, I should be good for another. Rejection seems unreasonably total. If, by analogy, you deal in second hand cars, it's a reasonable business model to buy virtually any car so long as the price is right and you know who to sell it to. But not all businesses are run like that of course. It aggravates people that there is a narrow vision for who is useful.
Very good analogy. And true. My dad used to own a used car dealership back in the day. He bought pretty much anything he could get for a good price that was in decent shape. If he only bought cars that were in perfect shape, he'd have pretty much no cars on his lot.
And I've worked for companies whose bosses are so damn picky about who they hire that they would go without hiring a single person even after conducting hundreds of interviews themselves over six months, as the rest of us were struggling to keep up with the workload.
It got so bad one time the higher ups eventually had a recruiter just pick a few people and said "Here, these are your new employees. Get them up to speed." and he just had to accept it.
In the meantime, collegues are leaving the gig, making my level of stress go up.
We do see other companies hiring differently, and being rewarded in the market, in part, for it. Most of the time it's a marginal reward. Sometimes though we get a new FAANG, staffed by people who wouldn't have made it through FAANG's ringers.
Its the difference between fracking the shale for every precious drop because that's all you've got where you are vs. being able to just sink a short pipe in the ground and stick the sweet crude that gushes out into barrels.
Um.. have you looked at their stock? Investors would probly want them to continue coding puzzles if they knew about that.
That's a great way of putting it. Hard to see any other explanation.
Well, maybe not even the "average" programmer, but just the elite of the elite Google-tier programmers ; ) I feel the same way. When I was young, I thought that absolute mastery was within my grasp but after 25 years, tons of self-study, a couple of college degrees and yet still a lot of surprising rejections, I have to concede that while I may actually be very good at what I do (I'm among the most respected and most sought after everywhere I've ever worked), there are still people out there WAY better than I am, and that's OK.
You're better off following your own path and making your own things happen.
You have no idea how diverse people are in terms of talent at big companies. This is a myth peddled here at HN that FAANG employees write CRUD apps and are one dimensional. The best perk of my job is the random lunch scheduler where I've met a former Olympian, someone who is on the Rust core API team and a professional ballerina + software person.
The same was the case when I worked at Mozilla..
But I've always felt the interview process at these places extremely arbitrary.
I'm the same way. I'm really good a identifying solutions to a problem. I'm really good at identifying the costs/benefits/issues with each of the problems. However, I take a while to get there. I may figure out one (suboptimal) solution quickly, but it takes me a while to pick out a variety of them and identify the one I think is the right one for the current situation.
In school would usually (ok, often) get highest score, but took the longest to finish.
Maybe we are just not good enough.. And maybe it's sour grapes for having been rejected by them, but honestly I don't feel I would be a good fit for Google or FB ideologically. I value user privacy and freedom too much. In my eyes they are both evil-corps.
> Finally, I realized my brain needs more time than the average programmer
I also came to this conclusion. I accept it and focus on my strengths as a team lead instead.
Your experience allowed you to move toward doing work that excites you. Even though you didn't meet your goal, you still had great success.
Just progress an inch at a time.
I mean yes, some engineers are going to be better at interviews than others but we gotta go by some signals. We had to flunk a few because it was "we see the depth of knowledge the person describes, but we have to go by the signals we saw, otherwise we're just randomly picking people".
Point is it is tough. However it does say something that our interviews are just a bunch of quizzes and studying for a month will make a huge difference. When hiring the goal is to find out if the person is good, not if they crammed, but cramming does work quite well.
I'm not arguing that it shouldn't be the way it is, and I'm also not arguing against.
Claiming "Finally, I realized my brain needs more time than the average programmer to find patterns in this type of problems." feels a little bit like you've given up and that in itself strikes me as the worst sign.
I haven’t applied lately. Working in one of these big companies was a dream of my younger self. Nowadays, I prefer companies where I can work at my own pace. Moreover, while the salaries at these companies are exaggeratedly high, especially in San Francisco, I feel that my current compensation package is good enough to live a kind and peaceful life.
Those companies sure want you to believe what you're claiming because it means they get the first bite of the cherry but the reality is very different (from my experience anyway).
I strongly disagree, and I'm not sure why you would say that. I've heard that working at Google is a golden stamp on your resume, and you will be able to easily get a job at any other company. You'll probably even be able to skip the coding challenges in any future interviews.
Is this speculative or does this actually happen?
As a team leader I'm involved in hiring and I certainly wouldn't treat one applicant any different from another regardless of their previous postings nor experience (except when I'm headhunting someone I've previously worked with). My own experience interviewing has taught me it's easy for people to put stuff down on CVs (eg they might have legitimately worked at Google but through an acquisition rather than hired by; or not even with the team they suggest they have). So I would consider short-cutting part of the interview process in the way you described to be grossly negligent.
I don't dispute that your CV is more likely to get short listed however you can certainly still sell yourself without having FAANG on there.
My general point is that while I don't disagree that having FAANG on your CV will undoubtedly look good, however a good engineer shouldn't have any problems getting awesome jobs with or without FAANG. Thus is the prestige attached to FAANG really equatable in the real world or is it perhaps disproportionately hyped?
Maybe this is just one of those differences between how people are hired in SV (where I haven't worked) and London (where I do work)?
I think it would be pretty rude and unnecessary if you asked a high-level Google employee to do a whiteboard algorithm puzzle, or a take-home assignment where they have to build a little todo list app. Especially if they are a Distinguished Engineer or a Google Fellow. I don't know where the cutoff is exactly, but at a certain point no-one should ask you to do any more coding puzzles. You'll still go through interviews, but they shouldn't need to test your basic programming skills.
To be honest, judging from your last post I suspect our opinions aren't that far apart. :)
In Silicon Valley, everyone knows that it is fake prestige and the fact that you worked for a FAANG doesn't really mean anything. I both know excellent and mediocre candidates coming out of FAANGs. It literally carry no information besides the fact that you are probably more attracted to prestige.
A few years ago I was contacted by a Google recruiter, but I realized that it was going to be a very junior SRE role, so I wasn't interested in that. I could have put Google on my resume, but that probably wouldn't have been very impressive.
It still makes sense to work at one of these places that pay twice as much as everyone else.
It is simple offer and demand. The supposed prestige of FAANGs also mean that more people wants to get in and unless they really want you, they would be stupid to overpay you.
Maybe my things are different in London than they are in SV but I've never had any issues. Quite the opposite in fact; I've been turning awesome jobs down.
Anecdotally I've really not seen the 2x trend you described and I have spent a fair amount of time negotiating peoples wages. Plus engineers who are really concerned about maximizing their income will generally turn to contracting rather than permanent work anyway (at least that is the case in London where contracting is common place).
Suffice to say, I'm pretty unconvinced that FAANG pay people twice what any other business would. Maybe if you're looking for jobs outside of tech hubs (like smaller towns away from expensive cities) but other tech firms in London (and SV I'd guess?) would have to pay competitive wages else risk not attracting any talent.
I also want to clarify that I didn't mean they always pay 2x over the competition, I meant that it's not unusual for them to. Also when I say FAANG - I kind of included similar large companies (Microsoft, LinkedIn, Salesforce, etc). There's also a lot of large companies that come close, maybe 80-90% of FAANG pay.
>Plus engineers who are really concerned about maximizing their income will generally turn to contracting rather than permanent work anyway
I think it's pretty difficult to get steady contract work that pays more than what FAANG does. I charged $175/hr when I used to contract and it was decently steady, but that only comes out to around the same I would be making at a FAANG minus all the perks/benefits. Also when you get to higher seniority levels, your pay at FAANGs start to reach into the 6 or 700's, meaning you'd need a contract rate of $300+/hr to compete.
Usually when companies need that high level of technical architecture/leadership - they'd normally hire someone full-time rather than use a contractor, so it would probably be difficult charging that rate while getting steady work.
Ahhh I was including those sort of companies (baring Microsoft) as part of my counterexample. If the discussion was "any large / reputable organisation" then my comments would have differed a little.
In any case it sounds like London is very different to SV. It's very common for senior engineers to contracting and that's precisely because the difference in pay between permanent and contracting is night and day (the polar opposite to what you were describing in SV)
FAMLANGS
Nobody aces those interviews in the way you probably think; by just magically knowing every detail.
Wow, that’s amazing! Congratulations to the author because this demonstrates they have genuine talent.
In contrast, I’ve been a programmer for 10+ years, and I cannot pass the technical interviews in the companies mentioned above. At first, I thought the reason behind my failures was a lack of formal education in Computer Science, so I started reading more books. Then I thought, maybe it’s the fact that I spend more of my “productive” hours in my job just doing lumberjack web development, so I started participating in competitive programming (LeetCode, Code Golf, HackerRank, Code Wars, among many others).
Finally, I realized my brain needs more time than the average programmer to find patterns in this type of problems.
I gave up on my goal to land a job in one of these big corporations.
However, I don’t feel bad about giving up, in fact, thanks to all these books and competitive coding exercises, I was able to find two of the most exciting jobs I ever thought I would have, for 4+ years I worked in the software security industry doing Malware Research and building infrastructure tools for other security researchers. Most recently, I entered the game industry, and finally, I can use my algorithms and data structures for non-trivial projects.
Interestingly, I’ve been recently getting more messages by recruiters who want me to work for some of these companies. I politely decline the invitations because I know I cannot pass the technical interviews, but I promptly refer to some of my colleagues because I can see my younger self reflected in them, and I want them to have the experience that I couldn’t have to work for one of these companies. Even if they work only for a few months, as many people burn out, having the company’s name in their resume will grant them dozens of new opportunities.