Become a SparkPost Engineering Intern

An internship opportunity can be incredibly valuable to your growth and career. Landing a cool internship can be one of the most important steps you take as you prepare to enter the workforce. There are many reasons why working at SparkPost as an Engineering intern is a fantastic idea! Here are the top 5:

Work on real technology

An internship at SparkPost means you get to work on the exact same crucial projects our full-time developers and engineers are working on. You gain the experience and knowledge you’ll need to rely on as you enter the workforce. You get exposed to things you can’t learn in the classroom. Additionally, you get to see your hard work directly in our products. Sounds great, doesn’t it? Learn more about the cool stuff we’re working on!

Leads to full-time opportunities!

The opportunity to gain the hands–on experience is essential but there’s the added bonus of building a network. You can create a strong referral network which is priceless. Not only can you use the real world experience that you developed, but you also have the opportunity to impress those around you that can attest to your stellar skills! In fact, several of our interns have transitioned to full-time roles at SparkPost! Read where some of our previous interns have landed in this blog post.

Work with awesome people

At SparkPost, we have smart, passionate people that really enjoy what they do. You get to work side-by-side with mentors and learn on a daily basis. Have a question or want to learn more? Our small environment empowers you to learn from the smartest minds in the industry.

Hackathons!

We host two internal hackathons a year and our interns get in on the fun! You get your creative juices flowing while working with other engineers to develop fun and interesting ideas. You may even see your idea implemented in a future SparkPost release!

The Perks!

Pizza, ping pong and all the snacks you can eat? Yes, please! We like to keep things fun here at SparkPost. We work hard but our culture promotes the little things that make working at SparkPost fun! Read about our intern culture.

“I love the openness and culture. There’s a huge focus on communication. I’ve been given work that challenges me but nothing that I can’t handle. Even when I’ve run into issues I can ask my fellow interns or any of the employees for help. It has been such a fun learning experience – I really couldn’t ask for anything better.”
–Avi Goldman, former intern, now a Software Engineer at SparkPost

And finally, engineering interns aren’t having all the fun! Other areas of SparkPost also offer exciting internship opportunities. You can check out our Marketing intern’s journey here as an example.

We’re also currently hiring for Summer Engineering Interns! If interested, you can apply here!

-Jayne Tanton

Other questions around working for SparkPost or on becoming an Engineering intern? Don’t hesitate to reach out to our recruiting team directly.

George Schlossnagle software architect, co-founder

George Schlossnagle is a pretty smart guy, though he’s too self-deprecating to really want me to say so. But there’s no question that he’s been a major force in the way SparkPost—in fact, the entire industry of high-performance email delivery—has developed over the years. He co-founded Message Systems in the late 1990s to develop a remarkably scalable email infrastructure that has grown and evolved to serve as a key element of SparkPost’s stack today. Not only is the Momentum MTA core to the SparkPost service, but it’s also essential to the in-house infrastructure at the largest mailers like social networks, ISPs, financial services, and publishers. Momentum and SparkPost together carry more than 25% of the world’s non-spam email. So, yeah, George knows something about architecting software and services that scale really well.

What does it mean to design and architect software services at scale in the cloud? I recently asked George to share some of his perspective about the role of a software architect and how it compares to other aspects of coding and building software. Here’s what he said.

How do you define your mission as a cloud software architect? What are you trying to accomplish? What motivates you in this role?

In the simplest view, I look at my job as ensuring we design and build software to not only service the requirements we have today, but that puts us into a good place to execute on the requirements that might come tomorrow. The forward-looking part of the role is probably the most difficult—ensuring that the technology and design choices we make are not only good for the problem they’re aimed at but that they interoperate with all the other portions of the architecture and are likely to remain good choices as the architecture evolves.

What motivates me is a desire to build functional software that allows us to adapt to changes in the market and changes in how our users want to use it. I’ve been building parts of this software stack for almost 20 years, and being able to gracefully evolve to handle new requirements is the key to long-term success. Many (most?) individual technology choices end up getting reevaluated every 3–5 years, and it’s setting yourself up to manage those inevitable transitions whilst still providing a stable and reliable service that’s the exciting (and necessary) challenge.

You also happen to be a co-founder of our company, so you might have a particular understanding of how technology and business goals go together. How do you see the relationship between technical goals and business goals?

I think they’re intrinsically linked. The business being successful is what allows us to continue to innovate, and innovation is what allows the business to be successful. I can’t imagine how we could be successful as a business if our technology goals didn’t directly support our business goals.

“Ahead of its time” and “vaporware” are two great monikers for failures driven by those goals being out of sync.

Does having a software architect’s mindset affect how you approach non-technical challenges, whether in the business or elsewhere?

To the extent that an architect’s job is to look at the big picture and plan for that, yes.

Have you always been a technologist in your career? Did you begin work as a programmer?

I studied to be a mathematician and began my professional career as a systems administrator. That led me into web and database performance work, and I became heavily involved in the PHP internals community, helping build an open source compiler cache for the language. From there I helped found a scalability-focused consulting company, OmniTI, which ultimately led to where I am today.

That path gave me a real appreciation for how software runs in the real world, the impact of design choices on operability and reliability and the importance of getting actionable telemetry out of your products.

What’s difference between being a programmer and a software architect? (Or, for that matter, an engineering manager and an architect?)

Being an architect is about setting a technical strategy while a programmer is fundamentally a tactical role. As an architect, you need to ensure that all of your choices and designs come together in a cohesive way that will grow over time and adapt to future challenges. A good programmer has their focus on making the individual parts as solid as possible. While there’s often some overlap, these are independent roles and both challenging in their own right.

Engineering management is distinct from both of them. Management is the art of achieving through others; of getting a group of people to all align their activities towards a common goal. It’s faddish to diminish the contribution of managers, but a good manager can really drive the productivity of teams and it is a tremendously difficult skill. People are always the hardest part of any business—navigating personalities, egos, strengths, and weaknesses.

Looking back, what’s the moment in your career you realized this was the right role for you?

Throughout my career I’ve always been interested in how things come together to form a cohesive whole. Seeing how all of the technologies fit together to solve our business issues has always been really exciting to me.

What are you working on right now?

We are moving to the next generation of our cloud architecture now, and that’s an effort that’s spanned most of the development group here. I’ve also been active in driving a lot of our compliance technology (trying to keep malicious and unwanted users from exploiting our platform).

What’s your most important tool?

My most important asset is a phenomenal team of great people who have a great understanding of all the technologies we have. Being able to leverage that group to make informed decisions is awesome.

You’ve designed on-premises and cloud technology products. What’s been the most startling difference between architecting for the cloud instead of a more traditional, packaged software product?

I don’t know that there’s anything particularly startling. The biggest non-startling difference between architecting for the cloud is that it flips many of the traditional challenges of release software on its head. In an on-premises world, you have to be extremely conservative about quality control, because when you release a version into the wild it becomes its own entity and you cannot force your customers to upgrade. When you control the entire deployment cycle yourself, you can iterate much faster because you can instantly (and globally) roll back from any issues. This allows for a feature velocity that is tremendously larger than on-premises software.

What’s a misunderstanding about software architecture you wish you could dispel?

I think the (false) notion of hierarchy is a common misunderstanding. Recognizing that the best architect may not be the best programmer (I’m certainly not), or that great programmers may not be great architects. They’re different skill sets and reinforce rather than eclipse each other.

What should I have asked you that I didn’t?

You were pretty thorough. 🙂

 

I hope you enjoyed this window into how one of the principal architects of SparkPost sees his profession. The thoughtfulness with which George describes his point of view as a software architect and builder doesn’t surprise me at all—in my experience, it’s a hallmark of how George approaches most aspects of work and communication.

—Brent
@brentsleeper

 

we love developers

April was a great month for Message Systems as the company launched its first ever Message Systems Hackathon!

The Message Systems Hackathon marked the start of a quarterly initiative to allow engineers, project managers and business analysts to team up and let their creative juices flow.

From extending the capabilities of a current product to developing a brand new product, no project was off limits. Winning projects would potentially be considered for inclusion in brand new product launches or updates – a great opportunity for teams to make a meaningful contribution to the company and achieve a memorable career highlight! Teams were encouraged to:

  • Write something from scratch
  • Build off Message Systems existing code base
  • Incorporate open source or trial version of commercial software
  • Create a new tool or improve an existing one
  • Use a new or familiar programming language

The only caveat was the honor code that teams had to observe, which was that projects had to start from scratch and no pre-coding was allowed!

The day started at 10am, where teams with custom made Hackathon shirts grabbed cups of aromatic coffee and doughnuts to kickstart their day, while Message Systems CEO, George Schlossnagle gave a brief introduction to the Hackathon.

The hard work commenced soon after and continued to the next day, as teams collaborated on their various projects until the hour of judgment…

Hackathon-20130423-529

The panel of judges included CEO George Schlossnagle, Project Manager Laura Rose and General Counsel & VP Joal Barbehenn. Up for grabs? Branded gear for winners and runner ups. The winning team would also get tickets to the Interact user conference in San Diego and be awarded with a mega trophy. All in all it was a pretty tense moment for the teams…

Hackathon-20130423-539

And so without further ado, the big winners of the day were:

First Place: Team Bazinga

Hackathon-20130423-540

Julie Zhao, Senior Software Engineer
Jun Chen, Software Engineer
Prashantkumar Dhotre, Senior Software Engineer

Runner Up: Team Radiate This!
Andrew Winder, Software Engineer
Chris McFadden, Director, Software Development – Applications
Chris Broome, Software Engineer

Runner Up: Team We don’t need no stinkin Java
Damian Danowski, VP Engineering
Jessica Martin, Software Engineer
Karan Singh, Software Engineer

The day concluded with a happy hour, where teams basked in the glory of the successful completion of their projects, and the first ever Message Systems hackathon!

Our talented engineering teams work on the product that drives 20% of the world’s legitimate email. Find out more about why major brands choose to use Momentum software.

Blog_Ads_TEI-Momentum_100413