Live data from Hacker News

How to Ace a Phone Screen

engineering.zenefits.com

21–30 of 54 posts

Re: How to Ace a Phone Screen

#23

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 co…

> 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.

Re: How to Ace a Phone Screen

#24
post #13

Earlier quoted context omitted.

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".

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.

Re: How to Ace a Phone Screen

#25
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.

As a way to get past HR idiots, it may be useful.

Re: How to Ace a Phone Screen

#26

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 d…

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.

Re: How to Ace a Phone Screen

#27
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!"

Re: How to Ace a Phone Screen

#28
post #13
post #5

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. https://www.quora.com/What-is-the-best-way-to-start-my-caree... http://www.businessinsider.com/zenefits-ceo-rescinds-job-off...

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 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!"

Re: How to Ace a Phone Screen

#29

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 co…

> 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 (b…

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.

Re: How to Ace a Phone Screen

#30

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 co…

> 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 (b…

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.

Post reply on HN