rjsen

How is this not just management consulting?

Ravel Law (http://ravellaw.com) | San Francisco | Full-time | Onsite

Ravel Law is a new legal search, analytics, and visualization platform. Ravel enables lawyers to find, contextualize, and interpret information that turns legal data into legal insights. Ravel's array of powerful tools – which include data-driven, interactive visualizations and analytics – transforms how lawyers understand the law and prepare for litigation. In today's global and increasingly digital world, Ravel empowers attorneys to benefit from this huge influx of information and find value in it.

In 2012, Ravel spun out of Stanford University's Law School, Computer Science Department, and d.school, with the support of CodeX (Stanford's Center for Legal Informatics).

We're looking for an experienced front-end engineer. We build our front-end in Ember using Ember-CLI, ES6 transpilers, ember-data, and http-mocks for rapid and modern development. Ideal candidates will be skilled in highly dynamic web interface development (HTML, JavaScript, AJAX, jQuery). In addition, candidates should have a passion for engineering unique interactive visualizations with d3.js and potentially canvas/webGL. A flexible front-end engineer with 3-5 years JavaScript experience will excel in this role, but 2+ years professional Ember experience will also distinguish leading candidates.

https://jobs.lever.co/ravel/73e5b4a3-7732-4369-8b3a-d82c934f...

Ravel Law https://www.ravellaw.com | San Francisco, CA | Full-time

At Ravel, we develop the legal profession’s most innovative products for data analysis, visualization, and research - uncovering insights about judges’ rulings, revealing critical cases, enabling lawyers to make data-driven decisions, and more.

Ravel was launched from Stanford University’s Law School, Computer Science Department, and d.school, with the support of CodeX (Stanford's Center for Legal Informatics). We have been featured in Wired, The New York Times, the American Bar Association Journal, and our founder is a Forbes 30 under 30 for 2015.

We are a rapidly growing Series A startup funded by top tier investors like NEA. We offer competitive compensation, equity, and health care. Our culture is extremely dog- and human-friendly. Our office headquarters are in San Francisco, South of Market - conveniently located between BART and CalTrain.

We're looking for Data Engineers (Scala, Spark, SQL) and Data Scientists (Spark, H20, Stanford NLP). Check out the full descriptions and apply at https://jobs.lever.co/ravel.

We're processing the opinions rather than the courts, so we're dealing with millions of documents. Since we're building a network of their citations, it winds up being way too much data to hold in memory on a single node, hence the need for Spark.

Ravel Law https://www.ravellaw.com | San Francisco, CA | Full-time

At Ravel, we develop the legal profession’s most innovative products for data analysis, visualization, and research - uncovering insights about judges’ rulings, revealing critical cases, enabling lawyers to make data-driven decisions, and more.

Ravel was launched from Stanford University’s Law School, Computer Science Department, and d.school, with the support of CodeX (Stanford's Center for Legal Informatics). We have been featured in Wired, The New York Times, the American Bar Association Journal, and our founder is a Forbes 30 under 30 for 2015.

We are a rapidly growing Series A startup funded by top tier investors like NEA. We offer competitive compensation, equity, and health care. Our culture is extremely dog- and human-friendly. Our office headquarters are in San Francisco, South of Market - conveniently located between BART and CalTrain.

We're looking for Front-End Engineers (jQuery, Ember, D3), Full-Stack Engineers (Scala, JS, Mongo), and Data Scientists (Spark, H20, Stanford NLP). Check out the full descriptions and apply at https://jobs.lever.co/ravel.

Ravel Law https://www.ravellaw.com | San Francisco, CA | Full-time

At Ravel, we develop the legal profession’s most innovative products for data analysis, visualization, and research - uncovering insights about judges’ rulings, revealing critical cases, enabling lawyers to make data-driven decisions, and more.

Ravel was launched from Stanford University’s Law School, Computer Science Department, and d.school, with the support of CodeX (Stanford's Center for Legal Informatics). We have been featured in Wired, The New York Times, the American Bar Association Journal, and our founder is a Forbes 30 under 30 for 2015.

We are a rapidly growing Series A startup funded by top tier investors like NEA. We offer competitive compensation, equity, and health care. Our culture is extremely dog- and human-friendly. Our office headquarters are in San Francisco, South of Market - conveniently located between BART and CalTrain.

We're looking for Front-End Engineers (jQuery, Ember, D3), Full-Stack Engineers (Scala, JS, Mongo), and Data Scientists (Spark, H20, Stanford NLP).

Check out the full descriptions and apply at https://jobs.lever.co/ravel.

Have you seen MuMaMo? It does a pretty good job handling mixed language files.

I'd also point to Ensime as an example of a language plugin that uses an external parser to check code.

The author of this article seems to be confusing "changing the world" with helping people. UNICEF and similar organizations are great at helping people, but they really aren't meant to change the world. They just make the existing one a little less terrible for those who are worst off. I can't imagine a compelling argument saying that digging wells or tree planting has changed the world more that Facebook or Google over the last 15 years. Whether those changes have been for the best is open to discussion, but the fact that many startups have in fact changed the world in significant ways is hard to dispute.

Actually, I'd say that whiteboard interviews are for Google are an arbitrary way of selecting from already qualified candidates, just as 40 times might aid a team in choosing between 2 otherwise similar players.

The players invited to the combine are the ones teams are considering drafting anyway; all the 40 times do is move players up or down the list by generally small amounts. The point isn't that 40 times are useless, it's that they provide very little additional information about a player. Champ Bailey was going to be a high draft pick no matter what he did at the combine, and everyone already knew that Trindon Holliday was fast but probably too small to succeed in the NFL.

Likewise, someone with a 3.9 from MIT or a bunch of good open source work who's coming for an in-person interview is already qualified, and the whiteboard doesn't tell you anything new. I'd guess Google sticks with them for the same reasons teams tout 40 times - it's good marketing both internally (making decisions seem less arbitrary) and externally (look how tough our interviews are is a more socially acceptable way of saying look how smart we are), and it allows people to deflect blame if a hire doesn't work out. Judging by the number of posts about Google interviews I see here and elsewhere, the marketing is certainly successful.

Except that the 40 really isn't a very good measure - if it were, the Oakland Raiders would be winning the Superbowl every year instead of missing the playoffs. Of the 15 fastest players in the last 12 years (http://en.wikipedia.org/wiki/40-yard_dash), only 2 are stars, and most are bench guys or out of the league. The 40 has its uses, but it needs to be taken as one fairly small factor in evaluating a player, and even then it's only really relevant for certain positions.

Similarly, coding algorithms on whiteboards doesn't tell you much other than how good the candidate is at coding algorithms on whiteboards. Given that the vast majority of their revenue comes from either search (which was built over a decade ago) or companies they've acquired, and the numerous well-hyped failures (Buzz, Wave, +, etc.), I don't think it's actually working all that well for Google either.

It would be cool if there were some way to exclude cities within a certain radius. It seems that most searches (inbound and out) are for nearby cities, and the fact that a lot of people move between Boston and Cambridge isn't particularly informative.