The Evolution of Eventbrite's Front-End Stack

8,216
X44pfwmn
Eventbrite
The world's largest event technology platform, powering over 2 million events around the world each year

By Marcos Iglesias, Senior Software Engineer at Eventbrite, and Ryan Wholey, Software Engineer at Eventbrite.



Eventbrite Charts


Background & Stats:

  • Eventbrite has processed more than $8B in Gross Ticket Sales (since inception), and over $3B in 2016 alone
  • They process between 2-3 million tickets each week on Eventbrite
  • They processed about 150 million tickets in 180 countries in 2016
  • Millions of events use Eventbrite as their ticketing solution each year; in 2017 alone, they supported nearly 3 million events in 180 countries
  • Britecharts was released back in April and is now one of the most popular D3.js-based libraries on GitHub

Check out their tech stack and open jobs on their profile


Yonas: All right, cool. Maybe we could just start off with quick background on both you guys. Where you're from? How'd you get here? And what you do at Eventbrite?

Ryan: Yeah. My name is Ryan, I grew up very local here. I started working at Eventbrite maybe a year and a half ago. Before that I was at a small tech company in northern San Francisco, that has gone under since I started there. I was doing mostly charting-related data visualizations for them, using D3. I think that's why I got hired here actually. To help my man on the left here, work on their charting library and the reporting parts of Eventbrite.

Marcos: Yeah. In my case, I'm Marcos Iglesias. I work here at Eventbrite, where I have been working almost three years already. I'm Spanish, I've been in the Bay Area on the barrier for five years. No, more than five years already.

I work with Ryan creating user interfaces and data visualizations for our event organizers. So when you create an event a Eventbrite and you sell some tickets, then you can come back to the organizer side of the website and check how are you doing? Where your attendees are coming from? How's your sales going? What kind of tickets did you sell? All that kind of stuff.

Y: Awesome. How is engineering organized? Is it front end, back end or is it product specific?

M: That's a great question.

It kind of evolves a little bit depending on the business objectives. But mainly we have a couple of back end and front end platform teams, or foundry teams, as we call them. [inaudible 00:02:40] in charge of creating the tools that we need in order to keep on working, like our development environments or our front and back end stacks.

We also have different feature teams, like us for example, that cover and hone a specific, sometimes really specific, sometimes really broad, part of our product. We will be small teams, one of those ‘Pizza teams’, it's called? Yeah. So we're maybe at the most eight people. We have a QA, a UX, a designer, a product manager, and then maybe four, five or six engineers. Maybe have half front end, back end. Usually a little bit more back end.

Y: Yeah. Okay.

M: More is like this.

Y: Okay.

M: I'm sure I'm missing something.

Y: Okay. Awesome. I'm sure you guys use a lot of different things, but what's the primary back end stack?

R: Back-end stack is Django. We've had some core contributors of Django lucky enough to work here at Eventbrite. We acquired a company called Lanyrd back in 2013.

Y: I know, I remember that.

R: Yeah. A few of those guys have made some huge contributions to Django when it was first starting out. So it was an easy choice for us here at Eventbrite to move in that direction because there's a vast knowledge of expertise on that side of the stack. Not only that, it's a pretty easy language to pick up for people just to come in and start working. So yeah, we have a little bit of legacy code hidden away, in some of those dark corners of our code base. But those are wrapped in Django interfaces and most of our stuff now is in Django.

Y: Gotcha. And database is MySQL?

R: MySQL. Mostly. We have a few other things floating around. We use a few Redis clusters, Elasticsearch for some of the aggregational queries that we're running. We're running Cassandra I think too. But mostly it's MySQL.

M: And Redis for some stuff as well.

R: Right, yeah.

Y: Okay, awesome. So you guys handle specifically the organizer side of the platform?

M: Yeah.

Y: Okay.

M: All of the reporting related stuff.

Y: So maybe you could just describe what that entails. You can create an event, you can offer tickets. Do you all do payments as well? Or is that a separate team-

M: No, that is a separate part of the system. Almost all of our work is based on something called the report service. That is grabbing all the order information and getting insights from it. It's the same service that our organizer app will use for example, our mobile app will use the same API's that we do on the web.

Y: Okay. So as an organizer I come in, I've already created an event but I want to see stats on how many people have registered, how many people have probably checked in-

M: Yeah. Also how many people visit your event page as well.


Eventbrite Charts


Y: Okay cool. How did Britecharts even come about?

M: The idea of Britecharts came from ... it was May, 2015 and we had a piece of D3 code in production. Someone created a line chart and started adding features and adding features and adding features to it.

And eventually it just became a huge file. It was a render function in a Backbone view that was more or less 500 lines of D3 code, all just in a row. So we get to a moment that we were actually unable to work with that. So we had to change our point of view and our approach to working with D3 code.

Our solution was to create a different repository, extract all that code out of our core repository and create a product that would be something that we at first, and later everybody at the company could work with. We always had a hope of open sourcing it in the future.

We created that piece of code and we committed to do it in a test driven development way. And keep it really, really clean, with a lot of options. Yeah, more of less, that's the beginning.

Y: Yeah. You mentioned Backbone. Are you guys using Backbone?

M: Yeah. Well, right now we are in the middle of a change of the stack in the front end. So we used Backbone with Marionette. Then we also created our own implementation of a Flux kind of flow. We call it eb-flux. We have worked with Marionette for a long time. Then at some point we start evolving and end up having a kind of Redux-style architecture, but with Marionette.

But then maybe one and a half years ago, we started moving into React and that's why we created the Eventbrite design system. It's a really nice project that probably could be open sourced. It's a library of components for our React components.

With the help of that library, we are building our new stack with React and sometimes Redux when it's necessary.

Y: Got you. So the evolution was Backbone, Marionette, and D3. Pure D3 with a bunch of, well 500 lines of extra magic. Then you're now moving to React, Redux, and Britecharts.

M: Well-

Y: Well, D3 as well, but Britecharts.

M: Yeah. More or less. The thing is that Britecharts was created from the point of view of just using it as a JavaScript-agnostic library. That worked really well with our Backbone builds. We just use a render and initialize all the stuff there.

Now moving into React, we have the necessity of actually moving Britecharts into React land. That's something we're gonna start working on in the next two weeks. That is a wrapper of our Britecharts in order to be used with React. And we are really excited about that.

Y: Oh, awesome. So Britecharts' React component. Very cool. What was the driver? I'm guessing you all were involved with that decision, but what was the driver for moving from Marionette and Backbone to React?

R: We found that there was some limitations with the speed of rendering and the ability of our components to branch out across component with Marionette, just the way that it was.

If you've worked with Marionette and Backbone you're familiar with the idea that everything is sending events to some other place across the code base and it immediately as soon as it gets past a certain point, gets unwieldy to work with in large scale applications.

So the hope was to move to something like React, which has a much smaller API than something like Marionette. Which is exciting for developers to work with. Like I said small API with the idea that when these complicated applications that need to be built, when that happens where you can use something like Redux. Which will hopefully simplify the front end, back end portion of it. The data driven portion of the view layer. That was the goal there really. Is to be able to move quicker down the road.


Eventbrite Charts


Y: Got you. What was the first section of the app? Or portion, feature/product that started to use React? Was it the charts?

R: No. I think-

M: Was it the login?

R: Maybe it was the login.

Yeah, I think the first production-wide page that went live very recently, a couple months ago, was our login page. So nothing too crazy on the front end. I think that was the first 100% live production page.

We do have another create event flow that's been in development for maybe the last year or so that is still ... I think it's rolled out to maybe 10% of our organizers that have opted into it. We're testing it out, making sure all the kinks are out of our new system.

We really want to make sure that our SEO doesn't drop at all with React. So we're rending on the server side, which introduces another layer of complexity that we didn't have before with Marionette. We're just making sure all of our ducks are in a row before we pull that ripcord for React.

Y: Yeah. What are you guys using for server-side rendering? I'm sure there's a bunch of prebuilt stuff.

M: I'm not super, super familiar with it, but we know. Our back end is Python so we couldn't run Node just by itself. So what some of our peers figured out was that let's create a service that runs Node and that can do the renders for ourselves.

So our Python back end, we say, "Okay, I gonna send you this context object with data and I will send you this application. And you will give me back a string of render markup that we will use to render on the server."

R: Actually I think it's just HTML.

M: It's HTML right.

Y: Oh, okay. Gotcha.

M: So we use it as a service that actually renders out someplace.

R: I think I've seen it diagrammed as a sidecar like architecture. Where we have just a, like you said, a service that we just request HTML from and we set it directly on the client's page.

Y: Got you. Okay. Makes sense. Cool. So coming back to Britecharts, what was the problem that it solved for you guys? What did you guys end up building on top of D3 specifically?

M: The good thing that Britecharts offers is that we move into this world of components as well. Like on React. Before we had really one-off things, so we will have this chart that works here and that's it. There's no API for that element, it's just a one off thing.

Right now we can take the same chart and we use the same chart in different places in our website. Also we have different small auxiliary charts. We can say like legend. We have different type of tool tips. We can stack those in and out depending of our necessities in each different case. So that was a big win.

Also having all that tested and in a continuous integration and platform. That gives you a lot of confidence over the code as you're using that.

Y: Okay. So it sounds like the main benefit is that it helps you sort of componentize your different visualizations?

M: Yeah.

R: And test it.

M: Testing on this is really not a trivial thing. It's kind of tweaky and it changes the way that you approach the whole thing.

Y: Got you. Okay. Are you now using Britecharts across all of your charting? Or are you still migrating some of that over?

M: Yeah. Well, we have some sections of charts that are really, really old and that we are trying to deprecate. So we can say that if we build something new, we only use Britecharts.

But still you will find some chart, some really old charts, some here and there. I don't know. You would actually need to dive deep into the code for those. We're really trying to hard to get rid of those.

R: Yeah.

Y: Okay. But for the most part, what a user can see now is pretty much powered by Britecharts?

M: I would say so, yup.

R: Absolutely, yeah.

Y: Okay. Ryan, I guess from your perspective, was Britecharts kind of like an obvious thing to you? As like, "Oh, this makes a lot of sense." Or was it just something brand new that you were like, "Oh, never thought of this before."

R: I think that the benefits for it, there was many. I guess totally was an easy choice 'cause if we open source that we have people contributing and giving their input into this code base. So we have a wider developer base for it. We have the testing.

Since we are the owners of it basically we can release it whenever we want. Someone when we first released Britecharts asked us, "Why didn't we contribute to something like Highcharts?"

Y: Oh.

R: Some other charting library instead. For us, it's easy. We need control over not only the release process, but the look and the feel of the charts. Our designers are very specific and they're very talented. Something like Highcharts where we're trying to delve into the API of some other charting library to add our styles in, it's just not gonna work out well for us.

So compatibility with our work style here. The testing was a huge thing for us. The modularity of the charts. It seemed like an easy solution for us.

Y: Yeah. I'm sure someone probably brought up the idea of forking too, right? Why not fork D3 itself or Highcharts?

R: Yeah. At the time when this was conceived, there wasn't a great library that was tested.

Y: Gotcha.

R: I think that there was some good research done and we couldn't really find one that was a satisfactory, fully test-driven environment. So that was big for us. It was either add testing to another library or just create our own.

M: Also we were limited in the sense that we had something that was working in production at that time.

Y: Oh, you mean the code, essentially everything you had added on top of D3 was already in production?

M: Yeah. Just one chart. The line chart was something that was already in production. So we had to move into something different, but we need to keep that thing there. So we actually we factored that thing until it just met our standards. And that was the first chart of Britecharts.

Shout out to all our contributors on Britecharts, it has been an amazing trip in that sense because yeah, they have helped us so much. I guess we didn't expect that much help from outside people. People find bugs and fix them themselves.

There have been people creating new charts from scratch and doing a great job on that. So yeah, we want to make the most of this to say thanks to all those contributors.


Eventbrite Charts


Y: Yeah. No, it's awesome. Looks like you have over 20 contributors. Can't see how many times it's been forked, but it looks like it's been really popular. Sounds like something the D3 community really needed.

As far as v2, anything you want to mention that's new with v2? 'Cause I know you guys just released that.

M: Yeah. With v2, what happened was that we noticed that we had ... even if we had a good amount of charts, we still are far from having all the charts that are needed at this point. So we knew that we had to grow.

From feedback from our contributors, they're saying that sometimes we didn't choose the right names for the API. And sometimes something that was doing the same thing in one chart was called that one way and in another was called in a different way.

So the idea was to make all these more consistent. For that we created these API guidelines document where we talk a little bit about how the API will look like and will be named.

Because actually one of the main pain points is naming. Naming is really hard. So even in ourself, we struggle, what do we call this? Do we say itthis way? Or that way? Or this word first? This word last? Y: One of the big computer science problems, yeah.

M: Yeah. So, we got a screenshot of all the API's from our documentation and we say, "Okay, what is matching here? What is not matching? What makes sense? What doesn't?" And we created a document saying for example, if it's a boolean, then it needs to start with is, has, should. Or if it talks about the ticks of the charts then it needs to have ticks at the end. This kind of stuff.

We created that document. We circled it around. We agreed on that. Then we refactor it so that every chart will have this consistent API. That's mainly the version two. It also added a couple of new charts by the contributors and some bug fixes.

But yeah, we're sorry for some of our users because we are actually breaking their charts because the old accessors don't work. But I think we are now a lot more confident that we can grow more and that people can contribute to it by just reading those API guidelines, they will be good. They will do it a lot better.

Y: Awesome. All right. I guess before we wrap up, how many front end engineers are now at the company?

M: That's a great question.

Y: Ballpark?

R: 35, 40, maybe.

M: No, a little less maybe?

R: Maybe less.

M: So we can say that maybe 15 pure front ends. Then we will have another 15 that can really work with the front end. But they also work with the back end.

Y: And that's out of what? Maybe 100 engineers?

R: We have more than 180 product, engineering, and design people globally. We have offices in San Francisco, Mendoza, and Nashville, which are heavily engineered. We have other offices around the world, but those are where our engineers mostly work out of.

M: Also, we just completed our aquisition of Ticketfly from Pandora.

Y: Ah, cool!

M: So we're in the process of integrating the Ticketfly team that is also here in San Francisco.

Y: I guess I was just mentioning that to say I'm assuming you guys are hiring front end engineers-

M: Yeah, sure, we are always hiring really good people. Specifically we're hiring a senior, front end engineer who's good with data visualization so if you're interested in Britecharts, please hit us up on our site or check out our listings here on StackShare.

X44pfwmn
Eventbrite
The world's largest event technology platform, powering over 2 million events around the world each year
Information Systems Engineer
Nashville, Tennessee
THE CHALLENGE As part of the BriteTech Systems team, you will contribute to supporting and building our global IT infrastructure. In this position you will administer and maintain on-premise and cloud backend IT systems, help manage thousands of endpoints across the globe, build and enhance tools for our global IT support team, and help automate and integrate everything imaginable. THE TEAM The Eventbrite IT team, or BriteTech as we are fondly referred to as internally, is responsible for overseeing all internal technical operations. From network services, security and collaboration services, to espresso machines over IP, BriteTech’s goals are to simply reduce technical friction in an effort to nurture an environment where technology empowers and supports the creativity of our Britelings! There are a number of services, software, and hardware solutions required to create a productive and collaborative environment for our Britelings and partners. Creating and supporting this environment takes a team of motivated individuals. We build the internal technology environment around the pillars of simplicity, efficiency, security and scalability. The team supports a global staff who are creating a global service. We are a diverse, global, forward thinking team and are looking for that special someone to join us! THE ROLE As a member of the BriteTech Systems Team, you’ll be a critical cog in keeping our backend IT systems and infrastructure not just up and running, but also thriving and propelling toward a more scalable and efficient future. In this role, you’ll have your hands in a lot of different areas, including but not limited to scaling Mac/Windows/Mobile platform management, administering and improving management of a large catalog of SaaS services, internal tools and automations, networking, identity management, strengthening our overall security posture, and eating donuts. You’ll also serve as an escalation point for our Helpdesk team to mitigate technical issues and collaborate with onsite business partners, external vendors, and the extended IT team. This role will also have the opportunity to drive multiple projects (sometimes simultaneously) from start to finish, making a profound impact on the productivity and efficiency of our global workforce. THE TECH STACK Internal System administration (Google G Suite, Okta, Salesforce, JIRA/Confluence, etc…), Mac and Windows Platform/Endpoint Management (Jamf Pro, AirWatch), Telephony (VOIP, WebRTC), Monitoring/alerting, Scripting (Python, bash, PowerShell), Security, Wireless (support and configuration), Network configuration and troubleshooting, Active Directory/LDAP, VMWare.
  • 4+ years of experience as an IT Systems Administrator/Engineer in a rapidly growing company or experience as a professional rodeo clown, whichever is less dangerous and unpredictable
  • 2+ years experience deploying, configuring, securing, and supporting Mac and Windows endpoints using a Mobile Device Management system (Jamf, Airwatch, or similar)
  • Strong experience administering a wide array of on premise and cloud-based services
  • Experience (and a passion for) scripting things (using bash, Python, PowerShell, or similar)
  • Experience managing hundreds of users in a complex, interconnected SaaS environment
  • Experience driving complex IT projects involving multiple stakeholders from start to finish
  • Excellent understanding and experience with identity management (Okta, Active Directory, LDAP), along with associated onboarding/offboarding workflows and user lifecycle management
  • Experience with vendor management and vetting products and services
  • A passion for documenting all things and communicating clearly and effectively
  • Fantastic ability to flourish as a part of a team while exhibiting flexibility and a passion for snacks
  • BONUS POINTS
  • Experience interacting with REST APIs
  • Experience automating batches of repetitive tasks with scriptsExperience with zero touch provisioning workflows
  • Comments
    Open jobs at Eventbrite
    Mobile Software Engineer - iOS
    Nashville, Tennessee
    THE TEAM At Eventbrite we tackle tough problems. We learn, grow, and have fun in the process. The women and men of Eventbrite’s Engineering team enjoy facing challenges as individuals, but we are also eager to collaborate and share our knowledge to drive the product forward. The Nashville Engineering team is charged with building our next generation organizer app, and the APIs and services that power it. We perform weekly demos of the code we ship, hone our skills through code reviews, and tell the world about it on Eventbrite’s Engineering Blog. We believe in the value of community and the power of live experiences, and regularly host free events with top technical speakers. Learn more about the team from some of our engineers here. THE CHALLENGE We are committed to building an amazing user experience that both looks and feels great, and that we’re shipping the highest quality apps possible. Our organizer apps power businesses of all sizes, from smaller conferences to massive international food, film, and music festivals. Their performance is critical; we must have a high level of confidence around every release and know that it will perform perfectly to guarantee a seamless experience for any Eventbrite powered event.   THE ROLE As a Mobile Software Engineer you will collaborate with product, design and other engineers to formulate and implement solutions to various needs and requirements. We work in an iterative fashion to always have a shippable product that can instantly add incremental value to our users. We value code quality and high confidence around our releases. THE TECH STACK We primarily use Swift to build our iOS apps paired with a mix of InterfaceBuilder and Programmatic Layouts to share eye candy to our users. We leverage and contribute back to open source projects as a standard part of our development practices. We also try to build things in a reusable and maintainable way by default.
  • Experience in software design and development
  • Experience with Objective-C, Cocoa Touch, and the iPhone/iPad SDK
  • Experience building applications that talk to RESTful web services
  • Understanding of software design patterns and architectural principles
  • Strong object-oriented programming and design skills
  • Experience writing multi-threaded, asynchronous code
  • Database experience using CoreData, SQLite or equivalent
  • Attention to quality through unit tests, automation scripts, and code reviews
  • Good communicator and team player with strong organizational skills

  • Experience with Cocoa on the desktop, AppKit, etc.
  • Experience shipping one or more native iOS apps to the App Store and/or Android apps to the Android Market
  • Experience using Python in a production environment
  • Active contributor to open source software

  • Senior Front End Engineer
    San Francisco, California
    THE CHALLENGE As a lead frontend engineer, you would build beautiful & responsive user interfaces for desktop, mobile, and tablet browsers that delight our users. You would work closely with Product Management, UX, and Design, giving input on what is both intuitive and feasible.  You’ll build new data visualization features in our open source D3.js based Britecharts component. You’ll also contribute to front end architectural improvements and create shared interactive components that span our service as we’re continuously modernizing our stack. Read more about Britecharts on our Engineering Blog. THE ROLE Across the Briteland, there are numerous frontend opportunities such as: Datahawks: This team builds scalable, performant, and beautiful Analytics toolsets for event organizers. Our analytics suite includes traffic to an organizer’s listing page, sales data, attendee geography, etc. As a frontend engineer, you will build scalable, performant, and beautiful Analytics toolsets for organizers consisting of data such as traffic to an organizer’s listing page, sales data, attendee geography, etc. On Datahawks, our mission is to create a differentiated source of value for our customers, consistently delivering them comprehensive, actionable insights that help them grow their business, and doing so in a delightful, simple way. At Event: This team is responsible for RFID and ticket scanning based access control for the largest music festivals on the Eventbrite platform. These complex events require advanced management features and data visualization to enable day-of event operations.  Our small and specialized team enables organizers with event logistic tools to provide a seamless and delightful event experience for event attendees. Our onsite solutions service events big and small, from neighborhood photography classes to top tier music festivals with hundreds of thousands of attendees. THE TEAM We're a people-focused Engineering organization. The women and men on our team value working together in small teams to solve big problems, supporting an active culture of mentorship, and challenging themselves to learn new things and take on new challenges daily. Weekly demos, tech talks, and quarterly hackathons are at the core of how we’ve built our team and product. We believe in engaging with the community, regularly hosting free events with some of the top technical speakers, and actively contributing to open source software. Learn more about the team culture from some of our engineers. Our technology spans across web, mobile, API, big data, machine learning, search, physical point of sale, and scanning systems. We even drive servers up mountains to power the most remote events. Our primary stack is Backbone/Marionette, React, Redux, Sass, Handlebars, Python/Django, Celery with MySQL on AWS, GitHub, Slack and an espresso machine.
  • 3+ years of working experience in rapid product development building rich client-side applications using a combination of HTML5, CSS3, and JavaScript/ES6+
  • Familiarity with Javascript applications using technologies like React, Redux, Marionette/Backbone
  • Experience or a strong interest in building data visualization with D3.js or equivalent
  • Deep understanding of cross-browser compatibility pitfalls and how to work around them
  • A track record of  working closely with Design teams to build beautiful & intuitive web pages and applications
  • Experience with techniques for improving SEO and accessibility
  • Excitement about working in an environment where you are expected to make a significant and visible contribution
  • The desire to work on a highly visible product that impacts millions of users
  • A strong portfolio that displays your passion for delighting users
  • Familiarity with D3.js
  • Previous experience working with a large engineering team on a complex web application
  • Familiarity with a server-side frameworks such as Django, Express, Rails or .Net
  • Experience with visual design techniques like spacing, typography and color
  • Senior Mobile Software Engineer - iOS
    San Francisco, California
    THE TEAM At Eventbrite we tackle tough problems. We learn, grow, and have fun in the process. The women and men of Eventbrite’s Engineering team enjoy facing challenges as individuals, but we are also eager to collaborate and share our knowledge to drive the product forward. The Nashville Engineering team is charged with building our next generation organizer app, and the APIs and services that power it. We perform weekly demos of the code we ship, hone our skills through code reviews, and tell the world about it on Eventbrite’s Engineering Blog. We believe in the value of community and the power of live experiences, and regularly host free events with top technical speakers. THE CHALLENGE We are committed to building an amazing user experience that both looks and feels great, and that we’re shipping the highest quality apps possible. Our organizer apps power businesses of all sizes, from smaller conferences to massive international food, film, and music festivals. Their performance is critical; we must have a high level of confidence around every release and know that it will perform perfectly to guarantee a seamless experience for any Eventbrite powered event.   THE ROLE As a Mobile Software Engineer you will collaborate with product, design and other engineers to formulate and implement solutions to various needs and requirements. We work in an iterative fashion to always have a shippable product that can instantly add incremental value to our users. We value code quality and high confidence around our releases. THE TECH STACK We primarily use Swift to build our iOS apps paired with a mix of InterfaceBuilder and Programmatic Layouts to share eye candy to our users. We leverage and contribute back to open source projects as a standard part of our development practices. We also try to build things in a reusable and maintainable way by default.
  • 5-8 years of experience in software design and development
  • Experience with Objective-C, Cocoa Touch, and the iPhone/iPad SDK
  • Experience building applications that talk to RESTful web services
  • Understanding of software design patterns and architectural principles
  • Strong object-oriented programming and design skills
  • Experience writing multi-threaded, asynchronous code
  • Database experience using CoreData, SQLite or equivalent
  • Attention to quality through unit tests, automation scripts, and code reviews
  • Good communicator and team player with strong organizational skills

  • Experience with Cocoa on the desktop, AppKit, etc.
  • Experience shipping one or more native iOS apps to the App Store and/or Android apps to the Android Market
  • Experience using Python in a production environment
  • Active contributor to open source software

  • Senior Software Engineer
    Mendoza, Argentina
    THE TEAM We opened our Mendoza office two years ago, merging with Eventioz, a local company, and we are looking to grow our amazing southeast engineering team. Hear from the Mendoza Engineering team and meet Ariel Chiat, Engineering Manager in Mendoza. Our primary stack is Python, Django, and Celery, all running on AWS with a MySQL backend. Some of the other tools that we use are Redis, RabbitMQ, Cassandra, Hbase, Hive, Backbone, Sass, Git, and an endless supply of coffee. Haven’t worked with these technologies before? This is an amazing chance to jump in and learn. One thing you should know: we're a people-focused organization. Engineers help each other, work on problems together, mentor each other, fail together, and actively develop their careers. Weekly demos, tech talks, and quarterly hackathons are at the core of how we’ve built our team and product.
  • Experience with or the excitement to work with Python and Django web framework
  • 5+ years building applications in a mainstream programming language: Python, PHP, Ruby, C#, C++, Java, etc.
  • Understanding that great code is also maintainable code. You care about making sure your code is well tested.
  • A result driven self starter with great communication and collaboration skillls
  • Unit-testing know-how required, experience with TDD or BDD is an added bonus
  • Working knowledge of front-end technologies (HTML, CSS, Ajax, Javascript
  • Solid database experience (ideally MySQL, NoSQLis a plus)
  • Medium/Advanced English Level
  • Active contributor to open source software
  • Verified by
    190833
    Sr. Software Engineer
    425965
    Big Cheez
    You may also like
    E-Commerce at Scale: Inside Shopify's Tech Stack
    How SendGrid Scaled to 40 Billion Emails Per Month
    How Stream Built a Modern RSS Reader With JavaScript
    How Heap Built an Analytics Platform that Auto-Tracks Every User Event