Since we store multiple versions of messages, Sprout engineers are tasked with “recreating the world” several times a day—an essential process that requires iterating through the entire data set to consolidate every part of a social message into one “source of truth.”

For example, keeping track of a single Twitter post’s likes, comments and retweets. Historically, we have relied on self-managed Hadoop clusters to maintain and work through such large amounts of data. Each Hadoop cluster would be responsible for different parts of the Sprout platform—a practice that is relied on across the Sprout engineering team to manage big data projects, at scale.

Keys to Sprout’s big data approach

Our Hadoop ecosystem depended on Apache Hbase, a scalable and distributed NoSQL database. What makes Hbase crucial to our approach on processing big data is its ability to not only do quick range scans over entire datasets, but to also do fast, random, single record lookups.

Hbase also allows us to bulk load data and update random data so we can more easily handle messages arriving out of order or with partial updates, and other challenges that come with social media data. However, self-managed Hadoop clusters burden our Infrastructure engineers with high operational costs, including manually managing disaster recovery, cluster expansion and node management.

To help reduce the amount of time that comes from managing these systems with hundreds of terabytes of data, Sprout’s Infrastructure and Development teams came together to find a better solution than running self-managed Hadoop clusters. Our goals were to:

• Allow Sprout engineers to better build, manage, and operate large data sets
• Minimize the time investment from engineers to manually own and maintain the system
• Cut unnecessary costs of over-provisioning due to cluster expansion
• Provide better disaster recovery methods and reliability

As we evaluated alternatives to our current big data system, we strived to find a solution that easily integrated with our current processing and patterns, and would relieve the operational toil that comes with manually managing a cluster.

Evaluating new data pattern alternatives

One of the solutions our teams considered were data warehouses. Data warehouses act as a centralized store for data analysis and aggregation, but more closely resemble traditional relational databases compared to Hbase. Their data is structured, filtered and has a strict data model (i.e. having a single row for a single object).

For our use case of storing and processing social messages that have many versions of a message living side-by-side, data warehouses had an inefficient model for our needs. We were unable to adapt our existing model effectively to data warehouses, and the performance was much slower than we anticipated. Reformatting our data to adapt to the data warehouse model would require major overhead to rework in the timeline we had.

Another solution we looked into were data lakehouses. Data lakehouses expand data warehouse concepts to allow for less structured data, cheaper storage and an extra layer of security around sensitive data. While data lakehouses offered more than what data warehouses could, they were not as efficient as our current Hbase solution. Through testing our merge record and our insert and deletion processing patterns, we were unable to generate acceptable write latencies for our batch jobs.

Reducing overhead and upkeep with AWS EMR

Given what we learned about data warehousing and lakehouse solutions, we began to look into alternative tools running managed Hbase. While we decided that our current use of Hbase was effective for what we do at Sprout, we asked ourselves: “How can we run Hbase better to lower our operational burden while still maintaining our major usage patterns?”

This is when we began to evaluate Amazon’s Elastic Map Reduce (EMR) managed service for Hbase. Evaluating EMR required assessing its performance in the same way we tested data warehouses and lakehouses, such as testing data ingestion to see if it could meet our performance requirements. We also had to test data storage, high availability and disaster recovery to ensure that EMR suited our needs from an infrastructure/administrative perspective.

EMR’s features improved our current self-managed solution and enabled us to reuse our current patterns for reading, writing and running jobs the same way we did with Hbase. One of EMR’s biggest benefits is the use of the EMR File System (EMRFS), which stores data in S3 rather than on the nodes themselves.

A challenge we found was that EMR had limited high availability options, which restricted us to running multiple main nodes in a single availability zone, or one main node in multiple availability zones. This risk was mitigated by leveraging EMRFS as it provided additional fault tolerance for disaster recovery and the decoupling of data storage from compute functions. By using EMR as our solution for Hbase, we are able to improve our scalability and failure recovery, and minimize the manual intervention needed to maintain the clusters. Ultimately, we decided that EMR was the best fit for our needs.

The migration process was easily tested beforehand and executed to migrate billions of records to the new EMR clusters without any customer downtime. The new clusters showed improved performance and reduced costs by nearly 40%. To read more about how moving to EMR helped reduce infrastructure costs and improve our performance, check out Sprout Social’s case study with AWS.

What we learned

The size and scope of this project gave us, the Infrastructure Database Reliability Engineering team, the opportunity to work cross-functionally with multiple engineering teams. While it was challenging, it proved to be an incredible example of the large scale projects we can tackle at Sprout as a collaborative engineering organization. Through this project, our Infrastructure team gained a deeper understanding of how Sprout’s data is used, stored and processed, and we are more equipped to help troubleshoot future issues. We have created a common knowledge base across multiple teams that can help empower us to build the next generation of customer features.

If you’re interested in what we’re building, join our team and apply for one of our open engineering roles today.

The post Reinventing Sprout Social’s approach to big data appeared first on Sprout Social.

If you ask me the same question today, I would give a slightly different response. Software engineers are tasked with solving the right problems through code—and when solved effectively, they accomplish business goals. Figuring out which problems to solve and how to solve them is the most important part of being a developer, with the actual implementation details being secondary.

My path to software engineering

I became interested in programming after taking a class at Upperline Code the summer before my freshman year of college. I got this opportunity through a college and career readiness program that I was part of called The Opportunity Network.

Upperline Code was my first introduction to programming, and where I quickly realized I was interested in learning to code. Later that summer, I received my Notre Dame enrollment packet and switched from the College of Arts and Letters to the College of Engineering so I could major in Computer Science (CS).

Some of my favorite CS courses were Design/Analysis of Algorithms, Cloud Computing and Programming Challenges. The problems were interesting and the professors were great at presenting new ideas and explaining concepts.

Throughout undergrad, I knew that I wanted to work as a software engineer and use the technical skills that I gained. Thankfully, the summer before my senior year, I had the opportunity to intern as a software engineer at Kantata and pair-program with other engineers to help deliver features.

My internship experience, along with pep talks from my professors, gave me the confidence to not settle for any other role when I first started applying for jobs. After plenty of time spent in office hours, I graduated in 2021 with a CS degree and accepted an offer to be an Associate Software Engineer here at Sprout Social.

Settling into Sprout Social

Part of being new to the role and new to the company was having to develop both general software engineering skills and Sprout-specific domain knowledge. I found that tasks which required general programming knowledge to understand were the easiest for me to solve. However, tasks that required knowledge of Sprout’s architecture took time for me to tackle and I had to rely on my team for help. While there are some problems you can solve by reading documentation online, you can’t always find information that is relevant to the work that you’re doing—being able to ask others for guidance is crucial.

One of the first things that stood out to me when I joined Sprout was how collaborative the development process is. I knew that it took entire teams to develop features, but I didn’t know what that looked like in practice. I quickly realized that releasing a successful feature required many people in different roles working together—from product managers defining project requirements, to designers creating mockups and engineers implementing features. Collaboration wasn’t something that was optional, but a necessity in accomplishing our team’s goals.

Learning how to navigate through the various codebases and building a mental model of how different services interacted with each other was a steep learning curve. Since Sprout’s core business is software, its architecture is heavily shaped by its business requirements. As I was ramping up,  I had to be aware of the business problems developers were trying to solve and why previous architectural decisions were made.

Initially, I was a bit intimidated that pull requests required reviews before they could be merged into the codebase. Understanding that the main purpose of code reviews is knowledge sharing and maintaining code standards helped change my perspective.

Going through code reviews has helped sharpen my technical skills and improve the quality of my pull requests. Having peers give me advice on what to change, introduce me to new patterns, and point me to relevant areas of the codebase has been really helpful. Reading the pull requests of other engineers has also given me valuable visibility into other services that I am not directly working on.

Your previous experiences matter

There is a prevailing idea that as you enter new stages in life, your previous experiences no longer matter. Once you enter college, your high school experiences no longer matter. Once you enter the workforce, your college experiences no longer matter.

But something that is often overlooked is that our experiences, knowledge, and habits have a compounding effect. We usually are only able to achieve new things thanks to the work we’ve done before. The knowledge and skills that I previously gained have greatly influenced how I approach new challenges as an entry-level software engineer.

The classes during undergrad that had the most direct impact on my day-to-day work at Sprout were Programming Challenges and Database Concepts. The former taught me how to break apart large problems into smaller pieces to solve them more efficiently. It helped me become more intentional on how I structured my code and improved the readability of my code.

Database Concepts taught me fundamental relational database concepts and covered topics such as database schema design and SQL. I learned how to write queries, which has been extremely useful since I frequently need to query our databases to solve problems or answer questions.

The opportunities I had outside of the classroom were equally as valuable. Java wasn’t a language that was covered in most of my courses, however I had the opportunity to work on it for a business project that one of my professors was leading. I gained hands-on experience writing Java, working with MySQL databases and creating Docker images. Learning Java was especially helpful since most of Sprout’s services are written in it.

There are a lot of other skills that I gained over my time in undergrad that I take for granted, like navigating the command line and understanding core programming concepts. It’s a common misconception that since most of the topics covered in undergrad are theoretical in nature, they won’t prepare you for software engineering careers. However, I believe the opposite is true—the skills you learn in undergrad matter, even if they aren’t directly applicable to your day-to-day work.

Computer Science is an extremely broad field

CS covers a variety of specializations such as artificial intelligence, machine learning and data science. The experience you gain in undergrad serves as foundational knowledge that can serve you well in a variety of entry-level roles not exclusive to software engineering. Making the jump from undergrad to a full-time position provides an opportunity to explore what kind of role and specialty is the right fit for you.

If you’re looking to start a career in software engineering, Sprout’s a great place to begin.

The post Lessons learned as an entry-level software engineer appeared first on Sprout Social.

Starting my career as a woman in software engineering

How humans interact with and leverage technology has always been an interest of mine–in my adolescence, social media and smartphones began their ascent and suddenly handheld technology was everywhere. By the time I left for college, almost every teenager had a laptop and I knew I wanted to study computer science.

At the University of Michigan, engineering was a fascinating but daunting space. Almost all my peers were male and the halls were dusted with aggressions—from being labeled by a new classmate as “worthless” simply for being a woman, to worse. Asking questions or being honest sometimes felt unsafe, out of a fear of appearing ignorant or stereotypical. Taking each barrier as a challenge, I pushed to excel in my program and defy the negative expectations.

In those four years, I had only two female engineering professors—the most engaging by far, bringing the complex and intimidating specialties of machine learning and artificial intelligence into my world. With their fire as my inspiration, I joined a lab as a human-computer interaction researcher, studying the role of human biases in reinforcement learning agents. I would hold on to that momentum when I joined the workforce, seeking out strong, diverse mentorship and opportunities to grow in fast-moving spaces in all of my roles.

Sprout Social’s engineering culture

When I first heard about Sprout Social, it was a return to my passions—people and social technology. I was thrilled to join the team last summer, with an engineering squad that was nearly half women and an engineering culture that rallied around learning and growth.

In my first weeks, I found the motivation and strength of the team to be evenly matched by its humility. I was encouraged to ask questions publicly and honestly, to admit knowledge gaps without judgment, and to reach out to anyone at any level. Moments that could have been intimidating became genuine learning opportunities and my confidence grew alongside my technical skills.

An exciting early project was our partnership with TikTok, integrating the viral platform as a new social network in our suite. Designs and technical documents evolved into TikTok posts popping up in our message and calendar tools, and the effort that came between was fluid and impressive. For me, there was plenty to learn—our designs dipped into less familiar waters, from webhooks and asynchronous processing patterns to data model compatibility. Working closely with other engineers and designers (and syncing often with TikTok) I became friendly with these concepts and many more. By the time we went live, it was clear we took both our wins and losses as a team, and I found that to be true even outside of engineering.

Finding solidarity through Community Resource Groups

In our hybrid work world, I searched for spaces to build connections and relationships. Knowing the power and bond of minority communities, I joined two of our community resource groups almost immediately: Underrepresented Genders in Tech@Sprout (UGIT) & Asians@Sprout.

In our organized Slack channels and meetings, real and authentic conversations bloomed. Members in each community supported each other through both work and personal issues. Each group had at least a handful of fearless members, driving vulnerability and honesty through even the most difficult of topics: from work-related themes like burnout or promotion advice to more emotional fronts like mental health.

Even painfully relevant issues like pandemic-spurred Asian hate crimes or political threats to women’s rights were discussed and grieved in the open. It was a breath of fresh air. In a mostly virtual environment, these communities had carved out a safe space to be unapologetically yourself, and the relief that came with it was evident. I found the effects on my comfort and confidence to be far reaching, extending past our gatherings to my every day work.

I wanted to give back—to be a driving force for the communities that had taken me in, especially for other women in engineering. So in early 2022 I joined the leadership board of UGIT and have spent the last several months alongside an incredible team working to further disrupt the gender narrative in technology. We foster discussions and social initiatives aiming to empower our community and provide opportunities for learning and recognition.

Finding an organization that will give you the space to be your authentic self is rare, but you shouldn’t settle for anything less. If you’re interested in joining our team, check out our engineering careers page and apply today.

The post Vulnerability in the workplace: A career differentiator for women in software engineering appeared first on Sprout Social.

My shyness and social awkwardness have always been my Achilles’ heel, but I ended up attending Texas Tech University and found myself in a lecture hall filled with almost thirty men and one other woman. I remember my professor making a point of calling on me during class, and while he may have thought he was helping me gain more confidence, it was an extremely stressful experience. I wasn’t afraid because I didn’t know the answer, I was afraid of being wrong.

I made it through with top grades and decided that from then on, I wanted to make sure women in engineering would not have the same experience as me. I started to get more involved in outreach programs and activities that allowed me to connect with other women in engineering. Around this time, I decided to help revive our small women’s computer science group: Extraordinary Women of Computer Science (EWoCS). Being part of EWoCS helped me gain confidence in my schoolwork and empowered me to tackle a new beast: how to find a job as a software engineer.

Finding Sprout Social

As I started looking into how to get a software engineering job, I discovered that the environment of some of these companies were all too similar to what I experienced in college: all-male teams and all-male leadership. The percentage of female software engineers is small to begin with, as women made up only 14% of software engineers in 2018, and I started to question if the gender gap in engineering would ever change. I am a firm believer that diverse teams bring incredible value to both the organization and the product, and I decided to only look for companies that valued culture and diversity as much as they did technical skills.

Enter Sprout: a company whose vision and values highly align with my own. I was hired as a front-end software engineer intern on the Analytics team. Not only was there another woman in my cohort of interns, but there were more than a handful of full-time women in engineering that I got to know and connect with. 

During my internship, I was blown away by the diversity of the engineering team and the efforts the company made to maintain that. For example, Sprout holds monthly diversity, equity and inclusion (DEI) Guild meetings that focus on educating our team about different cultures, identities and societal issues. I was surprised to see the team willingly talk about topics like systemic racism and women’s rights, and after my first DEI meeting, I decided that Sprout was the place I wanted to work long-term. I was offered a full-time position as a Software Engineer in July of 2018. 

Starting a Business Resource Group

Engineers are constantly faced with complex problems that need to be broken down into smaller tasks. Even though Sprout had a more diverse team than any other company I looked at, it was not perfect—but I wanted to help change that. I knew that if I could tackle a problem as difficult as supporting women in engineering and our underrepresented community, I could apply similar learnings to my everyday work as an engineer. 

I started to get involved by joining a Slack channel aimed for women in engineering called #BarbieIsAProgrammer. We would share resources, volunteer opportunities or just chat about what we were going through as non-male tech employees. Over time, Sprout’s DEI efforts grew and with this came the emergence of Business Resource Groups (BRGs). BRGs are employee-led groups for traditionally underrepresented communities who share a common purpose, interest or background. So when applications for BRGs opened, three amazing colleagues and I decided to help turn #BarbieIsAProgrammer into an official BRG, which we called “Underrepresented Genders in Tech,” or UGIT for short.

Like the name suggests, UGIT provides a space for underrepresented genders who work in tech fields at Sprout, including engineers, designers and people from our product team. Our first goal was to raise internal awareness and build a community so that people could connect with one another and meet potential mentors. Now that we are more established, we’ve been able to host events, coordinate panels with our own engineers, participate in community outreach programs and foster an intimate and safe space for our members at monthly meetings.

One of my favorite speakers we’ve hosted to date was Natalie Kissinger, a corporate litigator, who talked to us about how to negotiate—a simple and broad topic, but one that I have personally struggled with as a female engineer. After this event, I walked away with new techniques on how to communicate effectively while sharing my thoughts and ideas in a way that I was comfortable with. It’s events like these that keep the retention in our group high, as we’re all trying to learn how we can succeed in the highly competitive tech space. 

Looking forward

Through UGIT, I have been able to meet a group of people who are eager to learn and prove to themselves, and the world, that our perspectives offer a unique point of view to the engineering field. Together we are learning how to be more confident, embrace our mistakes and reinvent the status quo for engineering as a whole. Since I started, I have seen more women, LGBTQIA+ people and other underrepresented individuals joining our company, which shows me that representation is improving bit by bit.

My advice to women and other underrepresented genders who are wondering how to get a software engineering job is simple: own it, and don’t give up. It may not be an easy road, but I guarantee that once you get involved and reach your goals, you will feel accomplished. This journey will give you the greatest experiences and lessons you can imagine that apply not only to work, but to your life in general.

If you’re interested in joining our team, check out our engineering careers page and apply today.

The post Women in engineering: How I found and started my career as a software engineer appeared first on Sprout Social.

In my three and a half years working on a small Android team at Sprout Social, one of the main things that motivates me to come into work every day is the freedom and trust from our company to tackle a problem in whatever way we deem best.

The freedom to research and explore many different solutions to a problem we deem necessary, while accounting for a timeframe to deliver on product updates, enables us to find the best solution for both our customers and our software.

One such challenge involved building a UI component for our new Mobile Reporting feature. This new component was a month picker, which allowed our users to scope a date range for an analytics report.

The starting place we picked was the existing Material Components Library. Rather than starting from scratch, this library is actively maintained and aligns with the Material specifications. With this library as a foundation, we could likely reduce the amount of logic we’d have to write ourselves.

In this article, I’ll cover how we approached this process, some unique factors in building for the Sprout Android app, a few “gotchas” that came up (and were fixed) along the way, and what to know if you’re working on a similar project.

Introduction

The Android Material Components 1.1.0 Release introduced a new Date Picker UI Component. One of the welcome additions of this new MaterialDatePicker over the AppCompat CalendarView is the ability to select a range of dates using either a Calendar View or a Text Input Field.

The old AppCompat CalendarView was not very flexible. It was a good component for the limited use case it was meant to solve; that is, selecting a single date and optional minimum and maximum dates to specify an allowed date range bound.

The new MaterialDatePicker was built with more flexibility to allow the use of expanded functionality of behavior. It works through a series of interfaces that one could implement to tweak and modify the behavior of the picker.

This behavior modification is done at runtime through a set of builder pattern functions on the MaterialDatePicker.Builder class.

This means we are able to extend the base behavior of this MaterialDatePicker through composable interface components.

Note: While there are a number of different components the MaterialDatePicker utilizes, in this article we will cover the Date Selection Component only.

Date range picker

The Sprout Social Android team was in the process of building our Analytics Reports Section.

This new section would allow our users to select a set of filters and a set of date ranges that the report would cover.

The MaterialDatePicker came with some pre-built components that we could leverage to accomplish our use case.

For our most common case, allowing a user to select a range of dates, the pre-built MaterialDatePicker would suffice:

With this code block, we get a Date Picker that allows users to select a date range.

Monthly date picker

One of the Sprout Social reports that has more unique date selection is the Twitter Trends Report.

This report differs from the others in that instead of allowing any kind of date range, it enforces a single month selection, meaning a user can only select March 2020 vs March 3 to March 16, 2020.

Our web app handles this by using a dropdown form field:

The MaterialDatePicker does not have a way to enforce such a restriction with the pre-built Material Date Range Picker discussed in the previous section. Fortunately, MaterialDatePicker was built with composable parts that allow us to expand the default behavior for our particular use case.

Date selection behavior

The MaterialDatePicker leverages a DateSelector as the interface used for the selection logic of the picker.

From the Javadoc:

“Interface for users of {@link MaterialCalendar<S>} to control how the Calendar displays and returns selections…”

You’ll notice that the MaterialDatePicker.Builder.dateRangePicker() returns a builder instance of RangeDateSelector, which we used in the example above.

This class is a pre-built selector that implements DateSelector.

Brainstorming a monthly date selection behavior

For our use case, we wanted a way to have our users select an entire month as a selected date range; e.g. May 2020, April 2020, etc.

We thought that the pre-built RangeDateSelector referenced above got us most of the way there. The component allowed a user to select a date range and enforce a [lower, upper] bound.

The only thing that was missing was a way to enforce a selection to auto-select the entire month. The default behavior of RangeDateSelector has the user select a start date and an end date.

We wanted a behavior so that when a user selects a day in the month, the picker will then auto-select the entire month as the date range.

The solution we decided on was to extend the RangeDateSelector and then override the day selection behavior to auto-select the entire month instead.

Luckily, there is a function we can override from the interface DateSelector called: select(selection: Long).

This function will be invoked when a user selects a day in the picker, with the selected day passed in UTC milliseconds from the epoch.

Implementing a monthly date selection behavior

The implementation turned out to be the simplest part, since we have a clear function we can override to get the behavior we want.

The basic logic will be this:

1. User selects a day.
2. The select() function is invoked with the selected day in a Long UTC milliseconds from the epoch.
3. Find the first and last day of the month from the given day passed to us.
4. Make a call to super.select(1st of month) & super.select(last day of month)
5. The parent behavior from RangeDateSelector should work as expected, and select the month as a date range.

Putting it all together

Now that we have our Custom MonthRangeDateSelector, we can set up our MaterialDatePicker.

To take the example further, we can process the result of the selection like so:

The result will look like this:

Gotchas

There was just one major issue that made it difficult to arrive at this solution.

The primary components used to build our MonthRangeDateSelector were the class RangeDateSelector and the interface DateSelector. The version of the library used in this article (1.2.0-beta01) restricted the visibility of these two files, to discourage extending or implementing them.

As a result, although we could successfully compile our new MonthRangeDateSelector, the compiler did show a very scary warning to discourage us from doing so:

One way to hide this compiler warning is to add a @Suppress("RestrictedApi") like so:

This experience illustrates how, even though the Material Components Library has provided some great new components to the Android Developer Community, it is still a work in progress.

A great part of this library is the openness to feedback from the Android Community! After discovering this component visibility restriction, I opened an issue on the Github Project, and even opened a PR to address it right away.

This open feedback loop between the Material Components Team and the Android Community breeds great collaboration and results for everyone.

Conclusion

The new MaterialDatePicker has some great out of the box functionality that will likely cover most use cases of date selection.

However, the best part of it over something like the AppCompat CalendarView is that it is built in a composable way. Therefore, it can be easily extended and modified for specific use cases, whereas it would be much harder to accomplish such things in the CalendarView.

Special thanks

I’d like to highlight some folks that helped peer-review this article:

• Nick Rout (Github)
• Mike Wolfson (Github)
• Ryan Phillips (LinkedIn)
• Lucas Moellers (Github)
• Mit Patel (LinkedIn)

The post Engineering at Sprout: Building an Android month picker appeared first on Sprout Social.

Justyn is a leader whose vision not only drives the growth of our business, but also inspires our team to do and be better each day. He is committed to a culture of openness and has worked tirelessly alongside our executives to create a workplace where team members are empowered to share their ideas, work collaboratively and embrace the diverse qualities and characteristics that make each employee unique. This has helped Sprout to maintain a close-knit, yet scalable culture that has developed organically over time.

“Being named to this list for a second year is a true honor and I am grateful to the team for their steadfast belief in our vision for the business and product,” Howard said. “I’m as excited about Sprout’s future as I was eight years ago when we started, and that is due in no small part to the nearly 500 team members that show up ready to tackle the toughest problems in the industry each day, while continuing to provide great value for our customers.”

So, what are employees saying on Glassdoor about leadership at Sprout?

“I have never worked with a more hard working, talented group of people! I look forward to coming to work every morning. It all starts with the leaders at the top who have been a consistent group from the very beginning.”

Anonymous Employee

“Sprout continues to foster a collaborative workplace. There’s tremendous opportunity to make an impact as leadership encourages feedback to shape company goals and processes. Sprout is routinely recognized as a best place to work for good reason.”

Account Manager

CEO approval ratings are gathered through Glassdoor’s online company review survey, which gathers current and former employee sentiment about job and company satisfaction, the work environment and the culture. Among the 770,000 companies reviewed on Glassdoor, the average CEO approval rating is 69%.

We are thankful to our team members who have taken the time to share their experiences on Glassdoor. And more than ever, we are proud to have a leader who is fiercely dedicated to team and customer success.

Want to join Team Sprout? We’re hiring.

The post Sprout Social’s Justyn Howard Named a Glassdoor Top CEO for Second Year in a Row appeared first on Sprout Social.

Since joining Sprout in February 2017, Shweta has used her time here to not only grow in her career, but also take on new personal challenges. She is now a city organizer for Tech Ladies Chicago, has attended her first engineering conference and is building her experience as a speaker on topics that impact women of color and women in technology. Shweta has so many fascinating stories to share and I’ve captured just a few of them below.

Name: Shweta Kapur
Department: Engineering
Started at Sprout: February 2017

What is your role at Sprout Social and can you explain what you do in one sentence?
I’m a Senior Software Engineer on the Data Ingest squad. It is difficult to boil down what I do in one sentence, but I’ll give it a shot. I am responsible for gathering data from the social networks (Facebook, Twitter, Instagram, LinkedIn and Google+) and importing it into Sprout’s platform so our customers have the data they need to view and engage with social messages.

Before we jump further into what you do, can you share a fun fact about yourself so we can get to know you a little better?
I am both a mechanical and software engineer. While I have been programming since I was a young child, it was the Mechanical and Automation Engineering program in college that initially grabbed my interest. Courses taught me about everything from engines and turbines to mechatronics and robotics. However, following an internship at a railways workshop, I realized my true passion was to be a software engineer.

I still received my undergraduate degree in Mechanical Engineering, but went back for a Master’s degree in Computer Science, and ultimately took my first job out of college with a software firm.

Now switching back to work, what is one aspect of your job that is unique to your role or department?
Our engineering department generally consists of squads that focus on different pillars of the Sprout product. This includes engagement, publishing and analytics. The Data Ingest squad is unique because we are not focused on a specific pillar, but rather touch every aspect of the platform.

Ultimately, for everyone else to do their jobs, we first need to ensure they have the right data. This means my role comes with a lot of responsibility and dependencies. I need to anticipate needs and stay in constant communication with other teams to ensure I am providing the most value.

What is one of you or your team’s greatest successes from the past year?
In late 2017, Facebook changed the format for private message identifiers, which impacted how different squads were going to be able to access that data within the Sprout platform. Albeit, a small change in theory, this presented a huge challenge as it required us to not only adjust how we were going to pull in future Facebook private message data, but also how we were going to retroactively update historical data to match the new identifier format.

Most importantly, the end goal was to ensure that there would be no loss of data and little to no impact to our customers as we migrated the identifiers behind the scene.

The entire project took almost three months to complete and it touched almost every aspect within the Sprout platform. While we ran into obstacles throughout the process, our cross-squad team was able to work through them all and successfully make the switch. What was most rewarding about the project was that with more than 30,000 customers, we only received one support ticket in response to the change.

What is currently at the top of your bucket list?
Traveling to Ireland. I don’t know exactly where this desire came from, but I think the scenery is absolutely beautiful and, of course, who doesn’t want to drink Baileys in Ireland. Plus, if you turn the Indian flag clockwise and remove the chakra, it is almost a replica of the Irish flag, so I’m convinced that may have something to do with it.

Do you use any specific tools or have a routine that helps you stay productive?
As a team, we practice agile engineering using Jira, a project tracking software developed by Atlassian. Within this methodology, we work in two week sprints and focus our time and efforts on priority projects that align with our goals. This allows us, as a team, to more efficiently and effectively delegate our time to priority tasks.

Personally, I use a task management app called OmniFocus. I always have so many ideas floating around my head and by using OmniFocus I can pretty much do a braindump and quickly capture and classify my thoughts in one place. It helps me organize and prioritize without having to keep it all in my head, which also frees up space for me to concentrate on what project is in front of me.

Do you work at a standing desk or seated desk? Why?
Seated desk. I find it harder to concentrate when I am standing. I also do a lot of pair programming, which is when you partner up with another team member and sit together to tackle a problem as opposed to doing it on your own. This requires a lot of back and forth conversation as well as two screens so seated desks are typically the preference among myself and my colleagues for this type of work.

Lightning round! Answer the following with whatever comes to mind first.

Q: Favorite movie?

A: Guardians of the Galaxy

Q: Go-to karaoke song?

A: I stay far away from karaoke

Q: Favorite social platform?

A: Pinterest

Q: Salty or sweet?

A: Definitely sweet

The post Meet Team Sprout: Shweta, Senior Software Engineer appeared first on Sprout Social.

Nearly every application you will work on requires the use of time in some way, meaning that at some point you’re going to have to collect, store, retrieve and display dates or times. There’s no silver bullet for dealing with dates or times and you can never escape the inherent complexity that comes with our concept of time, but there are steps you can take to make it less of a pain.

In the years that I’ve been working with time across different programming languages, I’ve found the following knowledge goes a long way.

Choosing the Right Data Format

The first step when working with times and dates is to choose a representation for your data. While different formats may seem more or less the same, the format you choose will have a large impact on how you write and debug your code.

Using a numeric timestamp when you need a date will mean parsing the date timestamp and retrieving the date from that, which may or may not be straightforward depending on the time zone.

Using a custom string to represent a span of time seems easy to store and manipulate, but it’s difficult to query. Additionally, using any kind of representation that isn’t immediately recognizable by the human eye is going to make debugging your code more difficult.

When choosing a format for dates or times, I abide by the following rules:

1. Never use numeric timestamps. They’re often the easiest to obtain by standard libraries among various programming languages but they’re not human readable and the temptation to manipulate them is too strong.
2. Abide by ISO 8601, a standard that defines a format for date and time-related data. It’s trivial to find a library for any language that can handle the variations of ISO 8601.
3. ISO 8601 is a standard, but it has many variations. You should always choose the most human-readable variant of ISO 8601. This requires no extra effort but makes debugging easier.
4. Your timestamp string should only contain data you absolutely need. When working with times your string should not contain a date and when working with a date that is time zone-agnostic your string should not contain a time zone. Adding extra information adds ambiguity to the parsing operation and to the intent of the data for future developers
5. When storing time zones always normalize to the same time zone in your timestamps. This not only makes it easier for a computer to sort and process the data but it makes it easier for a human developer as well.

Abiding by these rules won’t cost you much up front but they will make your life easier when your application is established and you find that your usage of times and dates isn’t what you expected.

Choosing the Right Tool

As with most problems in our industry, time and date handling comes down to picking the right tool for the job.

It’s tempting to use the tools in your favorite language’s standard library, but that might not be the best choice. While some standard libraries have fantastic date and time features (Python), others are downright pitiful (Javascript). Using the wrong tool makes it that much more difficult to develop features based around time and that makes it easier for bugs to slip into your application.

A good library for handling dates and times will allow you to follow the 5 rules mentioned above. Specifically, it should be able to:

• Parse any date representation you may run into (including external representations.)
• Output to any date representation you may need (including external representations.)
• Manipulate dates and times by adding or subtracting units of time from them.
• Compare dates and times.
• Correctly convert between time zones.

It’s important that your library supports these features, otherwise the temptation to try to implement the functionality yourself will be too high. And just to be clear, if you try to implement any of that functionality yourself, you will fail.

Don’t parse your own timestamps with regular expressions, don’t add seconds to a numeric timestamp because it seems like a normal number and don’t compare dates and times using the equality operator. These libraries exist because these problems are hard to solve and reinventing the wheel in your application is just going to leave you with a broken wheel.

Below I have a few suggestions for libraries that fit these criteria:

If your language isn’t listed (because I’m not familiar enough with it) just search for <language> date and time library. Chances are you’ll find a good library that will do everything you need.

Knowing About Time

The final bit of knowledge I have to share isn’t specific to working with dates and times, but is more of a general philosophy to help us avoid problems and it applies to date and time handling as much as it does every other problem in programming.

Always check your assumptions.

We approach every problem presented with a large body of knowledge and an even larger body of assumptions. When handling dates and times it’s more important than ever to check your assumptions to ensure that they still hold for your scenario.

This list, titled Falsehoods Programmers Believe About Time, gives many excellent examples that illustrate time probably isn’t what you thought. When you’re designing or developing a feature that centers around time I encourage you to grab a partner and go through this list ensuring that you’ve avoided the pitfalls listed.

Time bugs are notoriously difficult to catch and even more difficult to test for. If you develop with this list in mind you may be able to avoid subtle bugs that would affect your customers but that they might not catch (the worst kind of bug!)

Time Zones

No discussion about times or dates would be complete without mention of time zones. In addition to familiarizing yourself with the common falsehoods listed above, also familiarize yourself with the basics of time zones.

Time zones will consistently be a pain point when working with time, even if you think you have them “all figured out”. Having a bit of knowledge about time zones will help you center your thinking and help ensure that you don’t make any logic errors when manipulating times.

Unfortunately there is no way to completely avoid the difficulty of storing and manipulating times and dates when programming. But if you follow these steps and work with this knowledge in mind, you can make the task easier by cutting down on the amount of code you have to write and forcing yourself into paradigms that are less likely to cause issues.

The post Working with dates & times in your application appeared first on Sprout Social.

Working with these teams, we’ve noted a few of the ways that team members become beloved assets to their squads. As we strive to create a merit-based culture, we pay close attention to individuals who go beyond offering empty gestures and take the steps to reaching solutions.

So what are some key differences that separate these folks from others? “They are helpful” is the obvious answer, but there can be a lot of nuance around “being helpful.”

To explain this, we’ve defined a spectrum of five levels to being helpful:

Level 1: Have Fun With That

Struggling teammate: This project is killing me. It’s way harder than I thought.
Bad teammate: Have fun with that.

The lowest level on our spectrum is responding to any team member needing assistance with cynicism. There’s a small amount of humor and sympathy shared, but ultimately it’s more important to offer a solution rather than leave them hanging with a feeling of futility.

Level 2: Let Me Know How I Can Help

Struggling teammate: This project is killing me. It’s way harder than I thought.
Mediocre teammate: Wow, interesting. Well, let me know how I can help.

Hearing folks say “let me know how I can help” to their peers is common, yet counterintuitive as it’s not actually helpful. That’s why this ranks low on our spectrum.

Although it feels productive to say to a coworker, “let me know how I can help,” in actuality you’re resigning to the low-probability they will take you up on it.

Some may say this as a genuine offer, but we’ve observed that it’s more often used as an empty gesture. It’s rare that this type of response is followed up and therefore not the most useful way to approach a struggling team member.

Level 3: What Can I Do to Help?

Struggling teammate: This project is killing me. It’s way harder than I thought.
OK teammate: Wow, interesting. What can I do to help?
Struggling teammate: Hmm. Thanks for asking. Maybe you can pair with me later to look at it together?

At first glance, this offer seems the same as the previous. However, the subtle wording adjustment and framing it as a question makes all the difference.

The question demonstrates genuine desire to help and seek information about how to actively help in the moment. Many team members will consider this question seriously and answer honestly.

That said, this is still not what we’d consider the ideal way to help your team. Many find it difficult to articulate how exactly they can be helped.

Level 4: “What If I ______ (Fill in the Blank)?

Struggling teammate: This project is killing me. It’s way harder than I thought.
Great teammate: I see. What if I took part of the project on for you?
Struggling teammate: That’d be awesome! You’re the best.

On the high end of our “helping your team” spectrum is offering a team member a specific way you can help them.

Let’s compare this method with the “let me know how I can help” from No. 2. The problem with saying “let me know how I can help” is that it leaves the burden of figuring out the best course of action on the individual that needs the help. They already have a lot on their plate, yet you’re asking them to figure out how you can get involved, which presents an additional effort to them.

In job interviews, there is a success principle: It’s not the company’s job to figure out how the candidate (i.e. you) may be a fit to the company based on your skills. Instead, it’s the candidate’s responsibility to figure out how you fit what the company needs and what problems the company is trying to solve.

If you’re interested in being viewed as a great asset to your team, take the initiative to figure out how you can help.

Level 5: Just Help, Without Seeking Recognition, Credit or Even Explicit Permission

Ideal teammate: You recognize a teammate is struggling with a project and proactively help push it forward.

We discussed how the previous method seeks permission and therefore causes cognitive burden to the person that needs help.

At Sprout Social, we sometimes use a metaphor, “mopping the floor when no one is watching,” to describe folks that help behind the scenes. We consider the pinnacle of helping your team as doing so “behind the scenes”—observing and empathizing with team members that need help, figuring out ways to be helpful and actively taking the steps to reach a solution. Learn more about careers at Sprout.

The post Becoming a beloved team member: Taking the initiative to be helpful appeared first on Sprout Social.

My choice to switch directions from doctor to engineer is one that has been extremely rewarding, but certainly not without its difficulties. Similar to most women in the industry, or really women in general, I would love to say the experiences that led me here were challenging in all the right ways, but as most of us know that isn’t the truth.

Being a woman in technology can be overwhelming and intimidating, especially when you are new to the workforce or starting a new position. While this is understandable considering only 18% of undergraduate computer science degrees and 26% of computing jobs are held by women, it should not be acceptable.

More often than not, I have found myself being the only woman in a class, meeting or even on a team, which has led me to look for opportunities that provide supporting and engaging environments for women. This is one of the reasons I feel so fortunate to work at Sprout. Everyday I am reminded of the commitment Sprout has to beat the industry standards and create a workplace where women, and people from all backgrounds, feel welcome.

One way I have seen this come to light is through an opportunity I had this past summer to mentor a young woman, Gwyn, who joined Sprout’s engineering team as an intern. Having experienced first hand the benefits of having a female mentor during my summer internship in college, I was thrilled to serve as a mentor for Gwyn and proud of my company for seeing the benefits of providing this type of resource to her.

My goal for the mentorship was to help relieve the uneasiness of being on a primarily male team, support Gwyn in her career journey and be a role model. Throughout the summer we got together weekly to discuss any questions or concerns, share a glimpse into what we were each working on and talk about life outside the office. After every meeting I was reminded about the power mentorship can have on encouraging and keeping women in technology. I still reflect on and appreciate the wealth of knowledge I gained during my mentorship in college. Not to mention, having a strong mentor was a large factor in my decision to accept a full time offer from that company.

In both of my mentorships I have been lucky enough to build professional relationships, as well as friendships and I look forward to seeing how increased access to mentorships like these will impact the industry in the future.

The post Empowering women in tech through mentorship appeared first on Sprout Social.