mpetrovich
I suspect that users care more about a service that works reliably. An extra 50-100k every 5 minutes (assuming the user keeps their mobile browser open during this time) does not seem like it would be problematic.
Ironically, the alternatives he proposes make the service LESS reliable, since many users may be behind firewalls that block WebSockets, HTTP streaming, etc.
HTTP polling works for a larger percentage of users and can be scaled horizontally more easily than these other methods during high-volume spikes like the World Cup.
In short, I think Google made the right tradeoff between dumb, boring, accessible vs. clever, complex. Especially for a product that probably doesn’t meet the threshold for investing in a more sophisticated architecture.
--- About Next Big Sound
Next Big Sound (https://www.nextbigsound.com) is the leading provider of online music analytics and insights, tracking hundreds of thousands of artists around the world. We use our expertise in prediction research and cross-network performance measurement to deliver analytics and insights to music makers as well as Pandora's listeners and advertising partners.
Next Big Sound operates like a startup within Pandora: autonomous and self-directed with the freedom to explore novel directions and to experiment with the way we work. We're a geographically distributed and interdisciplinary team of data scientists, designers, engineers, client services, and product leads who are passionate about solving challenging problems with data at a massive scale.
--- About the role
We're looking for a senior data engineer to work directly with our science and product teams to ingest and integrate large volumes of disparate music and social data from a variety of sources. This involves rapid innovation in large-scale data pipeline design and development to ensure critical datasets are audited, normalized, and made available to our users and predictive models in a timely manner.
This role might be for you if:
- You have experience with and enjoy designing, building, and owning data architectures and ETL pipelines end-to-end
- You can work effectively on small, interdisciplinary teams with other data scientists, data engineers, web engineers, designers, and product managers
- You're hungry to learn new technologies and teach us a thing or two about building world-class data platforms
- You're excited by the challenge of extracting value and insights from large, disparate music and social data sets at scale
Our team is based in New York City but working remotely is an option. In fact, one third of our team is remote.
Apply here: https://pandora.com/careers/position?id=oJaQ6fwz
I hope others build on this in the future and add the worms gameplay mechanics. One of my favorite games when I was younger.
My team is hiring! Next Big Sound is like a startup within Pandora--autonomous, interdisciplinary, small, and nimble--with a big impact in the music industry. We're remote and travel-friendly, too.
If you're interested in novel data and web engineering challenges at scale, reach out to me or apply using the links below.
Senior Web Engineer: https://pandora.com/careers/position?id=op106fwg
Senior Data Engineer: https://pandora.com/careers/position?id=oJaQ6fwz
With a tailored take-home, the company has a chance to evaluate candidates based on more realistic, holistic challenges than “solve this academic comp sci problem that you won’t actually encounter on the job”. And candidates can get a better sense of the type of work and challenges they’d actually be tackling on the job.
The take-home isn’t tailored to each candidate. The opposite, actually: it needs to be the same for all so that candidates’ solutons can be compared.
Here’s the tl;dr example of a challenge we give web engineering candidates:
“Here’s our API and API docs: <link>. Create an interactive data visualization using D3 and any other tools you’d like. Your submission should include instructions on how to run it.”
By keeping the challenge relatively unconstrained, we allow candidates to show some creativity and prompt them to make the same feature/quality/speed tradeoffs that they’d have to make in the role. We look for autonomous individuals, so this turns out to be a good filter. We encourage them to spend less than 4 hours on it, but our time limit is a pretty generous 1 week since they likely already have a full time job and other interviews.
The nice part of this workflow is that the changes are all squashed into a single commit in the trunk, but there’s always a link to the pull request where you can see the individual commits pre-squash.
A linear history is helpful when debugging since it makes git bisect a lot easier. Having individual PR commits in the history makes git bisect useless since it’s unfortunately common for individual PR commits to leave the system in a broken state.
Also, the foot traffic is really light. Most people seem to hang out at the few cafés or restaurants. But I suppose with prices like that, they need a lot less traffic to pay rent.
TL;DR. Too much personal fluff and no meat. Nobody cares about your hobbies unless they're directly relevant to the position.
Overly general. You haven't differentiated yourself enough from others applying to the same position.
These kind of cover letters/emails should be highly specific to the company you're applying to. It should answer the HR manager's primary question: Is this applicant the best person to help the company achieve its goals?
Find out from the job description what you're being hired to do, and provide examples of things you've done in the past that are similar. Help the manager imagine how you could apply your experience and talent to that position. And do it quickly, since they're reviewing hundreds of these a day and will spend less than 30 seconds on yours.
Customizing your cover letters in this way is definitely more effort and more time consuming, which means that 99% of applicants won't do it. Be the 1% that stands out.
Finally, the HR filter sucks. Find the actual team managers/members and reach out to them instead. Referrals, even if cold, are better than nothing.
The 48 hour time limit is a relatively arbitrary timebox and isn't a hard limit; we value quality over speed.
After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete.
In submissions we look at everything from overall program structure and approach to applicants' attention to detail and usage of good industry practices.
This coding challenge quickly weeds out applicants that interview well but code poorly and is an efficient way for us to see the quality of work we can expect from them (and conversely, the type of work they can expect to do with us).
After a successful challenge, we bring applicants in to meet the team. At this point, it's largely just about culture fit.
The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with a sparse fieldset query parameter [1]:
/users/123?fields=name,email,work.name,work.address
user({ "id": 123 }) {
name,
email,
work {
name,
address
}
}
https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...
Phil Schiller:
So, the two sort of priorties we set on the team as they were working on it was, if we're going to do this, we have to do it in a way that, number one, protects user privacy. There are many ways that companies do it where they're not protecting privacy and we need to understand that. And secondly, how do you do it in a way that gives advantages to small and indie developers, because it's easy to imagine a system that didn't do that.
And so, we set out to think of all the things we could do to make that possible. And there's a long list of things. And I won't go through all of them to bore you all, but there are many things.
Things like:
- First of all, there's no minimum bid. So we don't set a bar, if you have a very small amount of money, you can just do what you can with a small amount of money.
- The fact that we're going to work really hard to try to make relevance the top priority, over bid, for why something gets shown. That the users are the ultimate deciders of what gets shown, based on their clicks, they're a big input to what is relevant to the search result.
- The fact that we're going to work hard to try to police and improve the whole metadata system if we find, as it easily could be abused to hurt [small] developers.
- The fact that — and this has been a hotly-debated thing — the fact that you can do conquesting. You can use someone else's brand in your ad words that you want to use. As we thought about it, that is more likely to benefit the small developer than the big developer. Because the big developer isn't going to pick on a lot of small developer terms, but a small developer can try to latch on to a big developer's name. If I want to search for Angry Birds and your game, you can. Right? And so we think that that can help them.
- The fact that there's no exclusivity. So a large developer cannot say, "And I want to be the top bid, and I'm going to spend everything I can to buy out this term." There will be no exclusivity, there's going to be a rotation there, and as that rotation appears, the relevance will help drive it further.
We're trying everything we can, and I think one of the best things is, right now, once we're in beta throughout the summer, the downloads the users get from the ads are real downloads to benefit the developer, but we're not charging [for ads] during the beta time. So there's a chance for everybody to get in and try it out, help us learn from it, and drive real downloads and real business without any marketing spend.
So we're trying to think of things we can do, and we'll think of more. We'll take feedback and see what's happening, and where it works and doesn't work, and where it feels like they're getting stomped on, and we'll try to do all that we can to make it better.