Buffer (http://bufferapp.com) - REMOTE (We're a small distributed team of 16 people (5 engineers) across the US, UK, Hong Kong, Taiwan, Sweden and Australia)
We'd love for you to come join Buffer for the fun ride. We have over 1.1 million users and our annual run rate is over $2m. There are some super interesting challenges ahead, as we focus on Buffer for Business.
We're looking to expand our engineering team with the following open positions.
Here are some key stats about our technology and scale.
- we have over 150k monthly active users.
- 8000+ API clients. Most popular: Feedly, IFTTT, Pocket, Instapaper
- we release changes several times a day - we have an entirely data-driven process,
with Einstein and Buffer-Metrics, our custom built a/b testing and
metrics tracking framework.
- Some of the tech we work with: PHP, Python, MongoDB, AWS (Elastic
Beanstalk, Elasticache, SQS), Backbone.js, Grunt.js, Android, iOS.
- More stats and stack details here:
http://overflow.bufferapp.com/2013/08/01/scaling-buffer-in-2013/
We're a small team of driven hackers and happiness heroes (our support people). Just like you, we're excited and passionate about engineering challenges and have some interesting architecture and scaling problems we work on.
If you're interested in coming on board, you’ll:
- work closely with Sunil on technical architecture and Joel on product.
- ship to thousands of users and iterate quickly
- work with our metrics team to make smart changes
- be friendly and comfortable talking directly to customers on issues and features
- be a happy, positive-minded and kind person who has a great approach in dealing
with others
- be a Buffer user
- be anywhere in the world, and if you'd like, you have help and support from us
to move to where you want to be
- have experience working with another startup or building side projects
before (would be awesome, it’s cool if not)
Some aspects of Buffer culture that makes us a little different:
- we are totally transparent. We raised $450k, we currently have over 1.1
million users and generate $195k/mo. Ask me anything else!
- within the company, all salaries and equity are open and we have a formula
for the distribution.
- we're all very focused on self improvement
- we have daily standups where we discuss our current improvements. This could
be waking up earlier, starting public speaking, blogging, exercise, learning
a language, etc.
- here's our culture deck: http://www.slideshare.net/bufferapp/buffer-culture-03
If this sounds fun, let's chat. Send me a note about yourself, why you’re interested in Buffer, and any relevant links (Github profile, projects and background): http://jobs.bufferapp.com
I greatly apologize for the mess. Thanks for posting this! We're looking into this right now.
- All FB posts via Buffer are temporarily deleted. They will reappear again once we've enabled the FB app again (which we'll do once we're sure we're not compromised anymore).
- All Tweets are also stopped from sending.
We'll keep you updated from the @Buffer twitter and FB account.
I know that PBKDF1 is deprecated, but using SHA1 is an upgrade to PBKDF1 which was once the standard. I'm not sure if "extremely unsafe" is the right level of worry. You can still do iterations to make the hashing slower, if for some reason you don't do the right thing and use the methods you listed.
Is there a good way to 2 way encrypt something in something like rails where the app needs to use the decrypted token. If you have app logic doing decryption then someone can just look at the source to figure out how to do this. Is the only good solution to use a compiled language?
Compiled programs are as easy to read the source for (at least the relevant bits) as interpreted ones. Still, if you encrypt it and someone gains access only to the database, they wouldn't be able to use the tokens.
Hashes like SHA1 and MD5 are fast. This makes them great for things like verifying file contents... You can hash a lot of data and get your answer very quickly.
This is exactly why they are not particularly well suited to passwords. A brute-force attack (since you're salting your passwords I'm sure!) against them isn't a huge undertaking. Just with the equipment in the computer I'm on right now, I'm looking at generating about 11.5b MD5 hashes per second, or 3.1b SHA1 hashes per second.
At eight characters a-zA-Z0-9, I'm looking at about 5 and a half minutes to brute force every combination with MD5. Under a day for SHA1.
Hashes like bcrypt and scrypt, on the other hand, are designed to be slow. Their complexity factors actually provide means to slow the hashes down even further as hardware becomes faster. Instead of 11.5b/second, you can increase the complexity until you're only able to generate one hash per second... Now it takes you over three and a half centuries to hash what might take one second with MD5.
Even ignoring the possibilities of MD5/SHA1 being 'broken', they're simply too fast to be considered for hashing passwords.
But it appears that almost all user passwords (99.8%) appear in the top 10,000 list [1]. So even a brute-force attack on a slow hash like bcrypt is pretty cheap in the vast majority of cases. So switching from md5 to bcrypt doesn't improve your security much.
According to that one guy with that one list. I acknowledge that the top N passwords are X% of all user passwords. I sincerely question the 99.8% figure. The problem with doing studies like this is while we have some fairly big password dumps we still do not have the universe. Furthermore, there are some number of un-cracked passwords in the dumps we have. Further complicating the situation are password policies which may reject common passwords. It has been many years since we learned that "password" is the most common password and is commonly disallowed.
Therefore 1) it is not useless to not increase your storage security even if Y% of your users use bad passwords as you are protecting 100%-Y% of you users. 2) Y% is probably not 99.8% for you, and if you are worried about it you can take steps to mitigate the problem.
ps. He is ignoring punctuation which is an important detail for actually doing the cracking.
pps. I appreciate the sentiment (users choose shitty passwords) but not the conclusion (so don't bother storing them well). The proper conclusion is use scrypt/bcrypt and increase the work factor. You can take reasonable steps to protect your users and you should.
Yes the figure of 99.8% does seem a little high. After a bit more research it seems Mr Burnett himself can see 'a few flaws' with that figure [1].
Just to clarify: my original point wasn't that you should continue using md5. Rather, it was that bcrypt doesn't improve your security much. Given the problems with the 99.8% figure, it would be better to say, "the extra security that bcrypt provides might be less than you expect".
Great point and actually, I totally agree. The funny thing is that founders aren't the highest paid people at Buffer - and it's actually just like you say with engineering being on the higher side.
I can't speak highly enough of IDoneThis - we've been using it for months at Buffer and it's absolutely changed the way we work. The reasons IDoneThis is invaluable to us, is that it allows us to track back performance (which easily gets lost in a chat room or an in-person standup). On top of this, if new people come on board, they can look through the previous IDoneThis notes and see what has been worked on. Oh and of course, not to mention that it's amazing to keep in sync with everyone if you are working as a remote team like we do. IDoneThis has changed our productivity for the better.
My best advice is not to drop your work for as long as you can
until you see traction. In our case, Joel only stopped working after
we hit ~$1k in monthly revenues.
(read: http://joel.is/post/6687368692/startup-bootstrapping) and I
only dropped out of College a lot later after Buffer actually had
already received funding and was supporting a team of 5.
I think the key might be to only drop your work once your
revenues are enough to support you. So I would try and make that
window almost 0, in our case working nights and weekends is a
great way to get there.
Thanks, that's very helpful! Much of my problem is that I'm coming into this as a full-fledged grownup - twenty years in the industry, two college-aged kids, mortgage, car payments, etc. What cushion I have is my retirement money, and my spouse will only let me burn just so much of that before she loses patience. I could maybe get a few months of pure bootstrapping in, but the drop from a six figure income to less than minimum wage is very steep indeed.
Right now, it's 20+ hours a week on the startup in my "copious spare time". What worries me is the pain waiting for me when the rubber meets the road... the support time and emergency fixes needed when I have real, paying customers. That's when the conflict between dayjob and startup will truly loom large.
But what the hell, I WILL make it work. I'm done with working for other people. I've already signed my Declaration of Independence, but if I want my freedom, I'm going to need to survive my Valley Forge as well.
I too was doing my startup part time for about 6 months before we were admitted into an accelerator. I am currently working FT on my startup. But my personal situation is completely different than yours (no kids, no debt, no house, low cost of living state, cars all paid, spouse working ..) . Take baby steps every day and you will be surprized how much you can accomplish in few months. Be consistent about it and you should be good.
On the plus side, my wife has a high-paying IT job as well, so we won't starve immediately. And I'm kind of boggled at how much I've managed to build, effectively solo (legal help only), in the past six months. But I have another six before it's really money-ready, I think.
That's a good one. And it seems you've made the common mistake to email news@. My general advice is: Never, ever email news@. A news site doesn't cover you, a writer does. So go after writers, not publications.
We'd love for you to come join Buffer for the fun ride. We have over 1.1 million users and our annual run rate is over $2m. There are some super interesting challenges ahead, as we focus on Buffer for Business. We're looking to expand our engineering team with the following open positions.
Here are some key stats about our technology and scale. We're a small team of driven hackers and happiness heroes (our support people). Just like you, we're excited and passionate about engineering challenges and have some interesting architecture and scaling problems we work on.If you're interested in coming on board, you’ll:
Some aspects of Buffer culture that makes us a little different: Salary: 88k-110k depending on location (living costs) and experience. (http://99u.com/articles/15527/the-age-of-salary-transparency)Equity: 0.5-1%
If this sounds fun, let's chat. Send me a note about yourself, why you’re interested in Buffer, and any relevant links (Github profile, projects and background): http://jobs.bufferapp.com
- Email our CTO Sunil thenexthacker@bufferapp.com