We analyzed 100K technical interviews to see where the best performers work
blog.interviewing.io
blog.interviewing.io
There's no effort to quantify what "technical" or "communication" skills are - these are left to the interpretation of a the interviewer. It makes no effort to show where these engineers are going, what the interview process they're completing looks like, what impact demographics had on this, etc.
I find this stuff repugnant. It perpetuates the myth that there's something really special about Silicon Valley engineers, while making only lazy and perfunctory efforts to examine any alternative explanations than "this is where the rockstar ninja coders work." Shameful.
Does this myth still have much traction? If anything, my general regard for engineers in the bay area has steadily declined in the last few years. There are so many really worthless folks who have only figured out how look like they have a clue, but go any deeper and they flail. I know I'm painting with a broad brush, and that's not fair, but most of the great engineers I work with are at various other places around the country, not California.
This article certainly assumes that myth is still in place.
* made up statistic.
My experience is biased, of course. My company has offices all over the country and a couple years ago opened a new office in SF, and I'm 93.4% sure we don't exactly pay FAANG-competitive salaries there, which affects the quality of who we can recruit there. It's kinda like how we hire engineers in Hyderabad for 1/5 the US rate and then wonder why we more often than not get substandard performance.
No worries at all: I agree with you.
More then just salaries, there's definitely a glut of people chasing the gold rush. More power to 'em (I guess) but it is a bummer for the rest of us.
Unless of course the weighting of his groups is off somehow, which should have been noted.
Actually it doesn't seem like the statement was very informative.
They have no scruples and play politics.
And yet, these scores are measuring something and averaged across tens of thousands of technical interviews, you have enough statistical power to average out the particularities of each interviewer.
I'm sorry you find the results repugnant, but the results are what they are. And the article did have a large section on limitations of their analysis.
Of course it has real world validity. It has real world validity regarding how well people are likely to do in tech interviews.
You can feel free to say that the way the tech industry does interviews is bad, or biased, or has all sorts of problems. But having vague measurements, such as "technical" or "communication" skills sounds very accurate to how tech interviews are actually done, in the real world.
All the moral outrage everyone is having about this, seems to have nothing to do with the accuracy of the report, which is about measuring tech interview performance. And it instead seems to be regarding the tech interview process in the industry, in general.
I'm not buying this as a moral outrage question, I'm wondering if this is adding anything meaningful for us to look at or if it's just a surface-level puff piece masquerading as an analysis.
Over the last 22 years I've interviewed hundreds, hired and directly managed probably close to 100 individuals in widely varying environments, ranging from a 25k employee state university, to startups of various shapes and sizes, to the hottest SV IPO of 2020.
The reason for interview practices to be the way they are is to raise the floor for FAANG, who have high internal complexity and high salaries, leading to a very fat hiring funnel with a high risk of turning into dead weight in "rest and vest" mode once they get inside.
However humans are smart, and interviewers are lazy, so inevitably the people who optimize for this process start beating out more able engineers who don't have the time or inclination to jump through these hoops. In my experience, the proportion of really good software engineers is roughly equivalent across all companies with baseline competent technical leadership. FAANG does have a lot of the outliers on the high end, but they also have a lot of folks who can't tie their own shoes without the support of world-class tooling, infra support, and technical design guidance that those companies surround them with.
The process isn't perfect, and it has some type I errors and a lot of type II errors, but it's a lot better than just throwing darts at a stack of resumes.
Micro-managing, non-technical leadership is the failure mode you're pointing out, and it's definitely the worst of all worlds, far worse than any failure mode at a FAANG. But on the other hand there is also parochial leadership who knows what they don't know and how to trust talent. Those environments can actually be fine for technical people. Granted, they won't necessarily get exposed to the exchange of ideas and mentorship from FAANG, but that's not a deal breaker in the modern internet age, and autodidactism has its place in furthering the state of the art by side-stepping social convergence to "best practices".
And on the flip side, I agree FAANG people are "sharper than average", but there are also headwinds to retaining the best talent. One is that you have to have a tolerance for moving slow, jumping through hoops, and generally dealing with a whole class of friction which many high performing engineers consider bullshit. Some will suck it up and deal with it to get the fat comp packages, but there is now an entire generation of <35 engineers who have had expectations set on comp levels based on a decade+ bull run of tech stocks which I suspect is unlikely to repeat over the next decade. There's also the appeal of working on classes of large problems that is only available at the biggest tech companies, but the actual interesting work is much fewer than the number of engineers. The majority are just dealing with incidental complexity and requirements of scale itself which can definitely occupy the mind, but may lead to an itch for more tangible impact.
Finally I will say there's a middle-ground between FAANG-style interviews and "throwing darts at a stack of resumes". If you are a small to mid-size company without the brand appeal and top-of-the-funnel recruiting volume of a FAANG, then you are absolutely shooting yourself in the foot by cargo-culting the FAANG approach. You know what the alternative is? Have qualified people do traditional interviews, going deep enough to get a gut feeling on their technical competence. Of course you'll get some Type I errors here, so then you have to actually pay attention to what they're doing once they start working. If they are not able to ramp and be productive in a reasonable amount of time, then you have to let them go (or at least pivot them into a position where they don't do damage). Big companies can't do that because there's enough chaos, lazy managers, and HR legal fears that Type II errors are a material risk. In summary, FAANG approach is solving for specific circumstances that most companies don't have, and it leaves a lot of talent on the table which is an arbitrage opportunity for companies willing to do the hard work to think about their recruiting strategy from first principles.
If you're claiming something weaker than that, can you state it more precisely?
The interviews in question are a mix of algorithmic interviews and systems design interviews.
Also, if I ever use "rockstar" or "ninja" in my posts, I hope someone finds me on the street and punches me in the face. I'd deserve it.
Are you sure you'll never find yourself blogging about bands' flamboyant frontmen (or frontwomen), or covert agents in feudal Japan?
I appreciate that you never used "rockstar" or "ninja". That dig was a bit unfair of me.
last thing i want is to perpetuate stereotype threat inadvertently. it's possible to do this right, i think, but we haven't gotten there yet.
I think what we have here is an attempt to imply, consciously or not, a causal link between interview success and previous/current employment. But without drilling into the other factors underlying their success, we get a lot of noise and not enough signal. Couple that with the continued mythologizing of FAANG greatness, and you get an article that perpetuates two of the more toxic notions in tech: FAANG is the top of a pyramid and talent is concentrated in a handful of companies. Neither are true, and neither are probably your intent, but that's how this reads.
Well, FWIW, that's 4 more hours than any of the rest of us...
Why don't you take a leap of faith once in a while on someone who hasn't done well? Especially if you ever interview interns and have a bunch on that team, that's a near zero-cost gamble for a large corp.
Related, interns are a fantastic way to hire because you get WAY better information about them. Instead of an hour or two of riddles, you've got a three month work history which a couple of trusted employees have witnessed. That's WAY better signal than any whiteboard interview problem could possibly get you.
This means absolutely nothing. It's a well known fact that SV titles hold next to no weight.
Except at FAANG; the rewards are so great that the competition is fierce. Whether they gained their levels through engineering ability or savvy politicking, you can be sure they are adept in at least one of the two.
Wait, so the result is that "interviewers from FAANG companies rate highly interviewees from FAANG (and FAANG-adjacent) companies"?
Or maybe more causally: "those who have already passed FAANG-style interviews are more likely to pass interviews conducted by FAANG people"?
I appreciate the mission here - but if the idea here is to give people a fair shot even if they don't have the pedigree of FAANG, building FAANG interview styles into the system seems counter to your stated goals. If anything these results are concerning - you can interpret the findings in (at least) two ways:
- these companies hire or produce superior engineers, the results you got are indicative of a broader higher caliber of engineer in those companies.
- the interviewing exercise is optimizing for "people who can pass/have already passed FAANG-style interviews", which rolls in all of the myriad biases of FAANG hiring and perpetuates them.
the second best performing company on "technical" and "problem solving" was Bloomberg, literally the opposite of Silicon Valley
Think about it carefully - if people rate people as being good at communication, then there is no reason to quantify it any other way. There are some obvious flaws here, like the quantity of data and it's normalization, but it's basically a tautology.
So if a lot of people rate you as a great leader, you are a great leader? Even if you lie to their face and delover terrible results? Objective reality doesn't matter?
So the greatest leader in the world is in North Korea?
Communication is a clearly measurable skill. Just because a lot of people have been sold a lie, that doesn't make it true
Why are you sure it's a myth? My prior would be to believe that engineers at the most exclusive companies with the highest hiring bars that pay 3-5 times more than average would be better programmers. The article is just one data point confirming what intuitively should be true.
If Silicon Valley engineers are no better than anywhere else then someone should notify the execs at FAANG, I'm sure they'd be interested to know they are dramatically overpaying for talent.
I don't understand what is so uncontroversial about this. SV companies recruit the best talent from around the world and it's where the best talent wants to work. Similarly, the best financial talents are in NYC and London, the best actors are in Hollywood etc.
In my [disillusioned] experience, this holds true: Silicon Valley engineers are very good for building throwaway MVPs that they won't have to maintain more than 3 years.
I've been very disillusioned by the quality of the software written by Silicon Valley companies, but in hindsight it makes sense: "Run fast break things" development culture resonates with the "raise VC money every 18 months" business culture, and then look for an exit in 5 years tops. There is no incentive in Dev or Business to really develop good software.
Or that your interview preparation platform prepares candidates better for Dropbox's interview process than it does for Microsoft's. Or that the people who were confident in their interview skills for Facebook decided not to use your platform. Or that these companies have different interview processes and selection criteria (they obviously do) so ranking "best" based on performance on different tests doesn't tell you that much.
There's hundreds of different ways to slice this data to come up with different hypotheses about what's actually occurring.
> At interviewing.io, we’ve hosted over 100K technical interviews, split between mock interviews and real ones.
Something like "We analyzed 100K technical interviews to see which companies employ the people that we feel best performed in our mock interviews" would be more authentic
One of the things I learned from my years in research/academia is that Design Of Experiments in itself is a pretty complicated task. Most experiments/studies are invalidated due to a huge amount of confounding factors and correlations that are not factored in for the experiments.
A cursory visit to r/science comments would show a lot of people who do science for a living providing valid criticism to published peer reviewed scientific studies due to wrong Design of Experiments procedures.
Having lived all this first hand makes me EXTREMELY resistant to take seriously the data, analysis and conclusions of the linked article.
Other than that, the effort is appreciated and I like the ideas behind interviewing.io.
Turns out it takes a lot more than a high leetcode bar for your interviews to run a successful company.
Not because you get good work done, but because people will apply because you look good on a resume.
His response - “It would be helpful if they then showed how that is used in real world code“. I had to tell him I don’t think these kinds of scenarios come up often in real-world use cases, haha. They are essentially coding puzzles to filter for people who are good at solving coding puzzles, which may or may not directly translate to being good at writing application code.
The interview process is fairly long, accompanied by an office tour which touts the numerous "Freebies" they offer their employees. Then you find out after the entire process that you'll be getting paid 4050K LESS THAN the industry average. At the time I interviewed with them, I had five years experience in UI/UX and mobile development. What they offered me was essentially what I was making as an entry level dev.
It was easy to turn them down. No amount of free Red Bull is going to pay my mortgage.
At any rate, it doesn't surprise me at all that Dropbox engineers do better than FANG engineers on these technical metrics. The average Dropbox engineer is almost certainly a bit smarter and a bit better at algorithms than the average FANG engineer. Of course those attributes don't automatically translate into being a better engineer, though, nor do they automatically translate into company success or anything.
Technical interview performance is a high stakes field for which almost all data is cloistered in individual hiring companies or secretive gatekeepers. In my mind, all efforts, even imperfect ones, to share data is a great step here. We should encourage them to continue to share, including pursuing options to anonymize the raw data for open analysis. The field deserves more transparency and open discussion to push us all to be better.
Really interesting to see dropbox so high - would be curious to see some other data to corroborate that they (at least used to) employ the best engineers.
From my time interviewing, I've seen clusters of very good candidates often be more reflective of which top companies were having a hard time, internally or externally. There was a while where my company hired a lot of people from Uber; right now we're getting Amazon and Facebook/Meta.
good luck with that
But where would the best go ? where the worst engineers are ? to appear even smarter ? or just a bit below ? to avoid toxic workplace.
I'm also not sure how it is at other companies (at Google but haven't gone through interview training yet), but Dropbox's rubrics are also pretty strict. Doing "well" on a question requires getting through multiple parts normally with close to zero bugs that you don't catch yourself.
Dropbox asks difficult questions, and it's hard to discern why. I don't believe the problems at Dropbox are particularly difficult relative to its peers. I don't think they innovate at a clip that's outsized, etc.. But they do this, and their engineering culture focuses on this.
That said, I think what I noticed at Dropbox is that asking lots of tough questions gets you a lot of pretty talented folks who are very interested in solving hard technical problems. So from an infrastructure side, Dropbox was overflowing with talented people. From the product side, though, it was harder for teams to staff frontend projects or make progress when their ideas were challenged by infra.
Startups ask questions 80% of engineers can answer because they don't have many applicants. Dropbox might have 50 decent applicants who could all probably do the job for every opening. How do you decide who gets it? Ask an easier question and you end up with way more passes than you have openings.
My point is Dropbox asks questions that are beyond what its peers ask, even companies not its peer (FAANG, which we don't think Dropbox is apart of).
This is an explicit decision by the engineering leaders at Dropbox. It's interesting, and I'm wondering if it works for them.
Then just take your chances. Rinse and repeat.
When you're young it might be worth it but to me the cost/benefit isn't worth spending months over preparing.
1. interviews are black boxes - there's no feedback; getting feedback from a professional interviewer is the best way to understand one's weaknesses
2. dealing with pressure in simulated environment can help (a lot, for some) to handle pressure in a real one.
I had no idea, for example, why I didn't fare well in a certain type of interview, until I did a mock one.
Last time I interviewed, I did 7 of these interviews, targeting: startups, pre-ipo, mid public companies, 2 of the FAANG I would never work for ...
I did that while prepping for interviewing at the companies I was really interested in working for. And eventually it all worked out and got a few offers, of which two from FAANG of which one from one of the two FAANG I really wanted to join.
That's what I thought about the job I came to SF for 20 years ago. Then 6 years in they got bought out and I got laid off. They weren't even a tech company. My career has been somewhat downhill ever since. Best of luck to you.
I will throw out counter-experience that I did not succeed at technical interviews until I treated it like a fulltime job. In the past I just brushed up and failed Google's interview a handful of times before I decided enough was enough.
My takeaway ultimately is that how much time and effort one chooses to put in is entirely personal based on how much they want one of these jobs + what their gaps are in algorithms and data structures. Some people are going to need more effort than others.
what companies should do is ask you to walk them through a piece of code of your choice and discuss that and/or hire you for a month as a contractor and pay you a fair market rate.
I’ve encountered many who graduated from bachelor and even PhD programs without programming skills (even from European universities), so your statement is false.
It also seems pretty weird to assume that a degree or certificate is foolproof for demonstrating programming skills. That seems like a lack of critical thinking skills.
besides, companies already ask what university you went to and could get your records and individual class grades and use that combined with number of people fired that had the same degree to figure out if they want to hire you or not. after all, we are in the era of data science?
and instead of paying recruiters lots of money for shuffling word documents around, they can use that money to pay prospective candidates for a month. it will be cheaper.
the real reason for coding interviews is to wear you out so they can pay you less. the problem is that people go along with this clown show instead of simply walking away and doing something else.
i interviewed a while ago at a FAANG where they had a long standing problem related to their OS. i knew the solution because i recently brought a product to market built on top of a similar OS and had to address the same problem.
but it was more important to them i passed their coding test within a few minutes, and that i choose the optimum solution, which can only be found if you can spend an hour thinking about it. i bombed the interview due to not being used to coding interviews and having to talk while i think, and having to do all this in a few minutes.
they are probably still wondering how to fix their problem.
There are obviously candidates that struggle with performing under pressure - even those that have gone completely blank, but through some simple guiding have bounced back.
To be frank, at the schools I studied at, it would be impossible to fake your way through a whole degree, unless you either got someone to impersonate you and take your exams, or you cheated your way through every single exam...but even then, your grades would be a big red flag.
Sure, there are bad programmers out there - but not being able to punch out a line of valid code, after obtaining a whole degree in the subject...seems extremely unlikely - sans the extreme edge cases.
Even the straight E / D students I've worked with managed to cobble together working stuff, without the aid of search engines or stack exchange.
also: this is not just the case for scandinavian universities but also the case for universities in most of western europe especially if they are non-private.
I’ve worked with programmers from Scandinavian university degrees and some sucked. Not sure how they passed, but the degree was 15 years old and this was the early 00s.
I interviewed a lot of people and quite a few could not implement fizzbuzz.
Huge risk for anyone who currently has a job. I'd much rather the technical interview.
> spend a reasonable time like a month
Spending a month on interview training is exactly what I would consider unreasonable effort.
Here's a scenario – I have worked at big tech company A for a decade writing backend code. Big tech company B has many openings for senior backend coders, and is desperate to fill them. B's recruiters are hounding me every day to consider a switch. The job looks interesting, and the salary and benefits are great.
Should be a perfect fit, you say? Except if I interview with B today I'll get rejected at the very first coding stage. The barrier to entry they have created for themselves is me taking time away from my current job to solve programming puzzles, solving them perfectly in an interview setting, then throwing away all of that knowledge. They are never going to make me go through this effort unless I am truly unhappy at my current role.
This is the exact reason companies are finding it so hard to hire engineers, and why they have to pay them so much to switch.
I'm not saying that some of my rejections can't do that. But I can't measure what I didn't observe.
I also get mountains of emails from recruiters about how deeply impressed they are with my skills, and how I should go work for their firms. I know that they are completely full of shit, because from looking at my LinkedIn, they have no idea whether or not I have any of those skills.
has worked out well so far tbh most of these interview processes are overengineered and geared towards nonsense
it's funny as a side-effect our teams are probably the most diverse and well balanced across skill level I've seen in my carrer too
I've interviewed four digits worth of candidates, under different rubrics and different expected difficulty levels, and all the good I can say about the modern interview is that at least it tends to crib out the people that can't write code at all, at least if you are making sure nobody is feeding them answers. But can I say that interview performance with me, and how well I rated the person's work when they were hired and ended up working close enough to me, had much to do with each other? I don't think so.
That's why, when working at a small enough place I have some control over the interviewing process, I'll offer options to the candidate, and dedicate far more time to the process than I would in a large software firm. It's OK to just raise the technical bar enormously when you are offering the best salaries in the market, and you can expect to never run out of candidates. But when you are not competitive, you have to do something to find great candidates that don't look wonderful in a FAANG style interview format, but will be very good in practice anyway.
If they become more desperate, things could change, but they don't and things stay the same.
More often than not, BigCo don't need A players, but average devs to keep the wheels spinning and that's where the struggle with hiring is.
- read the whole website of the company I want to work for
- apply
That's it. If after N years of experience I'm not able to pass the tech interviews then I'm not a suitable candidate for them, and I simply accept that. To me, spending a month memorizing and refreshing concepts I learned when I was at uni, feels like cheating (because I'll forget what quickly studied in a few days).
I do "study" on my own constantly, though. I'm always reading tech books and trying new things. I do it at my own pace. Perhaps that's the reason why I don't prepare myself for interviews.
I wonder if you are thinking of the same tech interviews that anybody else here is talking about. Those tests are almost inversely correlated with N years of experience. Without specifically studying for those tests you would definitely score lower than an inferior (but well prepared) candidate.
interviewing.io's best and brightest.
There are plenty of applicants who just can't do the job, and the cost of restarting the search all over again is high. It's important for a team to vet their new hires.
While that definitely matches my observations, the current interview grind:
a) filters out people who can do the job too
and
b) somehow also manages not to filter out people who can't, either.
The tradeoff is that you have to go through the same grueling process every time you change jobs. I think the tradeoff is well worth it and would not like to see software become more like medicine where you have to put in 10+ years of schooling to prove your worth.
If you were a doctor, you would have gone through 4-5 years of supervised residency after medical school (https://en.wikipedia.org/wiki/Residency_(medicine)) to guarantee some minimum level of competency before becoming a practitioner. Pay is notoriously poor and the hours are extremely long.
Programmers have it exceedingly good and the only reason for that is that software is still in its growth phase. I doubt we'll all be still riding the gravy train in another 25-50 years.
- First of all, it assumes that `interviewing.io` is some sort of certification standard (which I'm willing to bet is the actual point of publicizing these 'studies' in the first place. It's 'fact' manufacturing)
- Then there's selection bias about engineers actually using one platform vs the other
- Touting the data set size in order to give the 'study' some credibility is a red flag for me. You can analyze millions of the same technical interview and deduce all sorts of conclusions.
- The use of 'best performers' is deceitful. It means 'best performers in the interview context'. But using it in the context of where do they work, it implies something like 'the best performing engineers are at company X'. Which is bullshit. More like 'best trained engineers to pass these interviews work at company X'.
Garbage. I'm flagging this as it's nothing more than self-serving marketing.
And until you can really say for sure this is the case, any speculation about the value of technical interviews other than just being a barrier to entry is really moot.
At the job I'm leaving tomorrow, I just did a 2 hour long video session / training where I started by teaching how to read call graphs, and that led to over a hour of me trying to sort out a horrible performance issue in real time.
The problem, solution and the iterated debugging to deal with all the edge conditions that the extensive unit tests called out (and I wrote all the unit tests that blew up, so I get to take credit for all that -- although I also wrote the bug I fixed) should show that I'm very high functioning engineer. And I had identified the problem previously at a higher level and had a fix that papered over the problem, but during the video I correctly figured out that the real source of the problem was deeper in the code, and had existed before the change which surfaced the problem, and managed to do a data-driven analysis to track down the perf bug and go from 15% of CPU time in one subsystem to 1% of CPU time in the same subsystem for a 15x speedup on my problem (and probably closer to a 90x speedup for the customers who were reporting it--including a large customer everyone is familiar with here due to headlines they're involved in).
Meanwhile I forgot that it was obj.send(:method, *args) in ruby and tried to obj.call(:method, *args) and had to look that up because my brain was derping a bit on that, and the night before I forgot it was JSON.generate in ruby and not encode/decode and just in general my brain is a mash of too many different programming language syntaxes. At one point I caught myself trying to use `%` for comments because I had been doing Matlab writing an Iterated Chebychev Picard Method IVP ODE solver the prior weekend. If I can't work with the command line or an IDE and with google I'm just going to be a mess of trivial mistakes due to crossed wires.
I've also never reversed a linked list in my life and the correct answer to that question is probably to never use a linked list due to TLB cache thrashing at the very least.
In our experience, they're quite good at retaining talent.
You're admitting that it's much more likely dropbox is a statistical anomaly because of fewer data points, rather than a robust data set.
must be self starter, enjoy high energy postive environment! enjoy coding in RoR etc
Here's what it looks like: https://imgur.com/a/BkzEoGV
I read “where the best performers work” as not where do the best coders/employees/whatever work… I read it as people who perform the best work. Where do people who do the best performance work? And in the context of interviewing - I don’t find this particularly weird to look at. Interviews are a performance.
That said - I’m apparently a weirdo!
Also, limiting this to companies with 50+ employees who have used the platform is going to definitely only let very large companies in the analysis. Even where I’m at now (1500 eng) I would be surprised if 50+ had used the platform because 75%+ were hired in the last 1-2 years.
Also - the way everyone here critiques the rating system - what a joke. You think the rubric at these big companies is really any better? You just find a way to shove your core feeling into the rubric and that’s it.
For skills, balanced team makes sense. You put a 10x type person in a room full of 0.5x people then yeah they'll start complaining about the chair color because the job sucks and they would kill for the chance to get on a better team.
The very best people I've ever worked with don't fit any of those characteristics you've mentioned.
Although I will say if a developer of yours wants a different chair, get them a better chair. They aren't that expensive and they are durable. Sometimes the overhead of getting $1000 purchases approved adds up to almost the same as the purchase itself. Give your developers some leeway to order equipment, software, books, etc... without approval up to some reasonable limit. It won't cost the company that much and your people will be happier and feel trusted.
Isn't that the definition of career progress? I don't think it applies to developers only.
Best wishes!
I'm curious if people just really need to learn the talk and the walk of a silicon valley employee to land a job at a FAANG.
can you elaborate on that please?
> Look at the failings of the IQ test for example.
You are mis-interpreting the point of all of this. This website does practice interviews. It doesn't measure how good of an engineer someone is, or how smart they are, and they don't claim to do so.
Instead, it measures how good they are at tech interviews. And for that purpose, the study works well enough.
But there's no inverse analysis: of people who worked at these companies, how predictive was that overall of a higher score on this particular assessment?
'Our five highest scores ever were all people who wanted to leave FooCo' tells you little about the overall quality of FooCo employees. Maybe the rest of them are terrible and these five needed to get away?
Well, live by the equity sword, die by the equity sword: SP500 is up 16 percent in the past year, DBX is down 10 percent. Even over the long term, DBX is down 15 percent since their IPO 5 years ago, while SP500 is up 77 percent. It's the kind of performance that results in layoffs[2], which will probably hit your most expensive / experienced engineers first. Glassdoor ratings suggest remote work did not go well when combined with the layoff.
[1]: https://medium.com/@paysa/thinking-inside-the-box-spotlight-... [2]: https://www.reuters.com/article/us-dropbox-layoffs/dropbox-t...
“Unemployed” engineers communicate better than those at Uber, Twitter, Amazon, and Google.
:)
Nobody ever talks about getting good, but not “the best”.
So the most I'll get out of this is to skip the initial screening interview and jump straight to the "real" interview? Or do I even get that?
Are they? I thought that was Amazon.
Anyway, interesting results. Let me do some Dropbox outreach and see how they are.
It should be: have you hired engineers from interview.io
This author is sadly blinded by the echo chamber of their own creation