Internal hackathons have become a common practice for tech companies these days. Here at SparkPost, we hold two hackathons a year and are happy to have made them a long standing tradition. So the question is, why do we hack? What value do we see in taking people away from their normal work and having them spend two days on completely different projects?

Building Relationships

The first benefit of internal hackathons is the social aspect. During hackathons you get to work with people from other teams, people you’ve possibly never worked with before. There is a lot of value in forming new friendships and strengthening bonds by working toward a common goal together. Hackathons also let you see your coworkers in a new light. Maybe someone has a real talent for something and only during a hackathon do you get to see them excel in their area of expertise. Learning people’s hidden strengths makes them more valuable to the company and allows them to grow even further in areas that are of interest to them.


Creativity is a second important benefit. Hackathons allow people to unleash their creativity. Taking a break from your normal workload for a couple of days can help refresh and reset the mind allowing you to tackle your normal projects with renewed vigor when you get back to it on Monday. Engineers often encounter small problems during their normal work day but don’t have time to fix them. Or they see ways in which their project or product can be improved but don’t have the bandwidth to expand on those ideas. Hackathons provide a space for people to voice their ideas and get immediate proof of concept.


All of this leads to the third important benefit, hackathons encourage innovation which can be invaluable to a company. So many people have great ideas for ways to improve the product they’re working on and hackathons give them the opportunity to delve into that idea and potentially get it to production. At SparkPost several of our hackathon projects have made it to production including our Zapier integration, HEML, our A/B testing API, our internal customer service app, and more. In addition to producing customer facing products, hackathons also allow the time needed for people to improve architecture and problem solve.

All in all, hackathons are great for our company. At SparkPost, we highly encourage cross team and cross company camaraderie and teamwork. We highly value creativity and praise innovation. Hackathons allow people to look up from their computers and see what could be in the future. It gives them a chance to focus on the bigger picture and flex their inventive muscles. We’ve done ten hackathons so far and we can’t wait to see what cool projects come from the next one.

Hackathon X

Check out this video from our most recent hackathon to learn about some of the exciting projects our engineers are working on!



Have you ever embarked on an adventure to learn a completely new skill set? Did it make you feel overwhelmed with no idea where to start? For many of our community members, that feeling is more common than you’d think. Tons of developers or coders didn’t originally start out on that path, and today we’re chatting with someone who’s making big waves and providing a ton of resources for newbies in the coding community.

Meet Saron

Not too long ago, Saron was also new to coding. She worked for a few different start-ups, but became more and more interested in the product side of things — which required a more technical background. So Saron did what any motivated self-starter does — she vowed to teach herself. From there, she started her own bootcamp and conference to help others!

Today, Saron has built the CodeNewbie community, a growing network of over 15,000 people who join in on weekly twitter chats, listen to podcasts, attend CodeLand (check out Cole’s experience teaching a workshop) and exchange ideas with others working on projects in tech. Saron was gracious enough to share some insights on the community she’s built, her favorite part about her job, and advice for those just starting out. I hope you enjoy!

Enter CodeNewbie

What’s your background in the tech world, how did you get started down this path?

I first got interested in tech after reading the Steve Jobs book. It was the first time I saw the connection between tech and more liberal artsy topics like design and psychology. I then read everything I could find about tech and startups, and eventually worked at a few startups. I worked primarily on the business side of things, but I was always more interested in the product. Because I didn’t have a technical background of any kind, I felt that the only way I could have a say in the product was if I invested in learning how to code. So I quit my job, taught myself for a few months then enrolled in a coding bootcamp.

Why did you start CodeNewbie?

When I started my coding bootcamp, I was surprised to find that I not only learned a lot, but gained a lot of confidence in what I already knew. I realized that when I was learning on my own, I’d been internalizing the natural failure that comes with coding, and interpreting my struggles as my own stupidity. But in my class, I saw that everyone was struggling! It removed so much of the emotional burden that I could actually focus on learning. The true benefit of the bootcamp was the community. But finding that community is hard if you don’t have $11K and can’t quit your job. So I wanted to create a way for everyone to have a supportive community, and that community is #CodeNewbie.

In your opinion, how important is community in the programming world?

It’s everything. Community is how you get out of your own way. It’s how you get jobs, opportunities, make friends, build partnerships, create meaningful change. I’m here today as a result of the incredibly kind community around me, and that’s what I hope to provide for others.

Why did you start the CodeNewbie podcast?

When I decided to do the CodeNewbie Podcast, I’d been doing the #CodeNewbie Twitter chat for about a year. I loved the chat. It was such a great way to connect people and start conversations. But it’s not a great medium for diving deep into a topic or a story. Since I’d previously worked at NPR, I thought that a podcast was a great way to focus on one story, one problem, one idea, and really explore it. Audio is such a flexible medium because it’s one of the few you can consume while partaking in other activities. I felt it was a great way to provide a weekly dose of knowledge and inspiration in the lives of our community members.

Which episode is your favorite so far and why?

This is tough! I’d have to say Season 1, Episode 2: “Building community in a virtual world: Moderation tools in VR Cameron Brown.” On a content level, I personally learned so much in that conversation and really appreciated the passion from Cameron. You can hear in his voice how much he loves creating a safe space for all. He talks so matter of factly about topics like diversity and inclusion, and how obviously important they are, in a way that I’ve never heard from a developer that absolutely blew me away. On a production level, I got to be more creative with the intro, so mixing that was lots of fun.

There are 150 episodes on the CodeNewbie podcast. For new listeners, where should they start?

It depends on their goal. If they’re looking to learn more about CodeNewbie in general and what we’re all about, definitely checkout the episode where my husband interviewed me. For job-hunting inspiration, I loved Paola’s incredibly powerful interview on her journey to finding a job. To hear how tech and society collide, I thought Carina’s episode on algorithms was brilliant. For an inspiring story on persistence and dedication, definitely checkout George Moore’s episode “Truck Driver.”

What are some great resources for all the CodeNewbies out there?

There are so many! The obvious ones are Codecademy, Coursera, Khan Academy. But there are also great communities like Girl Develop It, Women Who Code, RailsBridge, Hacker Hours, PyLadies.

Do you have any advice for people who want to begin their own journey in programming but don’t know how to start?

Yes! Nothing is going to make sense for awhile. It’s going to take a lot of beating your head against the wall, not really knowing how useful what you’re learning is going to be, and not building anything that seems relevant to a job before things start to click. That’s just part of the process. I think newbies obsess over starting with the right thing and seeing immediate results, and this results in people quitting much sooner than they should. So I’d say, pick a language with a large and supportive community (ruby, python, javascript are great for these reasons), pick a free resource that doesn’t require much setup (I usually recommend Codecademy), start and then *stick with it.* Over time, things will fall into place.

Questions for Saron? Join in on her weekly Twitter chats on Wednesdays at 6PM PST/9PM EST! Questions for us? Reach out on Twitter or find us in our community slack.



A few months ago, our community manager Mary Thengvall asked Avi Goldman and I if we would be interested in teaching a 3-hour technical workshop at the upcoming Codeland conference. Now, neither Avi nor I had ever attended a workshop, let alone run one. But Codeland is organized by Saron Yitbarek with help from members of her CodeNewbies community (please do yourself a favor and go follow them both). Saron has a sharp mind and a warm spirit and she has built an amazingly supportive community. We knew that we would be free to be beginners. So, with sweaty brows, we said yes.

Looking back at the overall experience, we did some things well. Some things? Eh, they could have been better. Here are some of the highlights:

We Started Early and Created Milestones

We started planning 9 weeks before the conference. Avi and I came up with the major tasks, guessed how long each would take, and divided up the work. To make it easier, we documented everything:

  • We created a public Github repo to track all of our tasks as issues and then added those issues to a Github project to track our status.
  • We made a milestone for each week leading up to the conference and assigned each issue to one of those milestones.
  • We assigned tasks to each other so we could track who was responsible for each piece.
  • We had weekly check-ins to make sure we were on schedule.

This is the most organized I have ever been in my life.

We Trusted Each Other

I can’t tell you how many times during our check-ins Mary and I had this conversation:

Me: I’m at least two weeks behind where I thought I would be.

Mary: So do you think we’ll have it ready in time?

Me: Oh definitely!

And to her credit, Mary trusted me. Her trust increased my desire to be accountable, and so I was much more motivated to follow through. This follow-through helped increase her trust in me down the line. It was a nice virtuous cycle.

Lesson learned: Enact trust and amazing things will happen.

We Trusted The Participants

One of my mentors would tell me: “everything you need is already in the room.” To me this means, in part, that when I’m teaching or leading a group, I don’t need to bring all the knowledge or all the energy. I am in a room full of intelligent, inquisitive, and insightful people. Rely on them and help them rely on each other.

With that in mind, we had people split into groups of two and work through the exercises together. Our goal was to create a supportive environment and answer questions when people were really stuck, but to by and large stay out of the way and encourage people to talk things out together.

So many wonderful things came out of these pairs of strangers, I could write for pages and pages about it. But I’ll leave it at this: most people stayed to talk with their partner long after the workshop ended and they had packed up. I even saw some of them working together on Slack later that night. That was a huge sign of success to me.

We Were Over-Prepared (In a Good Way)

We had 8 exercises of increasing difficulty for a 3 hour workshop. It took me about 15-20 minutes to do each exercise the first time, so I figured most people would only get about halfway through. We also knew that we might have an experienced Javascripter in the workshop who would speed through the early exercises. We wanted our workshop to have something for them too.

With the extra preparation, we can also turn this into a longer workshop with only a little extra work. By making the workshop thorough and reusable, we help our future selves.

We Were Weird

Ok… this one mostly falls on me. And honestly I can’t say if this actually helped anyone learn anything.

You see, I watched a lot of TV growing up and for some reason while writing my slides, I got it into my head that the early to mid 90’s TGIF lineup was a good theme. Keep in mind, a large portion of our audience was likely in their mid twenties… meaning these gifs are older than them.

But as a presenter, having a theme that I found funny and engaging was helpful. I had an easier time writing my slides and I was excited to share what I wrote with our participants. That excitement helped me cut through the anxiety of presenting as well. (The patron saint of Kevin James on a jumbotron also helped, tbqh.)

We Didn’t Follow Our Milestones

There were things we could have done better. Like I said, we started planning 9 weeks out. “9 weeks is forever,” I thought. “I’ve heard that 4 women can have a baby in that time. Surely we can plan a single workshop by then.”*

Oh the hubris.

We had a crunch at the end. I spent a Saturday afternoon or two sipping on Dunkin Donuts free wifi. We never really used the project kanban board. And more than once I found myself filing and closing issues for tasks after they were done.

I think nine weeks gave us a false sense of security that continued as the conference got closer. If we had started five to six weeks out we probably would have been more focused.

In the end, even though we were still crunched, more than doubling the amount of time we needed served us well. It meant that we could slip and still be on time. It left us time for work emergencies and to go home to our families. We could have planned on a 3 week rush and we could have finished fine, but the anxiety/effort ratio would have been much higher.

We Were Under-Prepared (In a Bad Way)

Again, I think this was just me. Codeland is a conference for #codenewbies, and I expected that most people coming to our workshop would have familiarity with Javascript even if they weren’t senior developers.

In retrospect, I should have expected some of our participants wouldn’t be very familiar with Javascript and Node.js. I saw a few groups who were confused by asynchronous callbacks. I could have done a better job preparing them for asynchrony, but I found myself flat-footed. I didn’t have a good explanation for how callbacks work (even though I’ve watched my good friend Jason Rhodes do this several times).

I think in some cases the disparity between partners’ abilities was difficult for them. If I could do anything over, it would be to prepare more for people who were newer to Javascript.

Wrapping Up

Holy cow was this a lot of work. It was also so rewarding! Meeting Saron, being part of the CodeNewbies community, and doing something scary that we had never done before; I’m so glad we said yes. I’m already looking forward to the next one. I mean, so long as Kevin James is there to watch over us.

*This is a reference to Brooks Law in “The Mythical Man-Month,” which is sometimes phrased as “nine women can’t have a baby in a month.” Nobody at SparkPost gets the joke, but I think it’s funny and so far they haven’t talked me out of it.

– Cole Furfaro-Strode

Have you run a technical workshop in the past? Are you about to? Comment below or send us your tips on Twitter

Dev Survival Guide Blog Footer

Introducing SparkPost Labs

We love to experiment with new ideas at SparkPost! Our regular hackathons are one way our engineers bring to life new ideas. Our engineering team has cooked up some great user features and tools during hackathons or other engineer initiated projects. Some favorite features that began life as hackathon entries are webhooks, multi-factor authentication, the new real-time suppression api, CSS inlining, and even the use of AngularJS for our web UI.

But it isn’t easy to take a proof of concept that is hacked together in 24 hours and release it in the wild. As you might expect, we have high quality standards at SparkPost and expect our APIs to be fully vetted, conform to performance standards, and be versioned. Normally for a hackathon project to make its way to production as a fully supported feature, it will require additional work by Engineering to ensure the feature is fully baked. The downside of our super high standards is many of these very cool projects don’t get to the top of the priority list.

That’s why we created SparkPost Labs—a new program that helps our engineers more easily share new and experimental API and App functionality and other helpful tools with our developer community. This way we can find out sooner if there is interest in the feature, get valuable feedback from our community, and decide to fully-productize if it’s a hit. It’s a great way for our community to be actively involved in the direction of SparkPost!

We’re launching SparkPost Labs by introducing a new A/B Test API endpoint.

What You Need to Know

SparkPost Labs features are different from other new API features that we often expose to customers in beta form. When we beta a feature it is versioned, supported, and production-ready. While beta features may sometimes be initially limited in scope, we release them with the full intention that they will be supported and expanded over time. However, what we release under SparkPost Labs may be discontinued completely or re-envisioned before making it into the core supported product. It’s really up to you, our community, to help us determine what features are most valuable to take the extra mile. Caveat emptor!

Here are some helpful tips to keep in mind when you try out anything marked as “SparkPost Labs” in our API docs:

  • Labs API functionality is not versioned. As such, it is available under a distinct /api/labs/ path rather than /api/v1/ path.
  • Any API feature accessed via /api/labs/ is by definition experimental and subject to change. We may decide to change the behavior or discontinue it at any time. We also may decide to incorporate Labs functionality into the core supported product.
  • Normal support channels or SLAs are not available for SparkPost Labs. You can provide feedback via this Google form. We will route your feedback to our engineering and product teams.

A/B Test API

An A/B test is a fully managed API method of comparing templates to see which one performs better, and automatically choosing the better performing template. It is super simple to use: you provide two or more templates, a recipient list, a sample size, and a test duration to begin. The A/B Testing API endpoint provides the means to create new tests, and view completed results.

The API randomly chooses recipients from the recipient list equal to the sample size. The API distributes sample recipients among the templates and transmits emails.

 SparkPost labs image 1

When the test time has expired, the template with the best conversion rate wins.

 sparkpost labs image 2

All remaining recipients will be sent the winning template.

 sparkpost labs image 3

Example API Call

POST /api/labs/ab-testing


The A/B API endpoint is our first SparkPost Labs project. If there is enough interest from the community in this kind of experimental feature we will do more – so please give us some feedback!

If you have any questions or comments about SparkPost Labs please don’t hesitate to connect with us @SparkPost – and we are always hiring.

Chris McFadden
VP Engineering

2016 hackathon review

2016 Hackathon Review

This year we challenged you to “Build Something Awesome” with SparkPost. To motivate you further, we sponsored 5 different Hackathons across the USA with cash and prizes. We also sent along our own engineers in order to mentor those who accepted our challenge. As a result, the response was incredible and we’d like to recognize the winning teams.

Developer Week

We started the year in February at the Developer Week Hackathon in San Francisco. We selected three teams that demonstrated the best use of our Inbound Email, Data & Analytics, and the SparkPost Heroku Add-on.

Best Use of Data & Analytics

Kaushik Ashodiya and his son created SparkPost ONTAP, combining our data with Net Cloud ONTAP to store webhook and campaign data. It allowed users to view or edit historical campaigns, as well as replicate the storage for disaster recovery and availability purposes.

Best Use of SparkPost Heroku Add-on

The team comprised of George Portillo, Stephen Fuller, Victor Sanchez, and Sal Casillas created Grab & Go, an application that leveraged the SparkPost Heroku Add-on to help alleviate the long lines found at the local food trucks. Their solution uses our transactional email to alert customers when their food is ready for pickup after placing an online order.

Best Use of Inbound Email

Marlon Frausto, Anna Wu, Ravender Virk, and Jigesh Parekh set out to tackle San Francisco’s affordable housing dilemma and created DwellWell. They used our Inbound Email to set up a double blind communication channel, allowing people to request information about a particular housing option with some anonymity. The DwellWell team has since continued their partnership with SparkPost to create PublicBNB.


In early March, we headed to Rochester Institute of Technology in New York for BrickHack. After 24 hours of hacking, we selected UBinE by Stephen James as the Best Use of the SparkPost API. This application uses transactional email to assist in planning, tracking, and notifying students of campus events.


In April, we headed to Bitcamp at the University of Maryland. Because of our close proximity, we got to send multiple engineers of our own to mentor at this 36 hour hackathon. Henry Saniuk, Sneha Vaswani, and Stuart Olivera won our “Build Something Awesome using SparkPost” challenge with their PiggyPennies application. This application made use of our inbound and transactional email and the CapitalOne API to while helping friends save money together.


After a long summer break, we headed to the University of California San Diego’s SDHacks, a 36 hour hackathon. At this event, Kevin Burns and Jack Zeiders had some fun with SparkPost and created an email based gaming service called QuibbleMail. Using only your email, you can challenge a friend to a game of Chess or Tic-Tac-Toe. Their use of SparkPost inbound and transactional email allows you to play without leaving your email client.

MLH Prime Southwest Regional

Finally, we wrapped up 2016 in Austin, where Major League Hacking pulled together the region’s best hackers for 24 hours. Bailey Breaux, Ali de Jong, Yuriy Minin, and Patrick Edelen blew us away with Mochi, their Jibo robot integration for patient care. The team used SparkPost’s inbound and transactional email to empower Mochi to contact a patient’s family via email and read aloud any replies.

At each event, the response to our challenges was amazing. So many of you Built Something Awesome and we thank you. As a result, we’ll be back out there in 2017 and we’ll be sure to keep you updated. Our first stop will be a return to Rochester in February for BrickHack 3. Because we take your feedback into account, we’d love to hear what events you’d like us to attend. You can chat with us on our community slack or send us a tweet @SparkPostDev.

— Aydrian

So, what’d you think of our 2016 hackathon review? What were your favorite hackathons from 2016? Any hackathons on the agenda for 2017 yet? Leave us a comment below.

what do hackathon judges look for

You’ve formed a rockstar team, worked your butts off to create the best project possible, gone without sleep and with more energy drinks than you’d care to admit, but it’s just about done. All that’s left? Presenting to the hackathon judges. So take a deep breath — you’re in the final stretch!

We know it can be stressful. After all, your blood, sweat, and yes, even tears, are wrapped up in this project, and you only have a few short minutes to convince everyone else that it’s as awesome as you think it is. So what do you do? We have a few suggestions.

You Do You

You and your team know this app inside and out. More importantly, you know why it’s awesome, what sets it apart, why it’s important, what its quirks are, and why you chose to build it the way that you did, which is exactly what hackathon judges will want to know.

Some key points:

  • Know what the qualifications are going in. Some hackathons have specific judging criteria for particular prizes, or even for turning in your final project. Hence, set aside the last 15 minutes of your hacking time to make sure you’ve dotted your i’s and crossed your t’s.
  • Don’t give a sales pitch. You aren’t selling a product, nor are you trying to get funding for a start-up. Hackathon judges care less about the potential future of your project, and more about what you built and why you built it in that way.
  • To that end, know your whys. Come prepared to answer questions about why you chose to use those particular languages and tools, what led you down your particular process path, and what your experience was along the way.
  • Be enthusiastic. I know you’re more likely to be thinking about sleep and a good shower at the end of a hackathon, but splash some cold water on your face and find the excitement that saw you through building the app for just a few more minutes. Enthusiasm is contagious, and you’ll want to show the hackathon judges that they should be equally as excited about your project.
  • Be You. Don’t try to dress up or be someone you’re not. Just show your excitement for the project, clearly communicate the ins and outs and quirks, and do your best to leave your nerves behind.

Just remember, you're awesome!

Hackathons are About the Journey

Ultimately, remember that the awesome thing about participating in a hackathon is the hackathon itself, not the prize. While winning is cool in its own right, remember to have fun! So focus on meeting awesome people, learning new skills, and building cool projects, not whether you won the best prize. Then once you’re done (and maybe after a nap), don’t forget to celebrate! Also, you’ve done something that few people ever do. You’ve invented a brand new product in just a few short hours, and that’s worth a 30-second dance break.

We all deserve an awkward 30-second dance break.

Interested in trying your hand at a hackathon? Keep an eye out for more information on MLH Prime Southwest Regional. We’ll be there representing SparkPost and would love to help you build something awesome!

In the meantime, check out our Developer Hub, where you can find code example, ideas for projects, and more. We look forward to seeing what you build!

–Mary Thengvall

Zillions Guide Blog Footer

We’ve been to a few hackathons and even host our own, internally, twice a year. In fact, last year everyone got a pony! (Sort of). That’s why it was easy to crowdsource from our community some of the best things to bring to a hackathon (i.e. hackathon necessities). Here are some of our favorites:


Obvious choices


  • computer
  • mouse
  • power cord

Although, when I asked folks what the craziest thing they ever saw was, NY Hackathons weighed in with this:

Common, yet not exclusive choices

  1. Red Bull/energy drink of choice. From what we hear, it’s a necessity. And our own Aydrian Howard, who recently wrote about how to get the most out of your first hackathon experience, can’t seem to live without caffeine.
    hackathon necessities
  2. Spare clothes. Apparently, nothing feels better than putting on clean clothes, even if you’re not 100% clean.
  3. Blanket. Let’s face it, it gets chilly sometimes. Plus, you can fold it up and use it as a pillow.
  4. Toothbrush and paste – unless you want to be relegated to Slack, your teammates will appreciate a little minty freshness.
  5. A good night’s rest – rest up the night before because you’re going to need it! Trying to pull an all-nighter on limited sleep makes you a sloppy coder.
    via GIPHY
  6. Chargers and/or spare batteries. You can never have enough juice and there are never enough plugs to go around. If you want to make friends fast, bring a power strip.
  7. Earphones/headphones. Everyone gets their own vibe on with their own tunes. Here’s a hackathon playlist we put together on Spotify for you. Let @tracysestili know what you think.
  8. Backpack/empty bag for swag. There is always swag at these things, all edible swag usually gets consumed on site. But if it’s not edible, then you’ll need an empty sack to bring home your goods.
  9. Favorite snacks. Nuts anyone? But seriously, if you’re a picky eater or if you eat a lot, then packing your own snack(s) is the way to go.
    via GIPHY
  10. Notebook/scratch paper + pen/pencil. Sometimes whiteboards aren’t readily available and so you need something to map out your schema.
  11. Jacket/hoodie/beanie. When you’re just sitting there for hours, you get cold because your body isn’t moving. And a hoodie or a beanie are great for those rooms where the vent is blowing right on your head.via GIPHY

Do you have any favorites? Anything crazy you’ve seen? Let me know in the comments below.


Big Rewards Blog Footer

conference swag

A Round-Up Of Conference Swag Favorites

The best conference swag I’ve ever received was an extra phone charger battery (pre-charged). As the Director of Online Marketing at SparkPost, I take an interest in the items we choose to give away (and what items resonate with people), as we’ll periodically host giveaways on social media – Jennifer loves any excuse to send out swag to our community members.

Recently I was reading my Twitter feed and another Jennifer (@sigje) who helps organize devopsdays in Silicon Valley, asked a simple question that got some great responses:

She took the conversation further by asking, “Beyond the booth giveaways, what about the specialty items that they do drawings for? So often it’s drones right now. What do people value?

The responses were overwhelming. They ranged from a Macbook Pro with an app store gift card to really nice pens, Swell water bottles or functional USB hubs. I think it really depends on the audience, don’t you? I am a marketer, so I recently dropped my business card in a fishbowl at a conference for a chance to win a 3-D printer – I mean who wouldn’t? Can you imagine what I could make with one of those? I would have dropped my business card in there a hundred times if it had increased my chances!

But the fundamental problem with booth giveaways and raffles is that you know you are going to eventually be nagged by a sales person to buy their product or service. Am I right? So you’re more apprehensive and less willing to let booth staff scan your badge or drop your business card in, unless you really think it’s worth it. I mean if you could just sneak up to the booth without anyone seeing you and snag some swag, that would be the best – but that’s not realistic.

At events we’ve sponsored in the past, we’ve given away various t-shirts, flasks, graph pads, bottle openers, laptop stickers, iPads, iWatches, drones and BB-8s. On social media, we’ve given away Stance Star Wars socks, Star Wars comic books, and recently in an email we gave away limited-edition client library laptop stickers (which you might still be able to score at a future dev event). But we’ve never really asked you, what would you find most valuable? Let us know in the comments below and maybe you’ll see it at a future event or on social.

p.s. Of course, you can always get one of these free dev t-shirts for signing up for a SparkPost account – we have women’s dev sizes as well!


This last weekend we sponsored Bitcamp, held at the University of Maryland, and in my opinion, it was one of the best hackathons we’ve ever attended!  Now would be the right time to disclose my bias: I was a Bitcamp organizer in college. So having my first experience on the other side of the sponsor booth be at my favorite hackathon, was truly special.

It was also a significant event for our Developer Advocacy team. SparkPost has sponsored small to midsized hackathons in the past, but this was our first delve into the larger student-run events, and we came prepared!

We started Friday night off by giving away tons of swag, including the limited-edition SparkPost Bitcamp stickers.

bitcamp sticker piggy pennies
SparkPost Bitcamp Stickers

These were such a hit with the hackers that we’re in the process of creating limited-edition stickers for other events! Come see us at one of our next events to get yourself one.

On Saturday, we brought in a slushy machine and served Monster Energy slushies (there was a fruit punch flavor for those who had actually slept).

slushie cups piggy pennies
Limited Edition Slushy Cups

Handing out swag and raffling off prizes is always a fun time, but what made the event really worthwhile was being able to help students with their projects. Throughout the weekend, we had six SparkPost engineers answering questions and mentoring hackers.  Nothing took me back to hackathon participant times like debugging a node.js app at 3 AM on Friday night! We even got a shout-out from one of the hackers on Twitter.

twitter piggy pennies

Whether hackers built their projects with SparkPost in mind or quickly incorporated, we got a lot of great submissions for our challenge. The deliberation was tough, but Piggy Pennies walked away as the winners of the SparkPost Challenge, with $500 in Visa gift cards. Piggy Pennies allows you to automatically round up the change of your purchases in order to save money towards a common goal with friends. The team leveraged the Capital One API (available only at hackathons) to process financial transactions, and used SparkPost Transmissions and Templates to deliver detailed updates and reports on the group’s goals. The team also implemented ways to trigger money transfers by replying to the reports using our Inbound Relay Webhooks.

bitcamp winners piggy pennies
Piggy Pennies – The Winners!

The rest of the challenge submissions were amazing too — 6 of them won major prizes from other sponsors as well. They were so cool we had to pick two honorable mentions to send to extra swag to. Contap took a new approach to the “tap phones to exchange info” concept, by automatically starting an email intro and implementing Amazon Echo Alexa reminders to contact the person. The second honorable mention was part of a surprising amount of hardware heavy submissions. Fireberry Pi used sensors and a RaspberryPi to send a warning text message including a picture of the room when gas levels were too high. This team was particularly crafty, figuring out how to use carrier email to sms gateways to send a text messages using SparkPost.

Bitcamp’s theme this year was “Explore new grounds,” and I can confidently say the SparkPost team did just that. It was a great place to meet up with such a large number of developers at varying stages of experience and skill levels. We got really valuable feedback on our product and even met a participant who had recently published a SparkPost Cake-PHP Library!. Thank you to Bitcamp for putting together such a creative atmosphere. Thank you to all the hackers, we hope to see you again soon.

Make sure to reach out to our team on Twitter or in our community Slack channel if you want to connect!