
How Firebase Interviewed Software Engineers - vikrum
https://startupandrew.com/posts/how-firebase-interviewed-software-engineers/
======
codingdave
> I don’t believe we ever lost a candidate due to them not being willing to
> take our test. The strongest candidates take their job search seriously and
> are willing to devote a fair amount of time to landing the right job.

This is the part that didn't ring true, at least for me. I believe that there
are some candidates would not complain. But if I am good engineer, odds are
that I already have a job that works well for me. Maybe not the perfect job,
but working well enough that you'll have to give more incentive than just a
job being available before I'd spend a day on a take-home, unpaid project. So
according to the quote above, I'm not the strongest candidate because I'm not
willing to devote a fair amount of time to landing the right job.

Maybe from the hiring manager's point of view, that is even true. But I've
already landed the right job. I work there, every day. If you want to poach
folk like me from a job that is already right, 6 hour take-home tests aren't
the answer. Give us something quicker. Maybe not easier... I believe a
challenging interview process is fair. But quicker.

~~~
mayop100
[author here]

If you're already happy with your current job, and we can't convince you that
our company is potentially a much better opportunity for you, then this is
working as intended.

Interviews are expensive for the company too, so it only makes sense to invest
time in someone who really is excited about switching.

~~~
Gibbon1
This comes across as really arrogant. And is a big big red flag for me.

~~~
s17n
I don’t think it’s arrogant, just realistic - if you aren’t interested in
leaving your current job you probably aren’t going to no matter what the
company trying to poach you does. So for them bend over backwards to convince
you to interview is a waste of time.

~~~
ubercow13
That’s a huge false assumption, of course you might consider leaving if the
interview process was less demanding and impractical? It doesn’t seem
realistic at all. The company is just continuing with their bad interview
process with their head in the sand, telling themselves “it’s okay, the people
who don’t like our interview process probably aren’t any good or wouldn’t move
anyway!”. I mean how would they know.

------
tlarkworthy
I took that interview, and got the job, emigrated to the US from the UK and
stayed for 4.5 years. I had total belief Firebase was the future and I wanted
to be part of it. The challenge was mentally stimulating, harder than most
academic planning problems. It was really hard to exploit the structure. I
spent the full 9 hours on it after restarting my efforts at the 5 hour mark. 9
hours of sustained effort. Its not the kind of effort I would blow on most
interviews, but totally worth it for that opportunity. And indeed, joining
Firebase changed my life fundamentally. In retrospect.... it was such a great
move, time spent exceedingly well :)

Edit: I wonder how much was luck. I definitely aimed for Firebase. I used it
once after seeing on HN and fell in love with it immediately. It felt like the
future, so it wasn't dumb luck, but then, it worked out so very well, I wonder
if I saw a similar opportunity I would be able to leap at it again. Would it
work out again? I guess time will tell.

~~~
koopuluri
Thanks for sharing. It's great to see how leaping at a seemingly small,
fleeting opportunity based on seeing something once on HN had such a great
impact on your life.

------
lbatx
At a previous company, we too would administer a technical test. Our pass rate
was close to what was described in the article (40% for ours vs 25%). However,
our test was incredibly simple. At most, it should have take a competent
developer two hours to complete [including writing comments and a README].

The assignment was to read a file containing a list of numbers (some formatted
incorrectly, so there was some very simple parsing logic involved), call an
API using each correctly formatted number as a parameter, and store what the
API returned to a file. I am to this day stunned that 60% of people who passed
a phone screen could not solve this task. Note that we gave them the input
file, so it wasn't a matter of an edge case tripping them up or them getting
one input file but the test input file having some other edge case.

My point here is that it may be possible to get the same screening value with
much less investment from the candidate.

~~~
pmiller2
We’re the other numbers in your funnel similar as well (phone screen pass, on-
site pass, offer accepted)? I ask this because the numbers I saw in the
article look remarkably similar to approximate numbers I’ve seen or been told
about other companies.

~~~
lbatx
I don't have the stats in front of me, but my recollection is something like
(using the same base number for Phone Screen but our rates):

Applications: 5000 candidates; ~20% pass rate (vs unknown)

Phone Screen: 1000 candidates; ~50% pass rate (vs 40%)

Technical Test: 500 candidates; ~40% pass rate (vs 25%)

On-site interview & reference checks: 200 candidates; ~50% pass rate (vs 40%)

Offer: 100 candidates; ~80% hire rate (vs 60%)

Hired: 80

So by some arguments you could say Firebase was 2.5x as selective (40 offers
vs 100). With a funnel like this, even small changes to the percentages end up
having a larger overall effect.

Unfortunately, we don't have the Applications number from the blog post,
though he says "we considered a great deal more applicants than that [1000] on
paper." I suppose a "great deal" could be anywhere from double to 10x...

~~~
pmiller2
What it looks like to me is Firebase put more emphasis on the technical test.
If you keep your exact numbers, except change the test pass rate to 25%, then
you come out with 62-63 offers, which, by the argument you reference, would
mean Firebase was 56% more selective.

That makes sense to me, because a smaller company needs to filter out as many
people who couldn't possibly get hired at earlier stages, since the later
stages are even more time intensive than code reviewing the technical test.

------
hysan
> Then, after they submitted their answer, we would provide them with a
> thorough and detailed code review (usually by the legendary @mikelehen).

> We treated this code review like a real production code review, and we did
> it whether or not we planned to move forward with the candidate.

First, thank you for actually investing time in giving feedback to candidates
regardless of their performance. Second, did you tell candidates that they
would get detailed feedback or a code review as part of the instructions or
phone screen? If yes, I figure that this would greatly affect how willing
people were to doing the assignment.

I've always hated the thought of take home assignments because I have never
been given detailed feedback and only rarely been given any feedback. Requests
for feedback are always ignored regardless of performance. I sense that part
of why people have greatly soured on take home assignments is because of how
lopsided the time investment has become.

~~~
merpnderp
If people knew they were going to get a free code review by a notorious
developer, they might submit without any intention of taking the job. Having
someone who knows there stuff look over your code and give you detailed
pointers on what's good and bad, is like finding water in a desert for most
devs.

~~~
nefitty
Any good resources you can recommend to improve my own code review skills? I'm
keen on drilling into the most valuable skills needed in the industry right
now. It sounds like good code review is super important but lacking.

~~~
ericmcer
It's really difficult to actually do a thorough check of logic , exploration
of alternate approaches, performance concerns, etc. in all your code reviews,
it would be an insane amount of time spent and probably no real return on
investment for the company (obviously devs would love to spend a couple hours
weighing the merits of different approaches to a problem).

I have a list of checks to run through, some general (Sass variables used,
reusable code/components used if possible, variables have meaningful names),
others more specific to our codebase conventions. I add to the list as new
conventions get prioritized and check it. Code review is more about
maintaining codebase consistency than suggesting alternate solutions to
problems for me.

~~~
inertiatic
A rare post in that it's entirely a coin toss whether it's meant to be irony
or not.

------
fishtoaster
I've seen a lot of companies that, like firebase, try to assess if a candidate
"is excited about our company" early in the process.

It always seems weird to me. I barely know you- why would I be excited? Ask me
at the end of the onsite after I've talked to a number of people across a
variety of roles, seen your office, heard about the work, explored the
culture, etc etc.

During the initial screen, I really only know about your business, which is
not the biggest factor for me.

~~~
ses1984
The cynical side of me thinks that candidates are screened for this because
screening for things like technical ability and communication skills is
actually really hard, so we screen for this easy thing instead.

I wonder if "excitedness about the company early in the interview process" is
in any way indicative of on the job performance later on.

~~~
gwbas1c
I find it's a lot easier to work for someone if I personally want their
product; compared to a product that I have very little interest in.

------
kamyarg
> The strongest candidates take their job search seriously and are willing to
> devote a fair amount of time to landing the right job.

... only for the 1-2 top companies they are interviewing for.

I have discontinued multiple interviews because they demanded 4-5 evenings of
work for free on short notice, if I am going to spend 10-20 hours per company
I have to take two weeks off from my current work to do it. On the other hand
I have done the required work if I really want to join a company, but they are
only top 5%.

Another problem is, usually what is expected and how the project will be
judged is not mentioned beforehand;

\- so do I write unit tests?

\- do you want docs for running it?

\- should it include deployment instructions/code?

\- does have to support 5000 req/s?

\- how important is clean code for this?

each add more time and these kind of question are never ending.

So unless you are Stripe, Airbnb, Netflix, etc. (Very strong Engineering and
better than average culture), I will not bother, will say thank you and be on
my way.

Finally, let's say you have done the project and they reject you, they never
put a fraction of the time you spent to give you feedback. because that means
a lot of time they will spend on someone that will not be hired. Also might
open the way for litigation for discrimination in some countries etc.

On the other hand; Once I was managing hiring process of a new grad where we
asked her to design a FE+BE system, after receiving it I spent a couple of
hours reviewing it, we decided to hire her, she was very enthusiastic and
smart, I also sent her our notes and how she can improve the project. Her
response was along the lines of "even if you don't hire me I am very grateful
for doing the project, did learn a lot" She joined and quickly became a very
productive colleague.

Edit: I noticed that the author mentions they keep in touch during the project
and provide a code review, had not seen that yet while writing the comment. In
that case it makes sense, but the candidate should know they will receive
feedback even if they fail which I believe is hard for the team to accomplish
but kudos if they did manage to do it.

~~~
graphememes
As someone who has given take-home tests let me answer these for you:

\- Unit tests? Yes. It will increase your standing.

\- Docs? Absolutely. A must have. You will not be considered really otherwise.

\- Deployment? See above.

\- Support 5k requests? Not unless that is what the test is testing for, pay
attention during phone interview about the role and it's requirements, the
test will look for this and other generalizations.

\- Clean code? Very, very important. Don't try to show how smart you are, show
how audience aware you are. Most likely you will be working on a team, a team
doesn't want a cowboy programmer.

Something you didn't mention but bodes really well for anything with a front-
end interface: hosting. Executives hate running things themselves, so a hosted
version will put you at the top of the list.

~~~
james_s_tayler
I like how this is what interviewers are looking for and then you get hired
and there are no tests, the code is a mess and the performance sucks.

~~~
raverbashing
And they ask a hard algorithmic/CS problem then your job is to build CRUD
interfaces

~~~
james_s_tayler
You nailed it.

------
gymnast35
I interviewed with Andrew in Google for an internal team transfer as a
Software Engineer. At the end of a very strange non-technical 30-minute
interview where he sounded like an important and arrogant upper-management, I
asked him what he was looking for and his reply was he wanted to hire someone
that he liked and wanted to work with. That's seriously what it boils down to.

I cannot take this article seriously. And "a history of working on challenging
projects with real deliverables" sounds ridiculous, when you know they hired
people straight from bootcamps as engineers.

~~~
mayop100
I’m sorry you feel I was arrogant.

I really do want to hire people “that I like and wanted to work with” though.
I would hope most managers do.

FWIW we never technically interviewed internal transfers inside Google (we
counted on Google’s normal interview process to maintain the bar). We were
just looking for team fit in those discussions.

I’m disappointed you would belittle bootcamp graduates. Many of them are
awesome, and we were lucky enough to hire one amazing one. And yes he did have
a “history of working on challenging problems with real deliverables”, just
not the CS kind in this case.

------
gwbas1c
This article is worth reading just for the description about the take-home
coding challenge.

I agree that 4 hours is a good target, and that the coding challenge must be
fun and in an language of the candidate's choice.

> One common objection I’ve heard to take-home tests is that they are too time
> consuming, and candidates won’t be willing to do them.

As a candidate, I encountered this situation twice, but it was because the
coding challenge was poorly designed.

In one case, the coding challenge basically required me to learn two major
Java frameworks. As I had minimal Java experience and never touched the
frameworks, I estimated that it would take me 2-3 days just to understand what
someone else could probably do in 2-3 hours. I have no desire to be a
framework jock, so I walked away.

Another time, I did a challenge for an open-source company. They had a list of
some bugs, and I picked what I thought was easiest. The language wasn't one
that I did any work in. No one responded to my questions, so again, I walked
away.

------
elbrian
I feel so fortunate that I have never been desperate enough to even entertain
the idea of working for 8+ hours, for free, as part of an interview process.

Yikes.

~~~
commandlinefan
I keep reading that there’s a huge shortage of competent software developers.
Then I keep reading that employers are kicking applicants in the teeth over
and over as many times as they can get away with. Something about this doesn’t
quite fit.

~~~
mianos
The other thing that is often odd is they place an ad for a position and list
very specific domain knowledge and they say 'before we will consider you, you
need do this arbitrary four hour on line coding test'. Here in Sydney we have
a couple of trading firms complaining they can't get staff. I often think now,
being able to confidently do the job needed very well, is not a primary
requirement. When I say well, I mean, well coded, well documented, good
design, not just able to solve the algorithm at hand. Are we short of good
programmers or do we have to many?

------
jacobobryant
"As a startup, process speed and transparency are your secret weapons when
competing for candidates with large companies."

Amen. I've known people who got through Google's interview process, but even
then the response is "Great job, we'll let you know within a few months if
there's an opening on a team you can join."

Not a great response when you're graduating soon and you've got concrete
offers from other companies that will expire.

------
anthonybsd
>The whole test was designed to take 6 hours.

Pre-Screening to get to an onsite interview taking 6 hours? I'm sorry, but
this is the exact toxic interview culture that is poisoning the job hiring
process in tech startups.

>Some of our employees enjoyed the test so much, in fact, that they continued
working on their solutions after they were hired

Jee, I wonder if that had anything to do with the fact that they were, you
know, new employees? As in, trying to put their best side forward and make a
great impression? Did it even occur to you that you are inadvertently
increasing their workload with your downright torturous screening process?

------
jlev
I'm currently on the job market, and have done a few of these types of take-
home tests over the last two months. If they're well structured, as it appears
here, they can be fun and hopefully build enthusiasm about the company. If
they're not, it's a huge red flag. A company that doesn't value my time as a
candidate is unlikely to do so as an employee, and isn't one I want to work
with.

If you do this, make sure to treat candidates with respect and humanity. Give
them some feedback at the end of the process, so they know their efforts
aren't wasted.

------
shubidubi
2 issues i have with this "process":

1 - take-home task of "only" 6 hours. that's on top of the onsite (~6 hours)
and a few hours for phone call and followups. that's too much for an unpaid
job.

2 - they try to find people they know to sniff around about the candidate.
that's usually bad as you can jeopardize the candidate's current job (usually
people interview while still working at another place). overall this post made
me want to work at firebase even less now.

------
01100011
Take home tests are fine by me, but before you ask me to do that you better
have sold me on the job first. If I really want the job, no problem. I expect,
however, that spending 6 hours of my weekend on unpaid labor translates into a
shorter on-site if you like the quality of my work. The goal of the on-site
should be to verify that I was actually the person who did the work for the
take-home.

Things are a bit different when I'm some schmuck off the street begging for
work. If you're trying to build a team and you want my skills, well, in this
market I'm not putting a lot of energy into it.

Case in point, I've had a company trying to hire me for over a year now.
They're in consumer electronics and it is a fickle market so I kept turning
them down, but I had a bad week at work and figured I'd go for it. I'd be an
absolute perfect fit given my experience and what they're looking for, so it
seemed like things were going to work out great.

I accept an on-site, do well on a whiteboard coding test and a general review
of my resume, and then one of their senior folks throws me an off-the-wall
algorithm question(random sample a stream of data with uniform probability).
Now, I'm an embedded guy, with an EE degree, and I specialize in "software
engineering". They have many problems I'm perfectly suited to solving. They
really, really need a guy like me(to design and fix drivers, abstraction
layers, facilitate porting to new devices and enable third party clients). But
here's this guy, asking me an algorithm question, and he didn't even explain
it right. I googled the answer(reservoir sampling) when I was finished and
understood the solution in a couple minutes, but it was too late. I was
flagged for 2 more algorithm-heavy, 'cracking the coding' interviews the
following Monday. I really didn't feel like spending my weekend reviewing
bullshit I never use in my job, so I turned down the offer. It's too bad, I
was a good fit for the team, and I was a great fit for the problems they were
trying to solve.

------
TheChaplain
A "take home test" of 6 hours is a waste of my time.

I'd rather spend those hours on a personal project which I can use for
demonstrating to potential employers or perhaps use for a side-income.

------
meuk
Not a place I'd want to work, I think. Two red flags are:

1\. They signal from the first point that all your time belongs to the
company. Taking a test of 6 hours is not something I'd have time for.

2\. Their company value "Give 110%, 33% of the Time" creeps me out. If someone
is not satisfied when you give 100%, _run away_.

------
29athrowaway
Candidates can cheat take-home exams by asking someone else to complete the
assignment. After the assignment, you have to ask detailed questions about the
code, solution approach and trade-offs.

If what you have to offer is above average (compensation, growth
opportunities, reputation, culture) people will be willing to make an extra
effort. If you are offering the same as everyone else, candidates will
deprioritize your interviews.

------
hising
"we had a small team of just 24 exceptional people that I firmly believe was
among the strongest of its kind in the world"

I am absolutely sure that this is something A LOT of companies say and think
about their current setup. Impossible to verify, just something that sounds
great and makes the 24-people group feel special.

------
Optim
(rant)

Startup idea: take away home assignments for a fee. You send us your code
assignment we make it for you. We also provide you with code highlights so you
can understand the code and architecture faster and have something to talk
about on the onsite.

Most of the work is not done by us but by "volunteers" .

Who are these "volunteers" ?

Desperate engineers looking for a role, who are thinking that our fake company
is really wanting to hire them.

We also get in touch with hiring managers and convince them to send take away
assignments in order to increase our market.

(/rant)

I don't like code assignments because they can easily be abused by both
companies and candidates and regardless of my opinion on it I think Firebase
is awesome. I was an early adopter before you got adquired by Google.

------
privateSFacct
This overlaps a bit with RFP processes.

If you get a request for a proposal where the potential customer / hiring
committee clearly just copy/pasted a set of items that don't even fit their
company type or area, or that ask for unreasonable stuff from the start, then
you will save yourself a TON of time by saying thanks but no thanks.

If someone has an interesting set of question or a clean and focused RFP,
fantastic. GO for it, you will enjoy working with them.

Another item - if your customer will need to do some type of work, have a TINY
bit of that in your engagement process. Ie, let's say client will need to
write a lot of text, have them briefly respond to a question in the process.
If they will need to fill out worksheets, have them do a tiny one.

Another one - if they won't tell you what they need or who they are - not
worth it.

------
ngneer
I wonder if the OP can comment on whether GoldMine ended up biasing their
decision to hire in an unintended way. In hiring security researchers, we have
been finding that a lengthy technical exercise is terrific to properly gauge
applicant skills, but that the scores of the test could end up weighing
heavily on the decision to hire or not, potentially at the expense of
unrealized potential. In other words, the candidate may have technical
strengths not captured. I am assuming the approach only works to the extent
that the test is a model of the actual problems the company is trying to
solve. And yet they are looking for generalists. Somehow the test seems
insufficient.

------
nurettin
Really appreciate all the skills and positive attitude they were looking for
and I think every engineer should strive to live up to their standards up
until this part:

    
    
        …is excited about our company.
    

Excitement should be deserved, which means it is a feeling which is acquired
_after_ working together for some time. It should not be required as the
default position in a job interview. To build a great product, you need
seasoned professionals, not gullible hipsters.

------
ttlei
I checked out the Gold Mine problem on geeksforgeeks (assuming it is the same
problem at firebase). Can you explain why it is "potentially impossible" to
get the optimal solution?

~~~
mayop100
That's a different problem than the one we used. We added some additional
complexity that required a search of the entire solution space to get a
provably optimal answer, and then we made the maps & allowed # of moves large
enough that brute force was impossible. So people had to build sub-optimal
search solutions that pruned in intelligent ways.

~~~
estomagordo
Is the problem (statement, input and hopefully leaderboard) available online
somewhere?

I figure it hasn't been used for recruiting in a long time, so there shouldn't
be any downside of that nature to it being so. But there is the invested time
in making it available, of course.

I hardly think I would be the only one thriled to try it just for fun. It
would probably provide a great deal of goodwill for you guys, as well as
further the industry's understanding of what constitutes a good take-home
problem.

------
mherdeg
> One of my favorite interview questions (created by Vikrum) was: “What
> happens after you type ‘[https://www.google.xn--com-
> to0a](https://www.google.com’) into a browser and hit enter?”

Wow, I had no idea who came up with that question first. (see, e.g.,
[https://github.com/alex/what-happens-when](https://github.com/alex/what-
happens-when) ).

When was the first time it was asked? Where?

------
Xenograph
Could you elaborate on how you know "the amount of time a candidate took [on
Goldmine] turned out to be a pretty strong signal."?

------
chank
This is probably survivorship bias at work. A lot of startups have strong
sense of self worth because they believe they are hiring/have the best
candidates with their process. Let's be realistic, you can probably build a
really good team out of just about any sampling of 1000 applicants with just a
regular couple-hour interview process.

------
brownkonas
In a tight labor tech market , unnecessary friction in hiring will be
detrimental until you build a brand (your company is hockey sticking or the
day to day work has wide appeal to devs) or find the “true believers”. In a
downturn , go crazy , set up your gauntlet , and you will find the best that
your network or advertising can produce.

------
alephnan
> If the candidate is traveling for the interview, your company should pay for
> all travel expenses and make sure they have a reasonable schedule and are
> able to get a full night’s sleep the night before.

We're lucky to have this in the software industry as standard practice. Has
anyone had horror stories otherwise?

------
DigitalSea
>The strongest candidates take their job search seriously and are willing to
devote a fair amount of time to landing the right job.

Yeah, maybe if they're interviewing to work for Facebook, Google, Amazon, IBM,
Microsoft or other big-ticket dream companies a lot of developers want to work
for. But, Andrew was talking about hiring for an early-stage startup, before
Google even acquired them.

As a startup, you're asking others to take a risk by working for you. Some
engineers have families, debts and commitments to worry about. Working for an
early-stage startup that might run out of money or collapse is a very real and
likely risk.

It's hard to argue that Firebase was not a roaring success for Andrew and
others. But, expecting a candidate to do a six-hour test for a startup that
statistically might not have succeeded, and furthermore, listing out the
benefits of a take-home test being less stressful and then proceeding to
describe what sounds like micromanagement under the guise of helping (by
calling candidates at the start and during of the technical test).

And we keep hearing there is a talented engineer shortage. Maybe the problem
isn't a shortage, it's companies expecting engineers to be put through arduous
and time-consuming interview processes like they're trying to get a job at
NASA building human-payload rockets. For every company wanting to take hours
and days of your time, there is another company that won't put you through a
BS hiring process and make it faster.

I work for a smaller company, I had two interviews for a front-end engineering
position. I came in, met with the engineering lead and another senior. They
didn't make me do a technical test, they opened up my GitHub profile on a
large monitor, handed me a keyboard and mouse and asked me to pick one of my
repositories and run them through my code and decisions that I had made. I
chose a Javascript library I had built, they asked me things about the
architecture, if I had tests, my thoughts on Webpack and other bundlers. It
was all related to the library and all answers I could easily provide because
I built it. No BS, just a pressure-free interview.

The second and final interview was a coffee with the general manager and the
engineering lead. They gave me more detail about why they're looking for
someone, explained it was a new position and where they saw me fitting. I
ended up having lunch with them and a couple of other team members who joined.
It was all casual and pressure free.

This company offered me $50k more than I was currently earning. It was a
MASSIVE pay bump for me, and I didn't have to sacrifice hours of my family
time just to be told I didn't pass or get the job. It's also a completely
remote position, no commute whatsoever. No wonder this company has been around
thirty years and many of the original hires are still here.

------
aryehof
Smart, compliant, friendly and enthuastic. No problem domain, life or business
experience required.

Sounds neat until one realizes you can be replaced in an instant by one of the
ever growing number of new "graduates" every year.

------
nitwit005
While it's certainly convenient to give everyone the same question, you'll
find that questions asked by even smaller companies get posted online these
days. You then give everyone willing to cheat an edge.

------
mayop100
[author here]

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.

~~~
jakebasile
Your claim that a take-home test is "lower stress" is undercut by the fact
that you time your interviewees on their homework. Why do you think it is
important to gauge how fast a person might be able to solve your toy problem,
and why do you expect your candidates to dedicate 6-12 hours (unpaid) of
continuous time to your company before you've even met them in person in most
cases? Did you consider that this might inherently discriminate against those
with significant time constraints in addition to their current job, biasing
your results to new grads and people without hobbies and/or families?

~~~
mikelyons
How does an employeee having hobbies and a family help with the survival of
the company? It seems that hiring people with a life outside of work could be
in the active disinterest of squeezing the most work for the least pay out of
the human resources that corporations feed on.

~~~
sbilstein
So true. If you can’t code for 6 hours straight without ignoring the fact that
a job change can have an incredible impact on all your life goals and personal
relationships, why are you even a coder bro?

This process is so weak, when I heard about it in 2013 I was like...why would
I ever want to work at firebase?

------
swyx
what kind of dev responds to the “what happens when you type google.com into
the browser” question with “Well, most laptops have mechanical butterfly
mechanism in their keyboards…”??

~~~
dmurray
Right? Most browsers these days are run on mobile devices with capacitative
touchscreens for input.

