Work Experience

Before College Graduation

Earliest work experience was 4 summers (starting when I was 15) as a lifeguard. I worked at a pool the first two years and a lake the second two years. Luckily I never really had to save anyone. I just had to yell at kids for breaking rules, and clean some nasty bathrooms.

When I was 20, I did a summer fellowship in DC on K Street working for a think tank. At the time, it was a very small think tank, just two full time employees. It had a startup vibe to it, lots of potential but not a lot of initial direction. It was tough as a ‘first real job’ internship position, because of the lack of direction. I was full of energy and enthusiasm. I wanted to be pointed at a problem and told to ‘go.’ It was a fun summer, but I realized politics was not where I wanted to end up in life. The job convinced me to take programming courses my next semester at college.

I had a coding internship with Agility Feat in the summer of 2012. I was new to coding at the time so the internship was a mix of writing/research and learning code. I learned Ruby on Rails throughout the summer, and worked on getting a website up and running. I also wrote some blogs about agile development and lean startups, one of which was retweeted by Eric Ries.

I finished my degree a semester early in December 2012 from George Mason University with a B.S. in Economics and a minor in Computer Science.

After College Graduation

Software Engineer

After finishing college, I had a very brief (three week) job at a company called Sotera. The company required a clearance. Something went wrong with my initial screening process (my best guess for what went wrong is that I put down “unemployed” instead of saying “employed as a student”). They let me go. The incident gave me a strong aversion to the idea of holding a clearance or working as a government contractor.

About a month later, I found a new job and began working at Cvent as a Software Engineer. For my first project, I was put on a team that worked on a massive website redesign for one of Cvent’s main products. We used a C# MVC framework to capture the business logic of the existing pages. There was a mix of a C# service architecture and SQL stored procedures for data retrieval. Then we used custom view methods built on top of JavaScript to maintain a consistent look and feel.

The first project lasted a long time and was a tough learning process for Cvent and myself. They had switched over to using git for the new project. They started trying Agile methodologies and often failed pretty badly. I remember having a two month ‘sprint’ at one point. It was my first time on a large software project. I was learning new things every day and fighting back a strong sense of ‘impostor syndrome’ as someone with only a minor in Computer Science.

Working with remote teams in India was often a challenge as well. At the time, Cvent would often have half of a team in India and half of the team in the headquarters office (Tysons Corner, VA). Features would get stuck in long turnaround times where someone in one office was waiting for the other office to respond. Later in the project, I got an opportunity to travel to the India office for six weeks. It was a great personal experience, but also a very useful work experience. I came back with a much better understanding of the problems they faced in a remote office. 

Next, I was on a project to cleanup Cvent’s extensive .NET dependencies. I worked on a two man team with a developer from Cvent’s DevOps team. My role was somewhat of a tester. The DevOps person I worked with wrote a script for cleaning up and discovering problems with the .NET dependencies. I ran the script on different repositories, reported problems with the script, fixed dependency issues I came across, and then made a release plan. The release plan was crucial because a mistake with this project could cause hard errors and completely block our customers in the production environment.

After working on that cleanup, I moved to a separate product team at Cvent. I’d previously worked on the event planning SaaS product that Cvent had. The team I joined had a product with a search/advertising business model. Cvent was going through many changes to our tech-stack. We started using Couchbase for some of our data storage needs, Java micro-services for data retrieval, and a React front end.

I initially disliked JavaScript, because I was accustomed to strongly typed languages. However, while working in it, I really started to enjoy the process of front end development. The feedback loop is fast, I am passionate about the look and feel of websites, and front end code itself just feels … accessible.

UI Developer

After getting my feet wet with UI Development, and discovering how much I enjoyed it, I decided I wanted to switch teams. Cvent was open to me switching roles within the company, so that is what I did.

I continued working with the same product teams, but my role on the team became different. Instead of just being an individual contributor, I had a more active role in the planning process. I was the UI Developer for two teams, but also offered minor help and advice to a third team. Also, upcoming UI Dev work was heavily filtered through a Senior UI Developer and myself.

A few months after becoming a UI Developer, the Senior UI Developer I was working with switched to another product team. So for about a month, I was watching over five different sprint teams and still coding at the same time. It was a temporary situation, but I did enjoy the process of triaging the work that needed to be done.

A UI Developer and Junior UI Developer joined the team with me and the workload became much more reasonable. Since we had more breathing room, we were able to setup a good process with the designers and product owners. There was a steady stream of UI work that was getting a healthy level of scrutiny and feedback before it was being implemented. It also allowed us to start developing components that were meant for reuse both in and outside the current project.

Everything was going incredibly smoothly, but there was another product team at Cvent that was struggling from a lack of experienced UI Developers. My manager and I decided that I’d be in charge of salvaging what was happening on the other team.

I was once again a lone UI Developer with up to five teams that might ask for help or reviews. I took a similar approach as last time by setting up a steady and consistent process to provide feedback on UX designs. We altered the pull request rules on git/bitbucket so that all UI-related pull requests would automatically add me as a code reviewer. Instead of jumping around to different teams, I became embedded on just one team. I’d work with the product owners to funnel UI heavy work to my team. The situation quickly improved, and I continued working on that team for another year.

History then repeated itself and there was another project in need of an experienced UI Developer. I was switched onto that project to get it up and running smoothly. I followed the same steps I’d learned before: solid interaction and feedback for designers, control of incoming UI work, automatically getting added to any pull requests with UI, and being embedded on a sprint team to complete my own work. There was too much UI work on the project for a single person. We hired someone new, and I trained/mentored them to work on UI features for the project.

During these projects I also took on some additional responsibilities within the UI development team. I interviewed candidates, developed new hire onboarding materials, and became a web-accessibility subject matter expert.