6 ms·

I used to work at Gusto (ZenPayroll back in my day) and dealing with Zenefits was always a pain for this reason. They were the consummate hackers, using screen

by tyre 11y ago

I used to work at Gusto (ZenPayroll back in my day) and dealing with Zenefits was always a pain for this reason. They were the consummate hackers, using screen scraping and automation to do whatever the hell they wanted. One nightmare example was when a bug in their "automated" system rewrote bank account information for tons of employees to just be the last 4 digits of their account number. Such a mess. Even if this weren't a tightly regulated industry, you're dealing with how people are paid and covered for health conditions. We didn't hire hackers[1] because that attitude just doesn't fit for certain classes of problems. Hats off to the investigative journalism by BuzzFeed, uncovering some frightening immaturity pervasive in Valley companies. [1] I authored this post about our hiring at the time: https://gusto.com/blog/zenpayroll-is-not-hiring-hackers/ https://gusto.com/blog/zenpayroll-is-not-hiring-hackers/

deleted 11y ago
[deleted]
mixmastamyk 11y ago
> uncovering some frightening immaturity pervasive in Valley companies. This is one of the dark sides to having an entire engineering team in the 25-30 age range. They can sling http just fine, but sometimes don't fully grasp the consequences of their work.
- tyre 11y ago
  I was 22 when I started and cared very deeply about the consequences of what I was doing. It's more about heavily interviewing for alignment with your mission. If people care deeply about the problem you're solving — not just the technical problem, the people problem — then you're far less likely to have these issues. I interviewed dozens if not hundreds of people at ZP and there were two red flags for engineers: 1) They only care about the technical problems. In this case, they're likely to make decisions more aligned with "that's interesting" than "that helps our customers" 2) Once we raised our Series A, we had a lot of applicants wanting to join a rocket ship. I literally heard that in an interview with a Facebook engineer who found us by "googling startups with 9 figure valuations." If you care about growth at all costs, you're going to cut corners and fuck over your customer. Mission matters. Values matter. Interview for them.
  - SapphireSun 11y ago
    Thanks for that tidbit. I work for a non-profit and sometimes it's hard to make the call when someone is technically sound but doesn't seem to get the mission. So far we've managed to get mission oriented people on board, but I'll make more of a conscious effort in the future.
  - itsjeremy 11y ago
    This is the essence of why Zenefits is in trouble. One of the mantras Parker would frequently state around the office was something very close to "growth is responsible for all of our problems and also the solution to all our problems". His view, if I'm recalling correctly, was that hypergrowth makes customer problems more visible due to scale while making the company inherently more valuable. There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees. As you mentioned in your comment, values absolutely matter. I think Sacks gets this, but a company this deep in with so many employees is a big, unwieldy ship that's hard to turn.
    - tyre 11y ago
      > There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees. I worked at LivingSocial early in my career and this is so true. There is a limit to how quickly organizations can grow (given our current understanding) and still be healthy. Employee happiness and related metrics (e.g. retention) is the biggest indicator of health. I don't care that you hired 400 people this year. Can you retain 40 world-class people?
  - mixmastamyk 11y ago
    Didn't mean to imply it was impossible to care/have awareness to care at a young age, just that it is rare.
    - tyre 11y ago
      I know what you mean, and most of the people I hire end up skewing older. For engineers, experience usually tames the "ooh let's try this shiny thing!" because they have had experience trying to maintain that beta JS framework or been paged at 3am to deal with their hacked together nightmare. It is absolutely more rare to find younger people who are already aligned with that mentality. That's not good or bad, just a matter of fit.
- exw 11y ago
  While there may or may not be a darker side to having an entire engineering team in the 25-30 age range, according to the reporter that wrote the article, this hacking came straight from the CEO, who also set the tone for this type of behavior: https://twitter.com/williamalden/status/697898496314077185 https://twitter.com/williamalden/status/697898496314077185 <<I’m told that Conrad created this program based on a belief that 52 hours was too long to spend in training>>
  - pinewurst 11y ago
    I realize it's the law, but that is an interesting question. I'm a page-at-a-glance reader (not to brag) and sitting in front of something for 52 hours would make me feel like a character from "Harrison Bergeron".
    - deleted 11y ago
      [deleted]
    - cosmie 11y ago
      The 52 hours is meant to be spent exploring inside of an LMS (Learning Management System). You aren't simply reading a manual, but rather going through lessons, taking quizzes on them, working through different scenarios, etc. It's supposed to be an interactive process where you're familiarizing yourself with the information, learning to identify how to handle different situations, learning what "gotchas" to watch out for, and generally reinforcing your recall of the rules and regulations around the industry. The LMS has the actual license exam locked until you've clocked 52 hours inside of it, so the macro just ran out that timer until the broker could get directly to the exam. Scraping by an 80% on that license exam (especially with all of your colleagues around that have taken it already) is ridiculously easy. Insurance companies are sticklers for technicalities and love to deny claims, so as a consumer I'd consider the 52 hours / 6.5 work days worth of required training to be an absolute necessity for an insurance broker. Disclaimer: My current company got our insurance royally screwed up in the short period of time we used Zenefits thanks to their corner cutting, so I'm a bit jaded.
      - 11y ago
- slavik81 11y ago
  I started my career working on software where serious bugs could get people killed. You do need experienced mentors, but they certainly could be under thirty. You don't have to be old to build things safely. You just have to care.
  - nostrademons 11y ago
    ...and have time, and funding, and patience. 2 out of those 3 are in short supply in Silicon Valley. Robust software is eminently possible, but it requires a development culture that is often incompatible with shipping lots of things quickly and seeing what sticks. I recall that when Parker Conrad spoke at the Stanford startup class, he said that he'd been turned down by many VCs, at least one of which said "Well, if you were Twitter, this would be a different conversation." His take-away from that is "Well then, what can I do to become Twitter?" Only problem is that health insurance and 140-character text messages are wildly different industries.
    - chx 11y ago
      As an aside this is something people absolutely do not get. MongoDB haters were always quick to point out how the database can lose data; even after the journal was introduced and that became much harder. But MongoDB failed to explain this same thing well: if you are storing payroll information you need a very robust data storage solution. There's a cost to robustness, however, which you probably don't need to pay when storing 140 character messages. Write concern is a very fundamental business decision. In other words, when I picked MongoDB to store NowPublic SCAN data, before the word NoSQL was in vogue, even, then it was scanning various streams (including the Twitter gardenhose so many years ago) for bits of news and the ability to store lots and lots of small bits of text quick as hell was much more important than keeping all of them. Noone really cared about every single one, we were in the business of surfacing breaking news and we were a very small startup so not needing lots of expensive servers were a huge plus. Obviously I picked a very different data storage model when I needed to store payment data at a TV station's video store...
      - tyre 11y ago
- GauntletWizard 11y ago
  The guy on my team who's a 'hacker' is in his mid 30s. Some people just never grow up. I'm 27, and I'm the guy always arguing with my near-40 boss about trying to do things the right way, not the way that's easiest today. Age is probably the generalization to make, but cargo-cult mentality isn't in any way limited to then young.
  - rhizome 11y ago
    Does his code work?
    - tyre 11y ago
      This is a very low bar for success. When you're working with sensitive information or financial transactions, it isn't just about "working". If your code "works" but is impossible to reason about or untested, you're asking for people later on to introduce bugs. Code is not written in a vacuum. The hardest part, for three nines of software problems, is not just getting it to work. It's architecture and building an engineering team that functions together. People are a major component of software development.
      - rhizome 11y ago
        Not sure what your point is, but thanks for the condescending digression.
- fancy_pantser 11y ago
  I bailed mentally at an interview with a YC startup in SF because, as part of the technical portion, they had me write a scraper to pull information from searches on other sites. This was against each site's legal/usage terms (and so was defeating the basic obstacles the companies put in the way of being scraped in bulk). When I asked about their business model they revealed that they were making money by doing exactly this and had zero intention of changing that or partnering with the other sites to legally obtain the data. Their recent series A made them so cavalier; they landed money to do this, so of course it was right. It would eat into profits if they negotiated contracts to do it aboveboard.
  - AznHisoka 11y ago
    Priceonomics?
    - AznHisoka 11y ago
      No answer means yes.
      - fancy_pantser 11y ago
        Actually no, that guess was incorrect. I just didn't check for replies until now.
  - deleted 11y ago
    [deleted]
- bishnu 11y ago
  I'm not sure how age-related this is. The Valley has started to equate "disruption" with breaking the law. This is its natural consequence.
- SteveGerencser 11y ago
  I wish it was just the 20 something programmer that did this. I know more than a few 40 somethings that never evolved out of the good enough phase of development. They can't even be bothered to test their own code before hitting submit. Everything is just a small bug that can be easily fixed later.
- vasilipupkin 11y ago
  I am not sure 25-30 year old engineers are the problem. The problem is management and leadership
ShaneWilton 11y ago
That blog post is one of the best advertisements I've ever seen for a tech company. If I weren't happy where I am, I'd apply for a position immediately. I get that moving fast and breaking things works for some products, but I wish more companies had the same attitude as you.
- tyre 11y ago
  Glad you liked it! I'm now building software for local government and we've naturally taken that ethos to our new company. If you are ever looking for another opportunity, check us out http://seneca.systems http://seneca.systems
  - toomuchtodo 11y ago
    You had me at "...building amazing technology to unf* government."
  - karmajunkie 11y ago
    I'm not looking at the moment, and not in SF, but having a minimum vacation policy and working on software for governments is impressive to me. Kudos.
  - free2rhyme214 11y ago
    CRM for government reminds me of the Ted Talk where a guy said the government should use source control. We're not there yet but it's a step in the right direction. You guys should seriously consider using resellers and distributors btw. Gov't purchasing agents always request three competitive bids.
    - ncd 11y ago
      That's true if you try to sell into the municipalities via the RFP process. However, we sell directly to the departments who will be using our software. We've met with great success doing it this way. In fact, we managed to close a department in Miami in only six days--that's basically unheard of in local government software sales.
gkoberger 11y ago
Without knowing much about the situation... how much was this necessary? The industries Zenefits are working with aren't exactly tech-friendly, and I just always assumed Zenefits was doing some gross things on the backend in order to make things easier for the user. (This doesn't excuse bad testing or bad code, but it's not like the insurance industry has well-documented public APIs for Zenefits to use)
- tyre 11y ago
  ZenPayroll has an extensive API (I built it.) They did it because they wanted to. http://docs.zenpayroll.com/ http://docs.zenpayroll.com/
  - dcosson 11y ago
    Reminds me of mint.com. I used to work at Venmo and they tried to integrate with us, but then without even reaching out to us they decided they couldn't because of the 2fa on our web login. We had a documented developer API but they seemed to never even consider using it.
selvan 11y ago
Issue you are talking here seems to be about pushing software with a critical bug (a logical mistake by the developer). This issue looks to me as a test scenario that wasn't covered before. I guess these kind of issue could happen at anywhere else too, irrespective of their working (hacking) culture.
- tyre 11y ago
  My problem isn't the bug. Bugs happen. It's that a developer thought that screen scraping a payroll system and setting up a recurring job to overwrite all bank account information in the middle of the night was a good idea. If you care about security and stability, that should have set off major alarms. Scraping data and pushing to internal APIs in another product have no spec, so any tests you write are either wrong or not wrong yet.

by tyre 11y ago

deleted 11y ago

[deleted]

mixmastamyk 11y ago

> uncovering some frightening immaturity pervasive in Valley companies. This is one of the dark sides to having an entire engineering team in the 25-30 age range. They can sling http just fine, but sometimes don't fully grasp the consequences of their work.

tyre 11y ago
I was 22 when I started and cared very deeply about the consequences of what I was doing. It's more about heavily interviewing for alignment with your mission. If people care deeply about the problem you're solving — not just the technical problem, the people problem — then you're far less likely to have these issues. I interviewed dozens if not hundreds of people at ZP and there were two red flags for engineers: 1) They only care about the technical problems. In this case, they're likely to make decisions more aligned with "that's interesting" than "that helps our customers" 2) Once we raised our Series A, we had a lot of applicants wanting to join a rocket ship. I literally heard that in an interview with a Facebook engineer who found us by "googling startups with 9 figure valuations." If you care about growth at all costs, you're going to cut corners and fuck over your customer. Mission matters. Values matter. Interview for them.
- SapphireSun 11y ago
  Thanks for that tidbit. I work for a non-profit and sometimes it's hard to make the call when someone is technically sound but doesn't seem to get the mission. So far we've managed to get mission oriented people on board, but I'll make more of a conscious effort in the future.
- itsjeremy 11y ago
  This is the essence of why Zenefits is in trouble. One of the mantras Parker would frequently state around the office was something very close to "growth is responsible for all of our problems and also the solution to all our problems". His view, if I'm recalling correctly, was that hypergrowth makes customer problems more visible due to scale while making the company inherently more valuable. There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees. As you mentioned in your comment, values absolutely matter. I think Sacks gets this, but a company this deep in with so many employees is a big, unwieldy ship that's hard to turn.
  - tyre 11y ago
    > There was absolutely no downside to growing as fast as your imagination could manage - despite an accumulation of red flags, technical debt, and unhappy employees. I worked at LivingSocial early in my career and this is so true. There is a limit to how quickly organizations can grow (given our current understanding) and still be healthy. Employee happiness and related metrics (e.g. retention) is the biggest indicator of health. I don't care that you hired 400 people this year. Can you retain 40 world-class people?
- mixmastamyk 11y ago
  Didn't mean to imply it was impossible to care/have awareness to care at a young age, just that it is rare.
  - tyre 11y ago
    I know what you mean, and most of the people I hire end up skewing older. For engineers, experience usually tames the "ooh let's try this shiny thing!" because they have had experience trying to maintain that beta JS framework or been paged at 3am to deal with their hacked together nightmare. It is absolutely more rare to find younger people who are already aligned with that mentality. That's not good or bad, just a matter of fit.
exw 11y ago
While there may or may not be a darker side to having an entire engineering team in the 25-30 age range, according to the reporter that wrote the article, this hacking came straight from the CEO, who also set the tone for this type of behavior: https://twitter.com/williamalden/status/697898496314077185 https://twitter.com/williamalden/status/697898496314077185 <<I’m told that Conrad created this program based on a belief that 52 hours was too long to spend in training>>
- pinewurst 11y ago
  I realize it's the law, but that is an interesting question. I'm a page-at-a-glance reader (not to brag) and sitting in front of something for 52 hours would make me feel like a character from "Harrison Bergeron".
  - deleted 11y ago
    [deleted]
  - cosmie 11y ago
    The 52 hours is meant to be spent exploring inside of an LMS (Learning Management System). You aren't simply reading a manual, but rather going through lessons, taking quizzes on them, working through different scenarios, etc. It's supposed to be an interactive process where you're familiarizing yourself with the information, learning to identify how to handle different situations, learning what "gotchas" to watch out for, and generally reinforcing your recall of the rules and regulations around the industry. The LMS has the actual license exam locked until you've clocked 52 hours inside of it, so the macro just ran out that timer until the broker could get directly to the exam. Scraping by an 80% on that license exam (especially with all of your colleagues around that have taken it already) is ridiculously easy. Insurance companies are sticklers for technicalities and love to deny claims, so as a consumer I'd consider the 52 hours / 6.5 work days worth of required training to be an absolute necessity for an insurance broker. Disclaimer: My current company got our insurance royally screwed up in the short period of time we used Zenefits thanks to their corner cutting, so I'm a bit jaded.
    - 11y ago
slavik81 11y ago
I started my career working on software where serious bugs could get people killed. You do need experienced mentors, but they certainly could be under thirty. You don't have to be old to build things safely. You just have to care.
- nostrademons 11y ago
  ...and have time, and funding, and patience. 2 out of those 3 are in short supply in Silicon Valley. Robust software is eminently possible, but it requires a development culture that is often incompatible with shipping lots of things quickly and seeing what sticks. I recall that when Parker Conrad spoke at the Stanford startup class, he said that he'd been turned down by many VCs, at least one of which said "Well, if you were Twitter, this would be a different conversation." His take-away from that is "Well then, what can I do to become Twitter?" Only problem is that health insurance and 140-character text messages are wildly different industries.
  - chx 11y ago
    As an aside this is something people absolutely do not get. MongoDB haters were always quick to point out how the database can lose data; even after the journal was introduced and that became much harder. But MongoDB failed to explain this same thing well: if you are storing payroll information you need a very robust data storage solution. There's a cost to robustness, however, which you probably don't need to pay when storing 140 character messages. Write concern is a very fundamental business decision. In other words, when I picked MongoDB to store NowPublic SCAN data, before the word NoSQL was in vogue, even, then it was scanning various streams (including the Twitter gardenhose so many years ago) for bits of news and the ability to store lots and lots of small bits of text quick as hell was much more important than keeping all of them. Noone really cared about every single one, we were in the business of surfacing breaking news and we were a very small startup so not needing lots of expensive servers were a huge plus. Obviously I picked a very different data storage model when I needed to store payment data at a TV station's video store...
    - tyre 11y ago
GauntletWizard 11y ago
The guy on my team who's a 'hacker' is in his mid 30s. Some people just never grow up. I'm 27, and I'm the guy always arguing with my near-40 boss about trying to do things the right way, not the way that's easiest today. Age is probably the generalization to make, but cargo-cult mentality isn't in any way limited to then young.
- rhizome 11y ago
  Does his code work?
  - tyre 11y ago
    This is a very low bar for success. When you're working with sensitive information or financial transactions, it isn't just about "working". If your code "works" but is impossible to reason about or untested, you're asking for people later on to introduce bugs. Code is not written in a vacuum. The hardest part, for three nines of software problems, is not just getting it to work. It's architecture and building an engineering team that functions together. People are a major component of software development.
    - rhizome 11y ago
      Not sure what your point is, but thanks for the condescending digression.
fancy_pantser 11y ago
I bailed mentally at an interview with a YC startup in SF because, as part of the technical portion, they had me write a scraper to pull information from searches on other sites. This was against each site's legal/usage terms (and so was defeating the basic obstacles the companies put in the way of being scraped in bulk). When I asked about their business model they revealed that they were making money by doing exactly this and had zero intention of changing that or partnering with the other sites to legally obtain the data. Their recent series A made them so cavalier; they landed money to do this, so of course it was right. It would eat into profits if they negotiated contracts to do it aboveboard.
- AznHisoka 11y ago
  Priceonomics?
  - AznHisoka 11y ago
    No answer means yes.
    - fancy_pantser 11y ago
      Actually no, that guess was incorrect. I just didn't check for replies until now.
- deleted 11y ago
  [deleted]
bishnu 11y ago
I'm not sure how age-related this is. The Valley has started to equate "disruption" with breaking the law. This is its natural consequence.
SteveGerencser 11y ago
I wish it was just the 20 something programmer that did this. I know more than a few 40 somethings that never evolved out of the good enough phase of development. They can't even be bothered to test their own code before hitting submit. Everything is just a small bug that can be easily fixed later.
vasilipupkin 11y ago
I am not sure 25-30 year old engineers are the problem. The problem is management and leadership

ShaneWilton 11y ago

That blog post is one of the best advertisements I've ever seen for a tech company. If I weren't happy where I am, I'd apply for a position immediately. I get that moving fast and breaking things works for some products, but I wish more companies had the same attitude as you.

tyre 11y ago
Glad you liked it! I'm now building software for local government and we've naturally taken that ethos to our new company. If you are ever looking for another opportunity, check us out http://seneca.systems http://seneca.systems
- toomuchtodo 11y ago
  You had me at "...building amazing technology to unf* government."
- karmajunkie 11y ago
  I'm not looking at the moment, and not in SF, but having a minimum vacation policy and working on software for governments is impressive to me. Kudos.
- free2rhyme214 11y ago
  CRM for government reminds me of the Ted Talk where a guy said the government should use source control. We're not there yet but it's a step in the right direction. You guys should seriously consider using resellers and distributors btw. Gov't purchasing agents always request three competitive bids.
  - ncd 11y ago
    That's true if you try to sell into the municipalities via the RFP process. However, we sell directly to the departments who will be using our software. We've met with great success doing it this way. In fact, we managed to close a department in Miami in only six days--that's basically unheard of in local government software sales.

gkoberger 11y ago

Without knowing much about the situation... how much was this necessary? The industries Zenefits are working with aren't exactly tech-friendly, and I just always assumed Zenefits was doing some gross things on the backend in order to make things easier for the user. (This doesn't excuse bad testing or bad code, but it's not like the insurance industry has well-documented public APIs for Zenefits to use)

tyre 11y ago
ZenPayroll has an extensive API (I built it.) They did it because they wanted to. http://docs.zenpayroll.com/ http://docs.zenpayroll.com/
- dcosson 11y ago
  Reminds me of mint.com. I used to work at Venmo and they tried to integrate with us, but then without even reaching out to us they decided they couldn't because of the 2fa on our web login. We had a documented developer API but they seemed to never even consider using it.

selvan 11y ago

Issue you are talking here seems to be about pushing software with a critical bug (a logical mistake by the developer). This issue looks to me as a test scenario that wasn't covered before. I guess these kind of issue could happen at anywhere else too, irrespective of their working (hacking) culture.

tyre 11y ago
My problem isn't the bug. Bugs happen. It's that a developer thought that screen scraping a payroll system and setting up a recurring job to overwrite all bank account information in the middle of the night was a good idea. If you care about security and stability, that should have set off major alarms. Scraping data and pushing to internal APIs in another product have no spec, so any tests you write are either wrong or not wrong yet.