Devpost helps developers do fulfilling work. Get an inside look at dev teams who are hiring and participate in hackathons to improve your skills.

LOCATION
New York, NY
DEV TEAM SIZE
7
COMPANY SIZE
16
TYPICAL HOURS
10:30am–6:30pm

Jobs

Benefits & perks

πŸ“…
No vacation policy (time off when you want it)
🚌
Pre-tax transit benefits
🍎
Fully stocked fridge
πŸŽ’
Team field trips
🍴
Catered team lunch Thursdays
πŸ₯
Health plans (75% covered by us!)
🌈
Great location in Chelsea
πŸ’°
Stock options
🎫
$2K education fund for conferences, books, classes, etc.
πŸ“ˆ
401k with 4% employer match
Devpost profile page & all jobs

Web Developer (Mid-Level)

Location
New York, NY
Compensation
$80,000 – $140,000
(0.1% – 0.5% equity)
Visa assistance
Available

What you'll do

As a web developer on our team, you'll have a huge impact on all of our current and future projects. You'll contribute to product design, implementation, deployment, refinement, and ongoing performance tuning.

Projects that employees in similar roles have worked on
  • Worked with Stream to create an activity feed of all of the developers in your network including projects they're working on, projects they've liked, hackathons they're attending, etc.
  • Created a Team Discovery page using React and Elasticsearch to allow developers to find companies with jobs matching their skill set and experience level.
  • Created a Dashboard for managing a company's presence on our Team Pages including everything from user accounts to design aspects.

Requirements

What you need to succeed in this role

ruby-on-rails

  • Shipping web applications to production
  • Using Test-Driven-Development to guide your software design and catch bugs and regressions
  • Treating software engineering as a craft and exploring it outside of your day job
  • Experience developing, releasing, and maintaining web applications
  • Comfort with a server-side MVC framework (e.g. Ruby on Rails, Django, etc.)
  • Ability to write elegant, readable code
  • Attention to software development fundamentals
  • Track record of collaboration and leadership in agile software methodologies

Bonus points

We'd like to see these qualities or skills, but they aren't required

  • Experience with front-end technologies, libraries and frameworks (e.g. HTML/CSS, jQuery, Ember.js, Backbone, etc.)
  • Evidence of community involvement, i.e. open source contributions on Github, StackOverflow questions/answers, SlideShare presentations, Devpost portfolio showcasing your projects

Interview process

  • 30-minute phone screening with our Head of Engineering. Roughly 20 minutes of us interviewing you, leaving 10 minutes at the end of the phone call for you to interview us back!
  • Depending on your experience level , you may be asked to complete a take-home coding exercise to provide the team with a better understanding of your technical abilities. Nothing too crazy, shouldn't take more than an hour or two of your time, we know you're busy.
  • In-person session at the Devpost offices. The interview typically takes about 4 hours and consists of four sessions, 45-50 minutes each:
    1. You'll start with a Q&A session with some of the tech team to get a better idea of your work experience, technical abilities, and desire to work at Devpost.
    2. This is followed by two separate pair programming sessions where you'll be working with another developer here on production code. Typically we'll revert a bug fix/small feature we wrote the day before that is live in production, and work through implementing it again together.
    3. The day wraps up with a conversation with our founder and CEO, Brandon.
  • We'll conduct reference calls to learn more about you.
Apply now

Tech stack

Rubyonrails ruby-on-rails

Devpost is a monolithic rails app, with some satellites, mostly built with Rails too.

My mysql

Our main database.

Rabbitmq RabbitMQ

Recently added to our stack in an effort to move to a more evented architecture. Our activity feed relies on RabbitMQ heavily.

Redis redis

We use Redis for volatile, non-critical data.

Solr Solr

Solr powers all our search features. Hoping to transition to Elasticsearch 2.X one day.

Backbone Backbone.js

Used to structure our Javascript code.

Marionette Marionette.js

Most of our Javascript-heavy features are built with Marionette.js, including our commenting system, notifications etc.

Stream Stream

Powers our activity feed. We've had a great experience with it so far.

Slack slack

Some channels are bit GIF-happy, but everybody here loves this tool for team communication.

React react

Building a new search to find team pages, like this one

Engineyard Engine Yard

Provides hosting for our Hackathon platform

Postgre postgresql

Primary database for our Team Pages application

Elasticsearch elasticsearch

Powers the API that feeds data to our Team Discovery feature

Heroku heroku

Provides hosting for our Team Pages and our Marketing application

neo4j

Provides recommendations for users to follow on Devpost

Trello Trello

Meet the team

Meet the team

Nataliya Seryakova

Software Engineer

The best part of working at Devpost

I have been programming for around a year. I met Devpost after graduating from the Flatiron School immersive program in fullstack web development and we hit it off right away. My coworkers are the best part of working here.

I am lucky to say that every single person on the dev team helps me grow. My mentor Robin teaches me the most elegant and concise ways of doing any task. The lead developer Matthew sets aside time every week to meet with me one on one and works with me to analyze my experience and establish goals. I love pair programming with Ronan and he taught me how to be a git ninja. Matt Z gives me awesome feedback in his insightful code reviews. Nick is a Javascript expert and explains concepts really well drawing wildly all over the whiteboard.

My day-to-day

It is Monday and I am walking from the train around 10:30 excited to get to work. I eat eggs, sausage, and breakfast potatoes with an unreasonable amount of ketchup and we have a morning standup meeting to learn what everyone is working on. I choose a card to tackle from the Trello board. I go out to Num Pang for lunch or sometimes I eat at my desk because I am too into whatever I am working on. Robin beats me at ping pong. I pair program. Robin beats me at ping pong again. I have a beer and hang out.

Fun Fact

I grew up in Moscow. I often burn my tongue tasting food while I cook and when I walk, I always bump into things because I am watching other things.

Cyrus Ghazanfar

Software Engineer

The best part of working at Devpost

The people you work with determines how happy and productive you will be at your company. My colleagues are smart, experienced and fun which makes Devpost a great place to work.

My day-to-day

I arrive at the office walk to my desk and turn on the beast (my computer). From there on, my day is composed:
building features, solving problems with my teammates and at times brainstorming / planning with product.

Something I've learned at work

I learn something everyday. Whether it's something technical, something about the company, the people or my colleagues.

Robin Boutros

Software Engineer

The best part of working at Devpost

Almost 6 years at Devpost, and I'm still happy to come to work every day. I'm not even joking!

I get to make most of my friends jealous when I explain that we start at 10:30am, play ping pong every day, and have a fridge full of delicious food and beers...

But actually, that's just the icing on the cake. I'm the happiest when I get to work on user-facing features I care about. I also love being able to contribute and provide feedback on everything I work on. Sometimes, I can even add my personal touch! We're all striving to build the best product we can.

My day-to-day

Well, I made a whole website about that! Check it out: Working at Devpost. It's mostly about chocolate-covered almonds, but sprinkled with useful info.

Something I've learned at work

Technically, I learned everything I know about Rails at Devpost. I went from copy/pasting code from Rails tutorials, and being so confused about MVC and when to pluralize resources, to what I would consider a pretty deep knowledge of the framework. Historically, we've been pretty open to add new technos to our stack, when it makes sense for the product, so I got the chance to try and learn a bunch of them (Ember, Marionette, RabbitMQ, and recently React, just to name a few).

Devpost is the first and only company I worked at professionally. I had the chance to join the company very early, and I learned a lot about how a company has to change to grow. We strive to improve constantly, trying out new processes, new ways to learn from our mistakes, from our users, from each other. So, over the course of 6 years, I learned a lot about working as part of a team, using different methodologies: XP, TDD, Scrum, Kanban... and often a mix of them.

Overall, it's been, and still is, a blast to work at Devpost.

Fun Fact

When I started here, there were the CEO, a product guy, and my friend and me, both interns. We were sharing a small room with another company, with an angry woman always shouting. And now we're almost 20 people in a shiny new office doing great work!

Matthew Gerrior

Director of Engineering

The best part of working at Devpost

Besides the free food, free beer, chocolate covered almonds, and ping pong? Oh, and the team, can't forget that one obviously. For me, the best part about working here is the product that we're working on. Not only do we get to have input into the product instead of just being told what to do from the top down, we're also trying to build a product that developers want to use. It's a win-win and I don't think many developers get to say that about their positions.

My day-to-day

I don't know if there is such a thing as a typical day-to-day around here. Between games of ping-pong, there is a wide array of activities that any developer may encounter in any given day. There are one-on-ones with Brandon, one-on-ones with Ross, brainstorming/reviewing/scoring OKRs, attending brainstorming meetings, replying to brainstorming emails, screening potential candidates, interviewing potential candidates, dogfooding, eating team lunch together, drinking beer, code reviewing the work of other developers, working with QA to review issues on staging, and actual development work.

Something I've learned at work

One of the biggest things that I've learned coming from a consulting background is learning how to present my vision for the product and how to work towards a product that I want to use every day. Despite having a product team that creates the vision for the product, the developers here have a ton of opportunities to provide feedback and steer the direction of the product. Additionally, I've improved a lot when it comes to pragmatism in coding in terms of always working towards an MVP and choosing the best tools for the job, even if they aren't the latest and coolest tools.

Fun Fact

I volunteer with ScriptEd which is a non-profit geared towards bringing computer science education to underserved high schools in NYC. Not only do I get to hopefully help fix the talent gap in our field, I get to do it at a high school right down the street from my apartment that I walk past on a regular basis, so I get to help out kids in my own neighborhood.
I'm also a mentor at the Startup Institute, teaching the Web Development topics (using Ruby on Rails as the platform). It's a great chance to help students that are looking to make a change in their lives as well as reinforcing the material through teaching so that I better understand it myself.

Matthew Zheng

Software Engineer

The best part of working at Devpost

I came from a completely different company culture and technology stack and the team helped me get situated and up to speed. Everyone is incredibly helpful and willing to lend a hand when you have a question.

We also get coffee, food, and play ping pong a lot. Hard to complain.

My day-to-day

I spend most of my day working on features for our platform. I get to experiment and build things with technology like rails, rspec, capybara, sidekiq, hutch, redis, mysql and many more.

Something I've learned at work

I came from a large insurance company and most recently developed in c#. The culture and technology at Devpost was completely new to me. I've learned what it's like to be at a startup. There are a lot less meetings, the pace is much faster, and you get free coffee. I've also had to learn a new language and framework. A lot of my prior experience was transferable but there was definitely some new stuff I had to learn as well. The team helped me get up to speed by pairing with me and helping me with my code reviews.

Fun Fact

I can do close to a million pull ups.

Jonathan Chu

QA Engineer

The best part of working at Devpost

I love working at Devpost because of the awesome team. The team is very supportive in helping each other. Any questions or concerns are addressed quickly. Plus, everyone has a great sense of humor!

My day-to-day

My day starts off with the morning tech huddle where the team discusses what we are working on and any important issues. Throughout the day, I test new features, report bugs, write test cases, and help out on support tasks.

In between all of this, I fit in ping pong games with the developers.

Something I've learned at work

Devpost gave me the freedom to learn and experiment with new ideas. From implementing any new process to using a new tool to help QA, Devpost is very supportive of trying out anything that benefits the team. Also, a lot of other companies try to follow Agile methodology, but at Devpost I have gotten to see its full potential first hand. Complex projects are broken down into smaller pieces of work. Code is much more manageable and deployed with less risk. All of the above has helped me grow professionally and personally where I am able to learn from my experiences.

Fun Fact

During my free time, I enjoy watching/playing basketball, collecting sneakers, and playing Starcraft 2.

Ronan Potage

Software Engineer

The best part of working at Devpost

The team is awesome, the office is great and we are helping to grow the developer and engineering community, a goal I particularly cherish.

My day-to-day

I come in at 10, wake myself with a cup of freshly brewed coffee (thanks Stefanie!) and wake up my computer with a hit of the keyboard. I then check our main Trello board to be ready for our daily standup at 10:30. During the day I work on my stories, help others that ask for help on Slack and pair program on some other stories.

Something I've learned at work

I already knew the startup environment thanks to my previous experience; it's dynamic and rewarding. Devpost which has a bigger dev team enabled me to learn a lot about team and work organization. Having a product team helped me to be more efficient on execution, and taught me how to collaborate better. We also use great tools and processes to achieve continuous integration. And good thing about startup environment is that I can actually act on that process and tool part, which is something I particularly cherish. And working with talented peers also improved significantly my code style and skills; I really feel that I've grown both as a engineer and human being.

Fun Fact

I'm French, I love trains and use a trackball.

Gender – company
Ethnicity – company
Gender – dev team
Ethnicity – dev team

Dev process

We deploy to production 5-10 times per week. Here's how the magic happens:

    How work gets started

    After initial discussions with a tech lead and business stakeholders, the project will be broken down into the smallest releasable pieces. A product team member will wireframe/design the solution and document requirements/specifications on a trello card for each piece of work. Then they’ll work with the tech lead to review specs and estimate the card..

    Stand-up

    Every day the dev team starts with stand-up. We each talk about what we're working on, ask for help, and discuss what's coming up next with the Product Team and our CEO.

    Trello is an integral part of our workflow.

    Coding time!

    Developers are free to work on a story on their own or pair with another developer to brainstorm the best solution or tackle a problem together.

    Watch this interview where Matthew talks about pair programming with Neal:

    Code reviews

    We jump on code reviews after our morning stand-up, before getting into our current stories, or whenever we have a moment. Our comments focus on code quality, maintenance, performance, etc. We do our best to keep the discussion at a supportive level, and to avoid nitpicking on coding style issues that will be caught by tools like Rubocop.

    Review / QA process

    Once the Trello card has been code reviewed, the Review process begins. This involves cross-browser testing, mobile testing, data testing, and/or any regression testing that is needed. QA works with Dev and Product to address any bug fixes or design changes. Test cases are usually done beforehand. Once everything passes, the Trello card is ready for Deployment to Production.

    Dev Thursdays

    Thursday afternoons are special. We call them Dev Thursdays and they're our take on Google's fabled 20% time. Take a crazy idea you're passionate about, build a prototype, and iterate on it. Several Dev Thursday projects that have made it to production include Devpost Search, :emoji: support, and an unofficial Devpost API.

    Team hackathons

    We power almost 100 hackathons on our platform every month, so occasionally we run team hackathons to hack our hackathon platform (very meta). Check out the awesome projects from our last team hackathon!

Q&A

  • What kinds of projects are you working on right now?

    Neal Shyam · Community & Marketing

    The Commit, our podcast, the weekly Devpost newsletter, my Table Numbers app for hackathon expos, and lots of other fun internal & external hacks.

    Matthew Zheng · Software Engineer

    I helped build the page you are looking at right now! We are creating an avenue for development teams to talk about themselves and give important information to candidates.

    Ronan Potage · Software Engineer

    I'm working on Team Pages, a way for us to present companies differently. We want to make sure those who search for a job have the most accurate first picture of the company they apply to.

    Jonathan Chu · QA Engineer

    I am usually testing new features and bug fixes on Platform, but lately most of my time has been spent on testing the Team Pages. It is a fast paced, exciting project with a lot of challenges, but fun to be on the team that built it from the ground up.

    Nataliya Seryakova · Software Engineer

    I am building the new Team Pages recruiting platform that helps developers find fulfilling jobs!

    Cyrus Ghazanfar · Software Engineer

    I am currently working on the new Team Pages application and reimplementing the Commit video channel into a Rails application.

  • What kinds of technical challenges do you and your team face?

    Neal Shyam · Community & Marketing

    I think we've struggled a lot with the decision around whether to build an API, a mobile app, and to expand certain products. We've heard from a lot of users that they'd like to things -- but without a business case, we're probably going to hold on them.

    Yeah, it's less 'fun' in some ways, but it means we can focus our attention on growth & revenue goals.

    Matthew Gerrior · Director of Engineering

    I think one of our biggest technical challenges that we face is having a monolithic Rails application which has been maintained for over four years now, from Rails 2.1 to Rails 4.2 (so far). Not only has the application seen many different Rails paradigms over the years, but also many different developers' interpretation of good code and good formatting.

    We've gone from ActiveRecord callbacks to ActiveRecord Observers to an Event-Based architecture built on top of RabbitMQ, but with remnants from all stages of that progression. Other than that, we also have the challenge of trying to maintain/upgrade the hackathon platform at the same time we're trying to grow our social networking features and pivot in to a completely new recruiting product, all at the same time.

    Matthew Zheng · Software Engineer

    I think one of the things we can improve on is to have a consistent set of guidelines in our code for patterns and practices. We will occasionally see similar problems tackled in different ways. Sometimes this can be confusing because you don't know which approach to go with. One of the things we do to try and mitigate things like this is to have a bi-weekly meeting to discuss any issue the team is having. This gives us a chance to vet out a solution with a team and establish a standard going forward.

    Robin Boutros · Software Engineer

    Our code base is pretty massive, due to the fact that we have a number of different products, all intertwined. That's the legacy part, and it has its challenges. But these days, we're building a whole new and shiny hiring product to help our community members have a fulfilling dev lives and jobs, and this too comes with its own set of challenges!

    For the first time, we're building a large product as a separate app, instead of as our monolithic Rails app. It involves figuring out authentication strategies, how the two apps talk, share info with each other, etc. It's fun.

    Ronan Potage · Software Engineer

    Writing good code and collaborating is not easy and already is a challenge. Scalability and releasing features and project fast within secured environment for our customers are great goals too.

    Cyrus Ghazanfar · Software Engineer

    Writing scalable and maintainable code that is clean and robust.

  • Any advice for potential / new hires? (What do you wish you'd known before you started here?)

    Matthew Gerrior · Director of Engineering

    When you set up your email on the first day, and you get a barrage of emails from all the different services we use, be sure to set up your password manager first! It will be much easier to sign up for all of the services we use when you have a program randomly generating secure passwords and storing them for you. Other than that, make sure you ask someone where the chocolate covered almonds are. We can't give that type of information away to the general public, but they make the work day so much better.

    Matthew Zheng · Software Engineer

    We use several third party services for our daily operations. Github for tracking our code, Trello for managing our work, Solano for our continuous integration, EngineYard for our server infrastructure and the list goes on. While you don't have to be an expert right off the bat, I think having some familiarity with these services would be helpful. Github is probably used on a daily basis and if you are coming from another type of source control, it would help to learn some of the basic principles and commands.

    Robin Boutros · Software Engineer

    Try to find the balance between asking questions (never be afraid to ask!), and trying to explore the code base and learn on your own. Don't be afraid to challenge the way we do things, and bring something new to the team! Over the years, all our new team members brought something new to the table, whether it was a process improvement, a passion for security, better code practices etc.

    That being said, understanding and respecting why some things were done a certain way in the past is also important.

  • What do you like most about your office space?

    Jonathan Chu · QA Engineer

    I love the amount of natural light we have in our office from the skylights and the large loft windows. It makes the office feel less confining and helps keep me in a pleasant mood.

    Matthew Gerrior · Director of Engineering

    Our office allows the different teams of our company to sit together allowing quick and easy collaboration. The ping-pong table also allows us to blow off steam in the middle of the day and clear our head before getting back to work on a difficult task. The phone booth is also really convenient too since you can make personal calls and get right back to work without having to leave the office.

    Matthew Zheng · Software Engineer

    We have an open environment so you can easily turn around and talk to a fellow developer if you need to. If you think it's going to cause too much noise, we also have two meeting rooms that are available. One of them even doubles as our ping-pong court!

    Ronan Potage · Software Engineer

    The office environment is really great, tons of food, coffee and even a real espresso machine! It's an open space so it's easier collaborate. Fun fact: our conference room table is also a ping-pong table. Also, the Meatpacking neighborhood is pretty cool, great food options and obviously, the Highline park.

    Nataliya Seryakova · Software Engineer

    I love the view of the sky and High Line from the conference room window and the kalamata olives and trader joe's salami in the fridge!

    Cyrus Ghazanfar · Software Engineer

    It's open, spacious and bright. You have a great desk, a full fridge. Basically everything you need to be comfortable and productive.

  • What ideas and tech have influenced your work?

    Robin Boutros · Software Engineer

    I started using Marionette at work a while back. It started after building an advanced and JS heavy search feature, where I saw the limitations of using Backbone without Marionette or a similar library. I now use both in all my side projects.

    Matthew Gerrior · Director of Engineering

    One idea that has influenced my work is the 80/20 principle and YAGNI. Every time product comes to me with one of their amazing ideas and incredible mock-ups, pretty much the first thing I'll ask is if there is an alternative / simpler solution that will take 20% of the time and get us 80% of the way there. It's especially important in a start-up that is trying to find their fit and isn't 100% if they are building the right thing. The sooner you can get something in the hands of the user, the sooner you find that out.

    Ronan Potage · Software Engineer

    Convention Over Configuration and RoR best practices did definitively influence my work.

    Nataliya Seryakova · Software Engineer

    The most important thing I learned as a programmer is to be ok with being uncomfortable. Those moments of suffering when you feel stupid and lost while mastering something new are the ones when you are learning the most. I try to embrace these feelings as much as possible and set my pride aside.

    Cyrus Ghazanfar · Software Engineer

    The Single responsibility principal of object oriented design.