My take is that Lever's features are well-optimized for companies doing outbound sourcing for roles like engineering (e.g. the extension, snooze features, pipeline structure) and where most hiring is owned by managers who don't have time to devote to mastering recruiting best practices (multi-touch sourcing with Nurture, easy scheduling, pipeline management, email sync, reporting).
Ultimately, you save a lot of money by not having to hire dedicated recruiters and recruiting coordinators, and you actually get a much better candidate experience and hiring effectiveness by having hiring managers and interviewers more closely involved in the process instead of trying to translate them through a separate recruiting team.
You know far more about your needs and are able to evaluate how well software would solve them, and the salespeople you've talked to haven't been worth the time....and that's not normal.
You'd be shocked how bad most people are at evaluating software, especially when it's highly technical. Most people don't even know what a reasonable budget is, what their biggest problems are, what would fix them, and what software is actually doing -- so they rely on cheap self-service products or just take marketing speak at face-value and hope for the best.
And a good salesperson is worth their weight in gold. If you're one of those buyers, salespeople should be much closer to an interviewer or consultant for them: approaching sales calls like research to uncover needs you didn't know you had, introducing you to best practices, and tailoring advice to your specific situation. Their goal is to find a mutual fit and stand by the quality of their solution (and should recommend competitors' products if you wouldn't be happy with it)
> And a good salesperson is worth their weight in gold.
Yes, they absolutely are, for both the client and the company. But you have no way of knowing if $randomNewSaas you're looking at has good sales staff or not. A bad sales guy can screw both. Recently we've had an experience with one Name Brand Vendor where the sales guy is promising things that the company doesn't really deliver; for example, we purchased an old bundle at his suggestion and then get sent automated demands to reduce our capacity because we're in excess of what we pay for (even though it's within the capacity of the old bundle).
Good sales staff are excellent value-adders, but far from all sales staff are good.
Here is the job board integration from Lever [1], taken directly from my Lever account.
Here is the job board integration from JobScore [2][3][4], taken directly from my JobScore account. I wouldn't say that JobScore is necessarily all that great either, but it does certain basic things that Lever has punted on.
And yes, that's right. It took me 3 screenshots to fit all of the JobScore integrations in.
Granted, Lever does have a lot more sourcing firm integrations, but that isn't my use case and it doesn't provide value to me.
Male engineer at Lever here, and I can confirm that we don't make hiring decisions based on gender or gender presentation. It's not only highly illegal, but totally not the point of tracking diversity metrics.
The ultimate goal here is not to build a company with perfect representation of the general population, but to build a company which honestly evaluates and rewards the contributions of all its employees (because we believe that those kinds of companies do build better products, businesses, etc.) and you can't do that unless you're inclusive and consistently fair with everyone in the company.
A number like 50-50 gender balance doesn't mean that we've finished building that company (and no company is ever finished). However, an imbalance of gender or any demographic such as age, race, prior work experience (such as government, enterprise, startup), academic background, parental status, etc. at a company usually indicates that there's a blindspot or bug in a company's hiring or culture and it deserves a closer look.
>However, an imbalance of gender or any demographic such as age, race, prior work experience (such as government, enterprise, startup), academic background, parental status, etc. at a company usually indicates that there's a blindspot or bug in a company's hiring or culture and it deserves a closer look.
Why? How are you making this determination? Should your demographics reflect the US population? State population? Hell, why not world population? Why are any of these inherently better or worse than any other?
Hire only the best people, because being the best isn't correlated with gender? And actively recruit from balanced pools (paying attention to gender balance), which is very different from making hiring decisions based on gender? This is pretty straightforward if you're in fact committed to hiring only the best people.
Seems like bullshit. As someone who's been doing a lot of interviewing recently the ratio of male to female SDE candidates is at least 10:1. If we assume that ability is uniformly distributed there is literally no way to get to a 50:50 split or anywhere close to it without discrimination.
If you believe that ability is uniformly distributed, and you're getting a 10:1 ratio of men to women, 9/10 of the men who apply are unqualified. Men are known to apply to jobs they're not qualified for way more than women do.
I have also been doing a lot of interviewing recently and that number seems about right.
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.
I've been hit with this too and it's not pretty at all.
If anyone else is concerned about this, you should talk with your CEO/legal team about early exercise options which can remove a lot of the risk of massive tax liabilities. From my understanding, some companies offer an early exercise option where you pre-purchase the shares and then instead of being able to buy the shares after they've vested, the company instead gradually loses the right to buy them back at the original strike price.
I'm not a tax lawyer, but Google "section 83(b) election" and you'll find more information.
What you're describing is called "restricted stock" (not to be confused with "restricted stock units", which are entirely different). The idea is that you actually buy the shares upfront at the current 409(a) (legal) valuation, but the company has a right to buy them back if you leave. Founders usually get their shares this way, because at the time of founding the valuation is essentially zero. Early employees may take this route too, but usually the company switches over to options after a funding round forces a non-negligible valuation. Some companies (like mine, at least so far) continue to let new employees choose.
The amount you would pay for restricted stock is exactly the same as what would otherwise be your strike price for stock options, assuming the same number of shares.
For an employee, the major down side of choosing restricted stock (assuming non-negligible valuation) is that if the company fails and the stock ends up being worth nothing, you don't get that money back. Whereas with stock options, you have more time to find out if the stock will be worth anything before you buy into it.
The up side is possible tax advantages, but of course I cannot give tax advice.
(All this is information I've learned while being the founder of sandstorm.io; I am not an expert in these things.)
PS. Don't forget to file your 83(b). (Any time you say "restricted stock" to a startup founder, they will instinctively reply with "Don't forget to file your 83(b)".)
You can also sometimes early-exercise an option (if the company authorizes it when they make the grant), which ends up being in practice a lot like buying restricted stock while still technically an option, and I think that's what the parent was referring to.
Weird, what is the reason to do that instead of restricted stock? It sounds functionally identical except more complicated and with possibly worse tax implications.
I'm sure there's some silly accounting reason having to do with option pools and cap tables.
Well since it's an option, the recipient has the choice to either exercise or not exercise, and they can early exercise at any time they'd like, not just on day one, so it's more flexible for the recipient.
On a restricted stock grant, the recipient has to either pay for the shares on day one, or the company gives them to the recipient for free and the recipient incurs a tax liability for the value of the stock on day one.
Magoosh ~ Berkeley, CA ~ Software Engineer (Rails + more)
###
We’re looking for our third full-stack developer to contribute to building the future of test prep.
Our engineering team is small (two developers + you), but we have a huge impact! We already help millions of students around the world study and prepare for their standardized tests with our popular web and mobile apps, and more are signing up every minute.
From day one, you’ll own projects and contribute directly to code running in production and we highly value collaboration, positive feedback, and mentorship.
Our projects usually involve close collaboration with other departments, which means you’ll learn far more than just engineering. The whole company is around 25 people, so you’ll know everyone in the office and have a real say in Magoosh’s goals and business decisions.
If you're an engineer excited about building edTech products, I'd love to talk :)
We’re looking for our third full-stack developer to help build the future of test prep.
Magoosh’s Engineering team is small, but we have a huge impact! We already help millions of students around the world study and prepare for their standardized tests with our popular web and mobile apps, and more are signing up every minute.
From day one, you’ll own projects and contribute directly to code running in production and we highly value collaboration, positive feedback, and mentorship.
The data is stored in postgres, so it should be simple enough to use the Snowball dictionary/stemmer and the tsvector/tsquery functions to sort this out.
What you really want is a lemmatizer (stemming approximates lemmatization). I believe that NLTK has a WordNet lemmatizer, but I don't know much about it.
Ultimately, you save a lot of money by not having to hire dedicated recruiters and recruiting coordinators, and you actually get a much better candidate experience and hiring effectiveness by having hiring managers and interviewers more closely involved in the process instead of trying to translate them through a separate recruiting team.