zmillman

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.

Ah man, you've been so lucky (and unlucky).

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)

How recently have you used Lever? The job board integrations got a lot better near the end of last year

Outside of GoogBookSoft, every interview process has survival bias and statistically insignificant sample sizes.

Gotta do the best we can ¯\_(ツ)_/¯

Author here! Let me know if you've got any questions :)

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.

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.

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 :)

###

Read more about our position here: https://boards.greenhouse.io/magoosh/jobs/59481

Magoosh -- Berkeley, CA

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.

Read more here: http://magoosh.com/jobs/junior-developer/

Hmm, what about word stemming? I looked up "windmills" and got an empty result set.

Hey aboodman, I was wondering if you've got some other recommended reading for designing offline applications. I'd love to read more about common design patterns.

Junior Developer at Magoosh (http://magoosh.com) -- Berkeley, CA (interns welcome too)

=-=-=-=-==-=

We’re looking for another full-stack developer to join our team building the future of test prep.

Our product helps tens of thousands of students around the world study for their GRE, GMAT, SAT and TOEFL exams and since we're such a small engineering team (in a company of almost 20), you'll be contributing to production from the first day. We ship early and iterate with feedback. We have fun all the time and meetings only when absolutely necessary.

You’ll work with Zach (https://github.com/zmillman) and Zack (https://github.com/zackm) to release new features and keep everything running smoothly. We use Ruby on Rails, CoffeeScript, AngularJS and PhoneGap, code reviews on GitHub, continuous integration with Semaphore, and deploy several times per day to AWS with Capistrano. There's a healthy mix of front-end and back-end work and we're constantly learning new tools and techniques to make us more productive.

Want to learn more about how we hire at Magoosh? Our CEO wrote a blog post: http://magoosh.com/blog/magoosh-hiring-process/

An interest in education, statistics, web applications and startups will serve you well!

=-=-=-=-==-=

Apply online here: http://magoosh.com/jobs/junior-developer/

I knew I recognized you from somewhere! For those who don't know, nirvdrum's one of the primary contributors to rubber https://github.com/rubber/rubber (it's a pretty critical part of our current infrastructure)

In my book at least, you've already contributed a huge amount to open source and I wouldn't worry about needing to do more :)

Does anyone know how Amazon's Elastic Load Balancers are affected? I can't find anything on the AWS site

Magoosh - Berkeley, CA - Junior Developer (fulltime, intern)

Magoosh is changing test preparation by building applications that students love. We’re a young startup, but we’re profitable, we’re growing fast, and we have wildly positive feedback from tens of thousands of students who have successfully used our applications to study for the GRE, GMAT, and SAT (more coming soon!)

Our technology includes Ruby on Rails, AWS, native iOS/Android, and AngularJS. You don’t need prior experience with any of these (it’s a plus, of course), just solid coding skills and a desire to build 5-star applications.

http://magoosh.com/jobs/junior-developer/

Just a quick usability issue I noticed: The numbers in the Gross (Amount?) column are only differentiated by their color. Red-green colorblindness is pretty common, so it may be hard for colorblind users to distinguish between the two. Adding a minus sign before negative amounts would probably help a lot for them.

Junior Web & Mobile Developer at Magoosh (Berkeley, CA)

We’re looking for another programmer to help us to build the future of Magoosh. We make websites and mobile applications that help students around the world study for exams with video lessons, practice questions and flashcards all made in-house by our expert tutors. We've already helped over 20,000 thousand students study for grad school and we're excited to make high quality education available to everyone.

Because we're such a small company you'll have plenty of freedom and responsibility. You'll be able to get your hands wet in the entire product-building process. Our development philosophy is to ship quickly and iterate with feedback. We care about our students and always make sure they are happy. We have fun all the time, and meetings only when absolutely necessary. An interest in educational statistics, web applications, and startups will serve you well :)

We're profitable, based in downtown Berkeley (right by UC Berkeley) and perks include company-paid general education classes (ever want to take a pizza-making class for free?), team events, infinite snacks and flexible hours.

Interested? Read more and apply here: http://magoosh.com/jobs/junior-developer/

Junior Rails Developer at Magoosh - Berkeley, CA - Full-Time (http://magoosh.com/jobs/junior-rails-developer/)

We’re looking for a friendly programmer to join us in bringing affordable and high-quality online test prep to the world. You’ll work to expand and maintain Magoosh’s various applications on the web, Android, and iOS.

Our development philosophy is to ship early and iterate with student feedback. We have fun all the time, and meetings only when absolutely necessary. We’re a small company, so you’ll have plenty of freedom and responsibility. An interest in educational statistics, web applications, and startups will serve you well.

About you: Experience shipping at least one web/mobile application Strong problem-solving skills High attention to detail Software development best practices 1-2 years of experience with Ruby on Rails A generalist programmer (front-end and back-end)

Why work at Magoosh? -- Magoosh prepares students for school. If you’ve ever wanted to teach students you’ve never met to read, to write, and to ‘rithmetic, Magoosh is the place. We’ve helped tens of thousands of students in over 150 countries prepare for colleges, graduate schools, and business schools.

Magoosh has been around for two years and is growing fast. We’ve grown from an idea to a business, from a single table to a small office, and from a handful of beta testers to thousands of customers. We need more excellent people to continue delivering teaching to the world.

Magoosh is a small team in Downtown Berkeley. Located by the UC Berkeley campus, we're a wisecracking bunch who eat out often. Do you like foosball, root beer floats, and word games? Come join us!

We're using HoneyBadger at Magoosh. It's been working quite well for us. The Capistrano integration for tracking deployments is really handy.

We used to use Exceptional because it was really cheap, but maintenance and bugfixes seemed to have stopped so we made the switch

Magoosh - Berkeley, CA - Junior Rails Developer

-- The company --

Magoosh is a small company delivering online test prep for grad school exams. We focus on high quality content and great customer support.

-- The position --

We’re looking for a friendly programmer to join us. You’ll work with Zach (https://github.com/zmillman) to expand and maintain Magoosh’s various applications on the web, Android, and iOS.

Our development philosophy is to ship early and iterate with feedback. We have fun all the time, and meetings only when absolutely necessary. We’re a small company, so you’ll have plenty of freedom and responsibility. An interest in educational statistics, web applications, and startups will serve you well.

-- Apply --

http://magoosh.com/jobs/junior-rails-developer/

Berkeley, CA ~ Developer Intern at Magoosh (http://magoosh.com/jobs/mobile-developer-intern/)

Us: A small team of 8 wise-crackers bringing online test prep to the world with 10s of thousands of happy students and an office in downtown Berkeley, one block east of BART.

You: A friendly budding programmer interested in shipping code and expanding Magoosh’s web, Android and/or iOS apps

I guess this is a pretty common itch. I scratched our office's with a weekend project. (it's open source if you want to host your own)

https://github.com/zmillman/foosball_tracker

If you don't need the user's timezone immediately for their first request (which I assume is why you can't use a javascript solution), using getTimezoneOffset() works pretty well.

Shameless plug: I wrote a gem to handle this in Rails ( https://github.com/zmillman/browser-timezone )

You should give your submit inputs the 'btn' class for better styling. The default style for submits makes them look disabled.

(you can also add the 'primary' class to provide a splash of color and highlight the recommended action)

Our site (http://gre.magoosh.com) serves up content for a variety of exams, each of which is accessible from a single subdomain. Since content is developed for the exams somewhat independently, we have to be able to roll out releases at different speeds per exam, so we needed a solution a bit more complex than just feature flags -- here's the solution I built:

We keep a table of feature releases, each with a reference to the exam, a slug to identify the feature and an number from 0 to 100 indicating their status in the release cycle (100 = disabled, 75 = alpha, 50 = private beta, 25 = public beta, 0 = full release, etc.). Then each user is also assigned an integer which indicates the point in the release cycle at which they get to see features (0 by default). When we want to give them access to a feature, we just adjust their release access accordingly. All this is controlled through the admin interface.

We then use a helper (in views and server-side), feature_active_for?(feature_slug, user) which returns true the exam has the feature enabled and if the release status is less than or equal to the user's release access, so we can do stuff like:

if feature_active_for?(:lesson_videos, current_user)

# use video template

else

# use plain text template

end

This has worked really well so far, giving the non-technical content producers and customer support the ability to manage releases as they test content. However, the biggest advantage is that we can now give customers access to features before their public release to build goodwill after support requests and gather feedback. (we've been giving out a fraction of the refunds that we did before the release control)

I haven't actually removed any of the feature flags yet (we can reuse the release process for each other exam that we develop content for) but I'll probably remove one when it if becomes an integral part of the product across all of our exams. It would actually be pretty easy to just add to the helper to intercept release status checks and ease up on database requests.

This is probably all a bit more complicated than what you'll need, but I hope it helps.