This is not really the attitude a company should have when they manage benefits:
On the flip side, with so many people contributing code mistakes are bound to happen. That’s normal – after all we’re all just people, and people make mistakes. One thing that I’ve found particularly admirable about our team here is that people own up right away, and strive to fix things as fast as possible. No one wants to ship buggy code, but it happens. The nice thing about working with so many smart and friendly devs though is that you can trust that someone will be there to catch you if you fall and help you fix things.
We've caught and reported 4-5 bugs in production to Zenefits on really basic features. Three of our employees have now been asked to send a screenshot of the dashboard with the JS console open...
> This is not really the attitude a company should have when they manage benefits
Why exactly? They are talking at the individual employee level, not company wide. The statement above is: "[As an individual developer] it is ok to make mistakes, just own up to them and take responsibility."
They didn't touch on test coverage, integration Vs. unit testing, code reviews, UI automated testing, code quality inspections (both automated and manual), regression testing, external audits, or a whole bunch of other things a company can do to improve the quality of their software over the medium to long term. These exist to help mitigate an individual's errors.
If we take what you said above at face value, you're essentially saying: "It is unacceptable for an individual employee at a company who manages benefits to make mistakes ever period." Which when re-phased like that is patently absurd.
Your anecdotes above may be legitimate reasons to gripe about the quality of Zenefits' software. But these are issues with organisational quality, not individual quality. Individuals can and will make mistakes at any endeavour no matter how mission or life critical, the way organisations detect and resolve these mistakes is what is key to quality, not pretending that people should be mistake free, that's a pipe dream.
I'm pretty understanding of occasional bugs, but Zenefits' site has been one of the most consistently buggy pieces of software I've ever used. Every flow has had broken pieces of UI, incorrect form validation, totally wrong calculations, or some other frustrating flaw.
It's an incredibly useful product (and leagues better than the competition) but when they can't even calculate your 401(k) contribution correctly, imagine what's going on behind the scenes...I'm trusting them with a lot of financial and personal information and it erodes a lot of the trust & confidence I would have in them to see such shoddy work.
The problem isn't with the first part ("it's OK to make mistakes"), it's with the second ("just own up"). When a mistake is made, it's because some part of the benefit coding process failed. I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC. The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.
I really can't speak for the company—it's just a single sentence in a blog post on an otherwise unrelated topic—but I imagine that's what the OP was thinking about.
> I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC.
For electronic engineering this is a known fault mode of inspection.
When the first line inspectors are busy they'll shovel stuff theough with less inspection because there's someone else to do so checking. But now that other person is busy, and they'll shovel stuff through because if the first line of inspectors are doing their job properly it should be okay.
So it's interesting to see this not fail in an indistry tha is data driven and cash sensitive.
It'd be interesting to know what the difference is.
Yeah, lets pretend there is a perfect process and also punish people who own up to mistakes. That is stupidly what most companies do: add more process, make developers stand on their heads. The fact is that certain types of logic errors are likely never to be caught by SCA, code reviews, test cases, or anything else. It's just a fact that bugs are going to get through no matter what. It's is far better to have an environment where fault tolerance is built in AND there is no punishment culture for bringing bugs to light. If you rely on process you will get a) people hiding bugs, b) blame culture c) more disasterous failures.
> The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.
Its interesting to reflect on this statement in the context of Zenefits vs the insurance industry.
When working for a devshop a while back, one of our programmers discovered a SQL injection by using some non-alphabet characters in their health insurance password...
We informed them. Never checked to see if it was fixed :)
This is very much unlike the phone screens I've been through. Most of mine involve the recruiter trying to see if I can back up the words I said on my resume to see if I am worthy for a technical interview.
This article did little to tell me how to ace it other than a little snippet of "I did a cool project to stand out". Which, admittedly, is cool, but I don't feel like it gave many tips on how to "ace" the phone screen. Also the end was basically an ad for Zenefits (well done).
Speaking as a hiring manager, showing me a cool hack is nice but acing a phone screen requires:
* you know something about my company and why you want to work here (visit our corp. site, interrogate the recruiter, read up on our press and know something about our space)
* you know what we're looking for and understand that we're talking to you because there's some intersection between your experience and our search criteria.
* for that intersection in the venn diagram of our candidate requirements and your resume, brush up a little so that you can speak to how you used technology X. If it was 2 years ago or less know it well... if we're talking 10 years ago being more general is fine.
* be able to describe how you got to where you are in your career and where you want to go.
* know who you're talking to in the phone screen and LISTEN to what they're asking you. i can't count how many folks i ask to describe how they built a particular solution go on to just ramble on about feature descriptions and process without ever getting to how something was built.
Anybody with actual experience and skills doesn't give a rats ass about your company's mission. And are you seriously asking devs about where they want to be in 5 years? I hope you're not any older than 30.
I don't think "make a hummingbird with CSS" is really a universal way to ace a phone screen. A more appropriate article title might be "how I aced a phone screen at zenfits.com".
Just make sure not to publicly discuss your deal/doubts about the company or the ceo will tantrum and revoke it. And then, in a bold stand for integrity, edit his answer to remove the offer revokation.
If you read the complaint, the potential employee essentially worries that zenefits won't be technically challenging and it won't be a name brand place that opens doors by having it on your resume. And if we're honest, the 2nd bit is definitely important for your career.
A ceo who isn't a prick might have said we understand your concerns: here's [blah blah blah] reasons that our work is more technically challenging than it may appear from the outside or from your limited time interviewing here, and it's a personal and/or company goal to be recognized for the quality of our technical achievements as a peer of google.
I happen to think that zenefits is not particularly technically challenging and is mostly wiring together integrations with 3rd party systems, but I'm open to being wrong. Nonetheless, this might have won them the employee without being a dick.
Well in fairness he actually is an amateur and is learning on the job. I think he's done something pretty incredible myself. Zenefits really is one of those incredible outliers that is going to the stratosphere. Even an experienced CEO might have some things go wrong in such an extreme example.
He made a public spectacle out of something small and he paid the price in bad publicity. But I've seen worse, by so-called pros. Sometimes people let their ego get the best of them. But that doesn't mean that every decision they've made is invalid.
While I agree that the CEO was an idiot there, I also don't have a huge amount of respect for anyone who judges where they work by whether it is a "buzzword like Uber".
I'm going to be unusually blunt here: I don't buy that name recognition isn't part of your equation (even if only a small or subconscious part). I could be totally ass-backwards wrong. You could have a mental discipline to make these sort of decisions in a far more principled fashion than myself or any engineer I've ever met; but that statement makes me set my Bayesian prior where I set it. At the end of the day, we all know that name recognition _is_ a component to how future opportunities may play out, like it or not, and as engineers trained (hopefully) in the art of considering the possible outcomes and impact of our actions, it would be going against our nature to pretend that having "Google" or "Microsoft" on your resume will not open doors.
College is a prime example of this. Why are certain schools (Ivys, primarily) so highly recognized? Do they universally have better programs? Sometimes, sure, but so much of their cache comes exclusively from the institution itself being a signaling mechanism of exclusivity, and as was put, "buzzwordyness".
In my view, it would be irresponsible to NOT consider any potential added value of positions when comparing them. You are not doing a disservice to either company or your own integrity as an engineer as long as the work you do is sound, and to suggest that you should put your own best interests aside because a given metric isn't "tasteful" seems shortsighted. (I do not mean to suggest that hopping companies to ride trends is something to be looked up to, but that when you make a decision, the more data that helps you obtain a positive outcome the better.)
I think I have a bit more respect for such behavior. Mercenary behavior and making work decisions based on the potential resume-building impact is a completely natural response to the ways in which the job markets have changed since the 90s.
Everyone can, and should, consider how a job will help them advance their own careers. This is exactly why I quit COMPANY_X. At the time, their codebase was entirely based on not one, but two obsolete technology stacks. If I didn't leave quickly, I would have been locked into that narrow ecosystem for the rest of my life, at a "flattened" company with almost zero opportunity for career advancement. It would have been almost like someone deciding to move into COBOL programming starting in 2016.
And I have been frequently laid off as a result of startup failure, acquisition redundancy, or just the company's loss of contract work. There is no longer any loyalty from the typical employer to the typical employee. If you can manage to work your entire career at a single company, you are an extreme outlier, because at many, if an accountant predicts you will be unprofitable next week, you will get laid off on Friday afternoon, with no severance package.
So asking yourself "would this look good on my resume?" is something you should do very frequently, even if you are currently content where you are. We wouldn't need to chase after buzzword-related experience if HR didn't look at those buzzwords when hiring people!
And anecdotally, the name of a previous employer has helped me to get hired at another company. After COMPANY_X, my future co-workers told me at the interview, "COMPANY_X is great! We know they hire only high-quality people, and we also know that the best all want to leave after about two years. PERSON_1 and PERSON_2 used to work there!"
But buzzwords matter. MIT, Stanford, FB, Google all things that make a resume look better. Would you want Java on your resume or JS and React right now? The candidate was absolutely right in the analysis even though it should not have been shared in public.
it's a kid fresh out of college, though -- how is he supposed to know any better? working for a name brand makes the decision a safer decision; i'd put the onus on those advising him to point out why that's not the best metric for making this decision.
When one is at the point where they can kind of pick and choose where they want to go because they have an awesome resume and a great body of work, then let them choose how they wish. If I were going to my first or second job, I would go with Google or Facebook or Uber over a smaller/lesser known company as they would be great signaling mechanisms for my resume for future opportunities.
I like the approach of a small, fun task as "extra credit". But how do you smoothly bring that up in the interview? I guess if you're being asked about CSS technical details, you can mention you built this last night and ask if they'd like to see it. But I'm pretty sure due to nerves, I would make that really awkward. Like I'd answer the phone and shout "LOOK AT WHAT I MADE!"
B. Bring it up when asked about previous experience tangential to it
C. Bring it up when asked about your outside work activities or what sort of continuing professional development you've been doing lately
D. Mention it when asked about the "coolest/most fun" thing you've hacked on lately
E. Whip it out when asked the usual "what do you think we do here and what can you bring to the table"
Or, when you start asking your questions about the company/culture/ect. (DEFINITELY ask those types of questions), weave it in with a question about what kind of side-project or 20% type program they offer/support.
You could also throw it up on a design site or your blog and drop it in whichever social media channel they may have.
Cultivating a curious attitude (or sincerely making an effort to fake it) will help calm your nerves a bit as well.
I viewed his little creation as "extra credit". It shows he knows Sass/CSS and makes him standout from other "boring" interviewees that may have possessed similar skillsets.
Why not make it about their brand? It shows his desire that he wants to work there, and it's also clear he just made this. It isn't some cool thing he did awhile ago and is showing many different companies in interviews. He wants to work there, and that initiative shown will go a long way (and was successful, in this case).
Worst-case scenario is that he doesn't get the job but spent the night learning more about pseudo elements and how the interact with other elements. That's a win-win.
Albert's hack is definitely impressive, and would make him stand out. I'm surprised at some nay-sayers here. Suggesting he use SVG? Nothing impressive about that.
I phone screen a lot, and would be impressed by Albert. However, if you are strong on resume, knowledge, and interviewing, you don't need any special tricks. I think such tricks are important if your resume does not support the position you're seeking: either a mediocre school, no degree, long unemployment, or switching industries.
As for acing a phone screen - no silver bullets here, but it pays to know something about the company and the screener. I know we're just company #923 to you, but don't show that.
Trying to draw by writing HTML text is like pounding a screw. It's the wrong tool for the job. If you want to draw Zenefit's hummingbird, use an SVG draw program. Inkscape is free and can do that job.
The CSS hummingbird is cool. It shows off the awesome ability of the software professional to take a half dozen stupid, illogical constraints and somehow end up with something that works anyway. The problem is that companies would not need to select for this quality if they could avoid imposing stupid, illogical constraints in the first place.
So the obvious followup question I would ask first would have been, "Why did you choose to do this with CSS rather than with a language designed for vector graphics, like SVG?"
Shall we also hire all the other people who can make their cats bark and their dogs meow?
I don't think making cats bark would be very relevant to an Internet technology company, but it would probably be a good sign in a relevant industry (say, a company that trains animals).
That's the point. This person did a neat little project that uses skills which are directly relevant to the job being applied for. The project probably isn't actually useful on its own, but it shows interest and ability.
I also thought about this as well. At first I even thought it was an SVG image. Don't get me wrong, it's pretty damn awesome that he was able to use CSS transforms to create that but...why? I guess it shows how to think critically and maybe he did it in CSS because it's backwards compatible. I don't know. I don't know the backwards compatibility of CSS transforms vs. SVG.
I think the answer is "appear to be the person they want to hire" with the extra degree of difficulty being you don't know the person they want to hire. On the other hand, who wants to be hired under false pretenses? Not I.
Trying to flatter an employer by doing a lot of pointless work is dumb and says something negative about the employers who respond. The "typical" way to ace a phone screen is: 1. be young and just out of college 2. pay more money to the person who wrote cracking the code interview and memorize the problems 3. Scan glassdoor and other sites for interview questions that the interviewers will, as predicted, lazily reuse. The real way to ace a phone screen is not to be involved in one.
Obviously, this isn't something to do for every place you apply to. However, for those at the top of your list, as is mentioned in the piece, riffing their design or code when you're practicing or wanting to expand your skillset anyway is a great idea. Two birds, one stone and all that.
I had the opportunity to speak with Albert on a developer panel and he told this story (we were speaking to software developers that had just begun their job search). He's a very nice guy and I think this is great, general advice for people just beginning to step into the world of software development and don't quite yet have a resume that can "wow" people. I'm glad to see Zenefits recognized that.
Anyone else getting spammed by these guys? I got like 3-4 emails the other day from them, really annoying too, saying the'd looked into what we were doing for our HR etc and thought they could help, except for they were sending emails to an employee who hadn't been with us for a year (email forwarded to me), so not really looking at what we do and how we do it, just disingenuous marketing drivel.
Funnily enough I used to work with Albert Treat at the "biotech startup" in South San Francisco. He's an incredibly talented individual, very driven, and contributed massively to the work done at that company.
Great advice, Albert! I'm glad you like your new job, too :)
On the flip side, with so many people contributing code mistakes are bound to happen. That’s normal – after all we’re all just people, and people make mistakes. One thing that I’ve found particularly admirable about our team here is that people own up right away, and strive to fix things as fast as possible. No one wants to ship buggy code, but it happens. The nice thing about working with so many smart and friendly devs though is that you can trust that someone will be there to catch you if you fall and help you fix things.
We've caught and reported 4-5 bugs in production to Zenefits on really basic features. Three of our employees have now been asked to send a screenshot of the dashboard with the JS console open...