Many readers are skeptical about the usefulness of personal AI assistants. This reminds me of what Jeff Bezos said about disruptive technologies [1], which I think resonates well among many tech company executives. You (they) need to be willing to be doubted for a very long time.
Any time you do something big, that’s disruptive — Kindle, AWS — there will be critics. And there will be at least two kinds of critics. There will be well-meaning critics who genuinely misunderstand what you are doing or genuinely have a different opinion. And there will be the self-interested critics that have a vested interest in not liking what you are doing and they will have reason to misunderstand. And you have to be willing to ignore both types of critics. You listen to them, because you want to see, always testing, is it possible they are right?
While there are many legitimate criticism of whiteboard-style coding interviews, I have yet to see a convincing alternative that scales well to the size of big companies. Google [1][2], Facebook et al. hire thousands of engineers per year, meaning they conduct at least 10-100k interviews per year. How do you design a process that is consistent, measurable and efficient at that scale?
This is what I'm starting to think of as the "sympathetic customer fallacy".
Coming up with a scalable hiring filter mechanism that doesn't belittle or frustrate the kinds of engineers are you are trying to attract is fundamentally not the problem of your hirees.
Now, maybe the top engineers will suffer through the process, in which case fine, run the whiteboard interviews. But increasingly, it seems like the real cream of the crop are saying "companies that run these kinds of interviews are too rigid for me to be willing to work for them".
Complaining about it won't actually attract those engineers back, because _your_ hiring process is not _their_ problem. They don't care about your hardships, and why should they?
First impressions matter, and if their first impression of your company is that you make everyone you see jump through arbitrary hoops regardless of merit, it's not really surprising they might not want to work for you. Telling them that the hoops are needed to keep the riffraff out hardly improves your image.
Maybe you'll have to accept you'll have to hire some bad engineers in order to get the great ones, and do the filtering as a longer process.
Maybe it's not possible for a 50,000+ employee company to have a hiring process that isn't belittling.
Maybe there's a third technique others haven't worked out.
But whatever the answer, you can be damned sure that complaining the world is unfair won't actually solve the problem for you.
>But increasingly, it seems like the real cream of the crop are saying "companies that run these kinds of interviews are too rigid for me to be willing to work for them".
I do not believe this for a second. The real cream of the crop comes into these interviews, passes them with ease and sometimes even enjoy the process. The worst companies I've seen had low hiring standards, they let any fool join the company and then that fool will go on to interview other fools and lets them join. It's like a cancer and rejecting a few potentially good candidates is worth preventing it.
I have been hired at both G and MS. In my tenure at both, my connects (performance reviews) have been stellar (you'll have to take my word on that, unfortunately).
At the risk of saying something I should never associate with my professional profile, I have also been rejected at both, in combination ~5 times to the 2 I was accepted. (both prior and post my acceptances at each place).
I reasonably consider myself to be a "good engineer" in a pragmatic, "you pay me money to make your company money" sort of way, however, I would not say I pass the interview process with ease or enjoy it; and would VERY MUCH say the process puts me off interviewing for companies I know behave this way instead of just waiting for a prior coworker who trusts my output to say "hey we need someone"; those latter arrangements have historically worked out far better in the long run for me given both outcomes and ROI of time spent in the process.
While I certainly welcome that I am either a fraud or an outlier, the fact that I've heard similar stories from coworkers I see as very high end engineers allows me to assert at least that this occurs (interviews putting off good candidates) although not necessarily how much.
The fact of the matter for me, at the end of the day, is the common lament: if the interview (and when it is) even VAGUELY about what we do day to day, I will surf without blinking, with the exception of the occasional "culture fit" rejection which I've come to accept in stride, but between those rejections and the sheer volume of "I clearly don't want to be interviewing today so going to make this hellish/I expect a magic question to a problem I prepared ahead of time" that I've seen, it seems divorced from reality that such an often arbitrary and painful process wouldn't put people off it. I recently likened it to be most similar to what it used to feel like to ask out someone in middle school, when you felt somewhat clueless despite your best effort, with low chance of success and high chance of shameful failure.
The majority of people that pass these kinds of interviews are the kind of person who will study for months the various coding interview books. Do you think that sort of person correlates with the "cream of the crop"? There may be some loose association there.
I love whiteboard questions! I've been on both sides, (given whiteboard, handled whiteboard,) and they always tell me a lot about the other person. They're also fun.
To be clear, I can see why big companies prefer coding interviews (it's more "consistent" when interview feedbacks are boiled down to a score), but at the same time I'm not defending it because like many have said it's not a great measure of an engineer's capability. I'm looking at the problem from the employers' point of view.
Give them a computer and some resources. Let them work on a problem for a few hours. Then have a discussion with them about how they approached the problem, any limitations of their implementation, and what they would do if they had more time.
I don't see how whiteboard-style coding interviews can scale any better than that approach.
The thing I don't like about whiteboard: A solid candidate that has a bug near the top of a function ends up looking sloppy because whiteboards don't have "insert". The same candidate making the same bug at the bottom of the function can just erase a closing brace and continue looking marvelous. It's very arbitrary I think.
> How do you design a process that is consistent, measurable and efficient at that scale?
None of these are strict requirements. Individual groups who are hiring can decide best what kind of person will make a good team member, and should be largely charged with hiring one (with some cross-team supervision to remove obvious biases).
It's humans you are hiring, not AWS instances –– a process that easily scales to large numbers (like HackerRank) should be viewed with some skepticism.
I'd argue they are consistent in that every candidate who made it past resume screening is given equal opportunity to partake in a well documented process. Whether or not the process itself is effective is a different question.
Sure, interviewers themselves are inconsistent (accents, prejudice, interview difficulty, etc), but that's not something that can be fully mitigated when every candidate gets a different set of interviewers.
Again, I'm not defending the practice and would just like to have a constructive discussion.
DeepMind reduced Google data center cooling bill by 40% in an experiment. If this effect is real, it probably more than justified the $500m tag Google paid to acquire DeepMind. Google might not have come up with a killer app, but perhaps the real killer app is not in the consumer space.
To be fair, the HN discussion was mostly focused on the lack of substantial details or an actual research paper to back up that claim. Google would probably need to show that only DeepMind, or an equivalent device, would have been presently likely to find the energy savings that it ended up finding.
Just because someone claimed Google manipulated search suggestions doesn't mean they actually did it. The video itself even acknowledged the lack of concrete proofs.
Its a credible claim. Social media apps are a fairly basic kind of CRUD app, and if you forego the complex layers of privacy settings and permissions, monetization schemes, and scalability issues you end up with what amounts to a weekend project for an experienced developer.
Now, social media apps are worthless without the aforementioned features that would have to be omitted to get it done in a weekend, so obviously there's some hyperbole going on with statements like that. However, on a fundamental level its correct. The technical requirements of building a social media app are small/easy and within the scope of what a startup on a shoestring budget could manage if they felt like it was a good business opportunity.
The issues start to pile up only much later down the road. Maintaining scalability after you cross some critical threshold of traffic gets hard, but you don't have to think about that until you're at or near the threshold anyway. Not a lot of barrier in getting started.
I agree that if you strip out all the complexities behind what you see on the screen, then yes someone can definitely build a bootstrap-y clone in a weekend.
What do you mean? I fully believe that a competent developer could sit down and make something like Twitter in a weekend. Especially since the concept and what to do with it is already on display for them to copy.
Now, to create a Twitter clone in a weekend when there's no Twitter to go by? Nope.
If you boil down the entirety of Twitter into just a CRUD app that allows you to post 140 characters at a time, then yes, you can make that in a weekend.
Well, how about recommended posts / people to follow (ML)? Sponsored posts with a buy button (3rd part integration)? Growth and metrics (data analytics)? A software product is never just about pixels on the screen; and trivializing the engineering effort behind it is insulting to Twitter employees, some of whom are brilliant engineers I know.
You could create something that looks like Twitter, but you couldn't create Twitter. Ignoring the network effects and scale that Twitter has is ignoring its primary value.
It's hard for me to get that from what you wrote. It seemed that your point was more that the existence of Twitter means it's easy to reproduce it, but before Twitter, it was difficult to envision a site like Twitter.
My counterpoint is that it's not actually the idea that's interesting, it's the fact that they've convinced lots of people to use it, and have built a system powerful enough to support that scale.
The original comment expressly states a "non-scaling" version of twitter...what is so hard about that? this sub=thread then clearly illustrates what "non-scaling" means and doesn't mean. smh
The poster was stating that writing Twitter was easy, anyone can do it, the only thing Twitter really has going for it are the network effects of having a huge user base and lots of visibility.
I do think that Twitter's biggest asset are the network effects that it currently enjoys, but I don't think that it would be trivial to recreate what they've done in order to create a Twitter competitor. It's not insurmountable, but it's not trivial either.
The original comment was clearly meant to trivialize the engineering. "One guy can do it in a weekend" is hyperbole, it's something you say when you're trying to communicate that anyone can do something in a relatively short amount of time. If there are a bunch of downvotes I would assume they're more for the hyperbole than people actually disagreeing with whether or not one weekend is enough time to write "non-scaling Twitter", which isn't specific enough for anyone to argue about how long it would take to do.
I don't think copying Twitter as a whole is easy nor do I think just anyone can do it. As pointed out, a simple non-scaling version of Twitter could be done by a competent developer in a weekend. I'm a front-end developer and I feel confident I could do it, just not in a weekend.
I fail to see where I am dismissing the accomplishments of the Twitter engineers in pointing out that creating, what is essentially, a RSS feed with a 140 character limit over a weekend would be difficult.
I believe you are complaining over something no one has stated.
On first glance seems like writing in React is way more verbose and cumbersome than the Blaze equivalent. What are the benefits of going the React route?
