We did the phone screen and the take-home test and asked them to come in for the on-site interview before asking for references. So this was pretty late in the process.
4,250 karma · joined September 17, 2008
It's easy for candidates to exaggerate or misrepresent their accomplishments. This is especially true when they worked on large team projects. For example, if they say "I was part of the team that built Google Search", that could be a really impressive thing if they played a key leadership or technical role, or it could be a really unimpressive thing if they hung out while others did the heavy lifting, and it's very hard to tell the difference.
I actually agree with your thesis! You're right that candidates are only willing to put in this level of effort if they are really interested and consider your company a "top 5%" big opportunity.
So it's critical that you convince them that you are in that top 5%! You don't want an employee to join you because their top choices turned them down -- you want to be their first choice.
We regularly won candidates away from Google, Facebook, Uber, Twitter, etc. If you want to build a great team, you're going to need to be able to do this too.
Re: code reviews -- yes, we gave everyone a thorough code review.
The total time spent is higher than most interview processes I think, which can be a struggle for some folks. But I do think it's the right tradeoff.
Regarding why time taken is an important data point -- we found a strong correlation between people who were able to get good solutions working quickly and people who were able to effectively defend their solutions during the "GoldMine review" in their on-site interview.
We definitely hired non-new-grad non-FAANG engineers. In fact, new grads and FAANG alums were a minority for us.
Hi all - I hope you find this useful!
If you have questions or want to know more I’m hosting a live stream Q&A today on Twitter at 1 PM Pacific. Tune in and bring your interviewing and hiring questions! I'm @startupandrew on Twitter.
Vikrum actually built a browser plugin at Firebase that was simple but incredibly useful. It color-coded cloud settings pages for different environments (prod, staging, dev) to prevent someone from accidentally changing the config in prod when they didn't mean to. We required the whole Firebase team to use it, and it honestly saved us from multiple downtime incidents.
If you're managing a service, I really suggest you try Gold Fig out. You can get the benefit of everything that Greg and Vikrum have learned (painfully from years of real experience) about how to run services and be safe with your config!
(I'm one of the Firebase founders)
Thanks for the love HN! Don't forget to set that calendar reminder for yourself for next June 27th! (and set to repeat annually, of course)!
Yep -- note the title is "Startups I Want to Fund", not "Charities I Want to Donate To".
Note that I also try to tackle some of these non-product-solvable problems through philanthropy, but that's a subject for another blog post...
If your take here is that I'm interested in "rich-white-guy" problems, I'd encourage you to re-read the list from the perspective of emerging and frontier markets. Most of what I have listed there is actually more important in those places than it is in Silicon Valley. For example -- receiver-centric package delivery is a far bigger deal in places that don't have addresses than it is in the US (and billions of people around the world don't have addresses!). Ditto with energy, waste management, etc... even an open web platform is a bigger deal in India than it is here.
Personally, I spend more time these days focused on those markets (especially Haiti and Africa) than I do on the US.
Angel investors almost never provide the bulk of the capital for a startup. We provide initial money, advise, and introductions to help raise more. So, yes, I expect the bulk of the "heavy capital" to come from institutional investors in later rounds.
Also note that I invest in follow-on rounds, so my total investment in a startup might get much larger than $250k.
We do often give credits to help in situations like this, though I can't speak to specifics publicly. We're working with this developer to try to resolve the issue, and we'll do so with other users who run into similar problems. This user did contact support, but we dropped the ball here. We'll be reviewing our support to find other devs we might have missed.
There are a couple of things I’d like to clarify for the group, to help folks understand what happened here, and hopefully help others avoid the same problem.
1 - The Firebase Realtime Database charges for SSL overhead on all requests (we charge for all OSI Layer 5 network usage). We’ve always had a policy of charging this way. Unfortunately, we introduced a bug late last year that began undercharging for SSL, so when the bug was fixed it surprised many people who had gotten used to the lower numbers. For most people, the change was very small. For a small number of people though with exceptional use cases (ie. tons of small network requests from IoT devices without support for session tickets), this can result in a larger change. We identified and contacted developers who were significantly affected, but this customer didn’t get the email. We should have done better. (we mention this change in our FAQ -- https://firebase.google.com/support/faq/ -- under “Why was my Realtime Database reported bandwidth lower than average”)
2 - We recently started actually enforcing overages on legacy plans and our current fixed-price ($25/mo Flame) plan. This is new -- in the past, we allowed unlimited usage on every plan, since we hadn’t built the tools to control this. This meant that many of our developers were getting far more than the listed limits for free. So you may start receiving emails now warning you of bandwidth overages, not because your usage patterns changed, but because we’re now enforcing limits for your existing usage. If you upgrade to the Blaze plan, you’ll start being billed for your full usage amounts -- so double-check your database’s “Usage” tab before upgrading.
I’ll be looking into our profiling tool to see if we can improve it to give a more complete picture of costs.
Again -- I want to apologize to the poster for the poor support experience. If others on the thread have had similar problems and feel they are not getting the attention they want from support, feel free to email me directly as well: andrew@firebase.com
We’re really excited about these new products. There are some big advances on the development side, with a new storage solution, integrated push messaging, remote configuration, updates to auth, etc. Perhaps more important though are the new solutions for later in your app’s lifecycle. We’ve added analytics, crash reporting, dynamic linking, and a bunch more so that we can continue to support you after you’ve built and launched your app too.
I'd suggest reading the blog post for more info: https://firebase.googleblog.com/2016/05/firebase-expands-to-...
This is the first cut of a lot of new features, and we’re eager to hear what the Hacker News community thinks. I look forward to your comments!