Hacker News new | comments | show | ask | jobs | submit | pixelmonkey's comments login

Parse.ly - http://parse.ly - Fully Remote - Full-Time

We are hiring a software engineer to work on our real-time analytics dashboard. Pythonistas and JavaScript hackers especially desired.

On the company: We've built a real-time content measurement layer for the entire web.

Our analytics platform helps digital storytellers at some of the web's best sites, such as Arstechnica, New Yorker, Mashable, The Next Web, and many more. In total, our analytics backend system needs to handle over 50 billion monthly events from over 475 million monthly unique visitors.

Our entire stack is in Python and JavaScript, and our team has innovated in areas related to real-time analytics, building some of the best open source tools for working with modern stream processing technologies. Our UX/design team has also built one of the best-looking dashboards on the planet, using AngularJS and d3.js. You can see some screenshots: http://parse.ly/tour

Our distributed team is best-in-class and we happily skip commutes by working out of our ergonomic home offices. Here's a photograph of mine running two full-screen Parse.ly dashboards on my monitors: https://flic.kr/p/v1NZ73

We are currently looking for software engineers to help us build the best real-time analytics dashboard the world has ever seen. The only requirement is some experience in Python/JavaScript. Bonus points for an interest in information visualization, Edward Tufte, and d3.js. To see an example of how we work, check out the blog post, "Whatever It Takes": http://blog.parsely.com/post/46

Apply now by sending a CV/website, github link (if available), and 1 paragraph intro to work@parsely.com. Let us know what part of the position interests you, or point us toward an interesting project or piece of code you wrote. Also, mention the HN Who's Hiring thread.

p.s. we are also looking for folks interested in intersection of product and marketing, such as hybrid product designer/developers.

Are you considering candidates outside of US. ?

I run a 20-person fully distributed product / engineering team at Parse.ly, and this post is a great summary of why we do it. It's not about hating on offices, it's about loving on quality of life.

Work-life balance and harmony is enabled by remote work. I don't have kids, but many of my colleagues do, and they really appreciate the flexibility.

I don't think all roles can work perfectly remotely, but software engineering certainly can. Github (any day but today :)), Trello, Flowdock/Slack/IRC, AWS, GHangout, GDocs -- these are the tools you would use anyway in a good company. And you can trade the money spent on offices for plane tickets to do team retreats and hackathons from time to time.

Wow. I still use VMWare Workstation all the time. I guess it's time to switch to VirtualBox and Windows 10 for my occasional MS Office needs.

If this isn't a sign of the decline of enterprise desktop software, nothing is!

I agree. I opened PR #19 to address this:


Would love to hear what you think of the changes.


Thanks -- we are actually discussing this possible change in a Pull Request here: https://github.com/amontalenti/elements-of-python-style/pull...


It's a fair point, but the style guide is meant to be illustrative.

The former example is indented the way longer lines might very well be e.g. if your filter clause were a 2-part bool, you might not be able to fit it in a one-liner. The indentation also clarifies the difference between it and the imperative example above it.

The latter example is a rewrite of code written with 2 nested if statements, so the indentation serves to show that now the two nested statements were incorporated into the bool evaluation. If I made it a one-liner, someone might make the argument that the nested version is "more readable", but as written all you can say is that the single-if version is "less nested", which is the point I was trying to get across.


I'm "this guy" who "got a bunch of things wrong" :)

Style guides are opinionated, and not everyone will agree. I intentionally made the style guide part of a Github repository so I could consider feedback from the community, and I've already incoporated plenty. As I mention below in the thread, I think you have a good point about "args" vs "cards" for your shuffle example.

Re: "The preferred place to break around a binary operator is after the operator, not before it", I think you mis-read this PEP8 suggestion. A binary operator is something like "and" or "+", not the "for" keyword inside a listcomp.

Re: your other disagreements, they amount to style choices of their own. When a style guide picks between two ways of doing things, there will inevitably be detractors, and I am OK with that.


If you don't use "if item" properly, it's bad code, not just style choice.


I'd gladly accept a PR on the issue raised re: "args" vs "cards" for the shuffle function. When I wrote the guideline on using the names "args" and "kwargs", I was thinking more about cases where you have to proxy both, e.g.

    class SomeClass(SomeOtherClass):
        def __init__(self, *args, **kwargs):
            # some logic
            super(SomeClass, self).__init__(*args, **kwargs)


that's totally acceptable in this case.


Ubuntu before Ubuntu! And my first "workaday" Linux desktop distro. Same here, that was how I came to know Ian Murdock indirectly.


I was once asked to help a friend debug his server. Its mysql state was not loading properly, so I wrote an rsync line to back up all the mysql data as a safety step before debugging. A few seconds later, I realized I put a forward slash and a space in the wrong place and had managed to delete the entire directory.

I felt like such an idiot. At least I haven't messed up an rsync command since!



Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact