nateps

What Lever did from the beginning was focus on building an inclusive culture first and let diversity follow.

My recommendation would be to check out Project Include; they've invested a ton in putting resources together: http://projectinclude.org/

Yes. The skepticism was less around whether the goal of D&I is a good thing and whether it might be more important for us to invest in other things for the success of our business.

We believe that inclusion is worth the investment. At the core, creating an inclusive environment is about employee engagement. (https://en.wikipedia.org/wiki/Employee_engagement) One company that studies the importance of employee engagement consistently is Gallup. Here is an interesting article on the intersection of diversity and engagement: http://www.gallup.com/opinion/gallup/190103/using-employee-e... "Engagement and inclusiveness are closely related. Gallup has also found that engaged employees are more likely to say their company values diverse ideas."

We think one action that raised diversity of our engineering team was raising the bar to include evaluating for soft skills in addition to technical skills. In general, raising the bar and having a more rigorous process tends toward more diversity: https://medium.com/inclusion-insights/want-to-hire-more-dive...

Hi! I'm Nate, another one of the Lever founders here. Have any questions about our efforts here? I'd be happy to respond.

Agree this is definitely true in many cases, especially with applicants. Where it can be OK to give candidates feedback tends to be when you have gotten to later in the process with them and built more of a relationship. The article was meant more for the general case. I totally agree a lot of judgement is needed.

Thanks for you feedback on this!

At Lever, we write about what skills we are hiring for in a very different way we call an Impact Description. It outlines the role in terms of our expectations for 1, 3, 6, and 12 months into the job.

Here is the description for our Backend Engineering role, a really cool new role that we're hiring the first of onto our Platform Team to compliment our Full-stack engineering team: https://jobs.lever.co/lever/7ab138b0-b5c8-425d-93ae-2fc2b051...

Check out Lever (YC S12) if you want a tool to help with more of this: https://www.lever.co/hire

I'm one of our founders and CTO, and we individually contact every applicant to our jobs. Lever has the ability to respond via a general email address for your company or your own email, so you can choose the appropriate level of personalization per email template.

Lever (YC S12) is a modern Talent Acquisition Suite, and we hear from our customers that writing rejection emails is really difficult, especially when you want to leave a good impression. Here are some tips we wrote up: https://www.lever.co/blog/how-to-write-human-rejection-lette...

Quill's OT type is compatible with ShareDB, which provides a simple to use backend that takes care of all this coordination. Here is a simple example of using the two together: https://github.com/share/sharedb/tree/master/examples/rich-t...

Agreed. It is likely to work pretty well with a format that is very close to plain text like LaTeX most of the time.

Git's resolution strategy is diff-match-patch of text, so it is a good analogy. However, the thing that Git does that CRDTs and OT string types generally do not is create conflicts requiring user intervention before proceeding.

If you are realtime editing concurrently, this might be acceptable, because the users might be able to see the conflict and resolve it. However, I'd say a clear UI for conflicts is the key reason why Git is able to more intuitively and safely deal with concurrent edits of non-plain text using a plain text algorithm.

We've been developing ShareDB (https://github.com/share/sharedb), a JSON OT system, and using it in production at Lever for 3 years now.

CRDT has some strong advantages in decentralized applications with a need to avoid a central server. But in practice, web apps today do generally have a central server.

I think the core advantages of OT over CRDTs are actually these practical concerns: being able to design transformations that are more intuitive to application developers, easily cleaning up old operation history, and real world production use and examples of the technology already.

One thing OT has enabled us to do that you cannot do as easily in a CRDT is to support turning off publishing of operations when we do large migrations and create huge numbers of ops at once. Because ops have a strict ordering and versioning, clients can lazy get the ops that they have missed if needed later because they submitted a modification on a document or see an even newer op and need the intermediate ops. In a CRDT, you have to make sure that all the clients get all the ops in order to converge. It sounds simple but can be complex in practice.

Another practical issue I'd add is that these algorithms sometimes place the burden of resolving the outcome of concurrent edits at read time vs. write time. With OT, you generally do a lot of complex work to figure out how to transform ops at write time, but when you read, you just read the already fully updated document in its native format. CRDT systems often store the document in a format that can be written to very cheaply as it is commutative, but the work gets pushed to read time when you have to collapse a tree full of all its history into a different data structure, such as a string for text editing. One is not strictly better than the other, but many production systems are vastly more read heavy than write heavy, so less obvious tradeoffs like this can become extremely important in production use.

This is true. To preserve document validity and user intent, an algorithm designed for collaborative string editing will not always work correctly when applied to a markup document such as LaTeX, HTML, or Markdown directly.

It is similar to how you need a JSON type to represent the kinds of edits you can do to a JSON document rather than editing JSON text as a string. The kinds of edits done in text better map to editing a markup language like LaTeX or Markdown than JSON, so you are less likely to notice these issues right away. But if the type is designed specifically for the markup language, user intent will be better maintained through concurrent edits and the document will never end up in an invalid format.

Author of ShareDB (https://github.com/share/sharedb) here. ShareDB is a stable production JSON OT system that powers the entire backend for Lever (https://www.lever.co/). All of Lever's apps, backend services, migration scripts, etc. go through ShareDB. It scales horizontally; over 1000 companies use Lever, including companies with 1000s of employees, like Netflix and Yelp.

There are some simple examples in the repo to get you started. Please let us know if you have any questions getting going!

Lever started as part of YC Summer 2012. From the early days we've building a company that earnestly values diversity and inclusion. As one of our founders, I'm so proud of the authenticity of this post!

Lever (YC S12) Founder and CTO here.

Just want to thank Leighton for putting himself out there with this post.

If anyone has questions or comments about how we approach diversity and inclusion for the Lever team, we'd love to share more. We're by no means perfect, but I feel incredibly lucky to work with our team every day.

Wow, that sentiment rings incredibly true. While the specific use cases may be a bit different, many companies are similarly fed up with the legacy ATS products for internal recruiting. Every time we encounter a recruiter or a hiring manager using a spreadsheet we ask ourselves why. We take design very seriously at Lever, and the workarounds extreme users do are some of the most insightful ways to learn what the real needs are.

Great idea. Actually slightly embarrassed I didn't suggest that since I was a PM on Google Search once upon a time.

Awww, shucks. Love you too! :-)

We certainly do hear from candidates that appreciate how much simpler it is to apply for a job with Lever on a regular basis. Not just that, but when companies have better tools internally, the candidate experience becomes much more personal. For just one small example, when you send an email to a candidate with Lever, we default to sending from your real email address and then use IMAP to sync the emails from your inbox. It is technically more difficult to implement than forwarding the email through some random email address like XXXX123-reply@ats-product.com, but the difference in establishing a real human connection is worth it.

As you point out, there is overlap, but there are some pretty large differences between the needs of recruiting agencies and companies. We believe we can create the best product by keeping focused on the needs of companies doing internal recruiting. As well, the industry is trending in the direction of internal recruiting being used for a larger percentage of hires at most companies. We think this makes sense, because employee tenure is shortening. Companies are learning that recruiting must be an ongoing operational function they are always doing even to remain the same size.

Thus, we've kept focused on the needs of companies doing internal hiring for now.

This is the first announcement that has been published for the current round. We have additional press links from a variety of sites on our press page: https://www.lever.co/press

Thanks for the feedback! It is great to hear that you've been finding that companies using Lever tend to be high quality and are interested in a way to get to them more directly.

Thus far we haven't focused on this, as there are quite a number of job boards from the super general to specialized niches. Actually, most companies have been finding that they are bringing more and more recruiting in house. Agencies and sites like traditional job boards aren't working very well for them. This is a very recent and rapidly moving trend. According to Bersin, an analyst division of Deloitte, in 2011, company websites were the 4th ranked source of hires (just 13%) after Job Boards and Aggregators (19%), Internal Candidates (19%), and Employee Referrals (16%). Three years later in 2014, Company Websites became the #1 source of hires, now 19% with Job Boards, Internal Candidates, and Referrals falling to 16%, 14%, and 12% respectively. Companies are paying attention to what works, and they now realize that making their own website high quality is now more effective than posting on job boards. Of course as someone applying to jobs, that means you are better off going to the company's job site directly and applying there than going through a job board.

I know with our own hiring, we find that the candidates that have invested a bit in getting to know us, reading our blog posts about our internal company culture at https://www.lever.co/inside, or have checked out our open source projects such as DerbyJS (http://derbyjs.com/) do tend to have better motivation alignment. At least at Lever, we take this as seriously as technical or skills fit; we even call our first interview step "Motivations Screen".

Thanks! We certainly have seen a lot of success in SMB because of Lever's modern design. Design is a huge part of what makes the product work so well for such a wide variety of company sizes, from 5 employee startups doubling to 10 all the way up to industry leading public companies like Netflix.

Thanks so much! In fact, statements like this from our customers were our very best asset in fundraising. We literally would not have been successful without you.

The partners at Scale told us this was one of the most important factors in their decision; they told us they almost never see the same kind of customer passion from other Enterprise SaaS products.

100% hear you on HackerRank integration. We've rolled out a number of integrations on the sourcing side of things the past few months, and we are so excited to grow our coverage to every single tool that our customers use alongside Lever. We have a great relationship with the team at HackerRank, so I am looking forward to it as well. :-)

Thanks so much, Chris! Yep, http://interviewed.com/ is an awesome product as well. Glad that YC companies have been moving the needle in the hiring space.

High quality, repeatable assessments of candidate's real work is so much better than unstructured interviews with under-prepared and inconsistent interviewer training. We're looking forward to more integrations with all of the companies providing great tools that improve the relationship between candidates and companies.

Founder and CTO of Lever, here.

We are so thankful to our many users in the YC community. Would love to hear from anyone already using Lever or companies looking for tools to help them refine their hiring process on how we can continue to improve. I'll be following along today and respond to any ideas!

Hiring is the most difficult and important thing most companies and founders have to learn, and we are hoping to do our part in providing software to make it more successful and a better candidate experience. We believe the very best hiring is accomplished by building long lasting relationships with candidates.

Lever (YC S12) | https://www.lever.co/ | San Francisco

Lever makes hiring software for entire company collaboration. It enables recruiters to focus their time on more strategic efforts and managers to easily participate and keep on top of what's happening. Everyone in a company knows that Lever is a tool for them and that they are a part of growing their company.

We're breaking the applicant tracking system mold, and companies from 5 to 5000 people are switching to Lever. They find that Lever is modern, well designed, and a better fit to how hiring gets done today.

We care deeply that the hiring process and environment at Lever is inclusive to all. We strive to make all people feel comfortable being who they are at work.

First and foremost, Lever is product driven company, and our founders have deep product experience from Google, Zynga, and design education at Stanford. We are also committed to innovative technology. All of our applications are written with DerbyJS (http://derbyjs.com/), an innovative realtime JavaScript framework. It is the only open source application framework entirely built around data syncing with Operational Transformation, the algorithm behind realtime conflict resolution in Google Docs, and formerly Google Wave and Etherpad. In addition, DerbyJS has a unique approach to optimized server and client-side rendering, and was an early pioneer in universal JavaScript rendering.

Lever is helping companies build the next-generation workplace, and we are starting with ourselves. We're a small team of just 40 right now, but huge growth is on the horizon. Join us to be part of the foundational team that sets the trajectory for what this company becomes.

https://www.lever.co/jobs

At Lever, we've got roles that are 100% focused on very cool open source technology, such as helping to scale and improve our unique web framework DerbyJS. We are working on cutting edge JavaScript rendering strategies as well as distributed data syncing via Operational Transformation, which is how Google Docs and Google Wave work. We are also excited for our product engineers to get involved in helping to improve our frameworks.

https://lever.co/jobs.html

We use Mongo and currently Mongo is the only database with an adapter for the full realtime synced stack. However, Derby itself can be uses without the ShareJS backend, and it is possible to write adapters for different databases. Thanks for the question!

Another option is DerbyJS (http://derbyjs.com), a framework that I wrote along with the team at Lever to do this from the start. We don't use any kind of DOM or Virtual DOM for server rendering. Server rendering is all done straight into HTML and client rendering is done via DOM methods directly. Glad to see server and cliemt agnostic rendering catching on with other frameworks!