RaiseMe: An Intern’s Reflection

I remember I first heard about RaiseMe’s Full Stack Engineering Intern position from a post in one of my school’s job search Facebook groups. I initially reached out because the post mentioned Ruby on Rails, which I had just learned, but by the time I applied I had fallen in love with the mission: to expand access to higher education so that every student has a shot at the American Dream. Several months later, I am excited to be working on furthering that mission and making a difference!

Meeting the Team

My first few days here were a whirlwind of names, faces, and coffees. Everyone in the office was so friendly, and they all paused their work to introduce themselves to me. I met people on every team and started learning about what they do from my first day here. During my first lunch, a group of people gathered on the couches to eat and talk. I was pleasantly surprised by how interesting and random the discussions were, ranging from asking about Luke’s new house to a philosophical debate about weighing survival against morality when stranded on a boat. They were open to new ideas in their conversation and it made me feel engaged and welcomed into the company. 💖

My favorite part was getting coffee with everyone over the course of the first few weeks. I talked to Dan and Anisha about product managing, and they were able to give me insight into what they do on a regular basis. As someone who’s interested in being a product manager, these conversations were very educational and fascinating. I got coffee with everyone on my team and several people from other teams. Mark and I discussed solving cool problems over boba, and Ian and I debated football as we sipped our kombuchas. The only downside: I didn’t realize that “getting coffee” with someone didn’t necessarily entail drinking caffeine, so I was jittery all day from sometimes having three coffees in one day! ☕☕☕

Learning

One thing that simultaneously excited and surprised me was how much I learned throughout the process of setting up my development environment. On my very first day, Kat (my onboarding buddy) introduced me to the technology stack that we use and all of the considerations that had gone into choices like MongoDB over PostgreSQL. The projects that I had done in school were small enough that I didn’t have to worry about scaling or using microservices and APIs. I learned about how engineers work on a large shared code base, the differences between relational and non-relational databases, and how a variety of services are used.

I wrote a lot of notes to try and remember everything!

Kat was super helpful and patient with me while I did my best to process the deluge of information. Her “pop quizzes” helped me understand what I knew and didn’t know–something that would have been more difficult to discover on my own. Every day, she would add questions to a Google doc for me to use as review (30+ in the first day alone! 😱), which I found very useful. Throughout the next few weeks, Kat continued to answer my questions, fill in gaps in my understanding, and help me through the onboarding process. I think that having an onboarding buddy–a full time engineer who was responsible for checking in with me and showing me the ropes–made a huge difference in my experience at RaiseMe, and I’m super grateful to have a great buddy! 💕

Kat! 🐱

In addition, Dan’s product demo on my first day gave me an overview of the website and what I would be working with. As he walked me through the RaiseMe website from different user perspectives, I was amazed at the level of detail and careful decision making that had gone into factors that I generally wouldn’t notice when using websites. For example, certain components are strategically placed to introduce students to RaiseMe partner colleges or encourage a sense of accomplishment when a student is awarded a scholarship. Additionally, I like the company’s commitment to accessibility. All of the text has a color contrast ratio greater than 4.5 to make it accessible for the vision impaired, media items have aria labels for screen readers, and the color cards were redesigned to have a high contrast ratio.

Accessible? ✅

My very first assignment was to improve logging in the Go server using Golang, a language that was completely new to me. Even though I was intimidated, I was able to complete the task with the help of other engineers (and Google)!

Purple text makes debugging typeaheads easier 😊

I also wrote code that was focused on improving the user experience by fixing styling. For example, I made sure a dropdown menu is aligned and changed text colors to match the style guide.

Before:

After:

These assignments offered me a gradual introduction to the code base and helped me get used to making pull requests. I also worked on more complicated tasks like changing the student sign up page to conform to European GDPR regulations, which was challenging and exciting!

Adding these checkboxes involved both the front and back end!

I think that my introduction to the company was absolutely perfect and I’m looking forward to the rest of the summer! 💯🌞

2532933019

Written by Christine Tran (christine@raise.me).

When I was job searching during my senior year of college, Raise.me was the only startup that I reached out to that didn’t have a specific opening for new graduates. I reached out because I felt so strongly about the mission, and the company has proved to be special. My six month anniversary at Raise.me is coming up, and I wanted to reflect back on my very first month here and talk about some standout moments.

The Coffees

During my first two weeks I was scheduled for coffees with almost everyone on the team, including the founders. It was a great way to meet all of my co-workers while also getting a better grasp of the area where the office is located. Each coffee trip varied depending on the person. Sometimes we talked about their role at the company, while other coffee trips were more focused on getting to know each other. These trips really differentiated Raise.me from other companies for me because all of my co-workers took time out of their schedules to talk to a newbie. I also discovered chai tea was not my favorite thing in the world.

The Projects

Turns out startups allow for a lot of growth very quickly, but that agility means there is also less structure in place for onboarding and ramping up. For new graduates adjusting to life after school, trying to learn new technology, and also coming to a new company, a proper onboarding experience is extremely beneficial. However, I wanted to learn a lot and I wanted to learn it quickly and Raise.me did not disappoint.

My first couple of days were spent setting up my development environment, and tackling various bugs. After a week or two I got my first big project: categorizing extracurricular activities with another engineer Graeme. That project is exactly as it sounds, we were to look over the extracurriculars that students had entered on Raise.me and consolidate them.  The capstone of the project was a new component on the student portfolio page that associated the extracurricular the student entered with a category.  This project ended up being blocked by other frontend updates, which was perfect timing because I was about to experience my first janitor week.

At Raise.me, engineers rotate between two roles, developer and janitor*.  When an engineer is in the developer role they are working on sprint items and features, while an engineer in the janitor role works on tasks related to colleges such as launching new ones, creating scholarships, as well as fixing bugs.  The janitor role rotates through the team and lasts one week, which is half of a sprint.

As I experienced my first janitor week, I lucked out quite a bit since I only had to deal with launching one college program.  After that, I spent the majority of my time fixing bugs which was a great way to familiarize myself with various areas of Raise.me’s codebase.  I even got a shout out during All-Hands from our product manager for squashing a bunch of bugs that past week!  All-Hands is a team-wide gathering where we all go around and say something we are excited, thankful, or grateful for for the past week.

Once I was off of janitor duty, I was given a new task to work on, which was to create and implement an experimentation framework so that we could have data-driven development. This was my first big project where I was involved in design, implementation, and testing with an A/A test to make sure that our framework did not introduce bias. I paired with Dani and Graeme on this project, but was working solo towards the end as the pairing became more hands-off. The experimentation framework passed the A/A test, and so Raise.me was ready to launch its first A/B test with a proper framework.

That A/B test was my next project. I was to implement a different homepage and signup flow to see if it performed better than the current flow.  For this project I got to work closely with Dani, who helped answer any JavaScript related questions I had. I also worked with our designer Marv, to make sure that the new homepage was pixel perfect.  It was awesome to work on such a big project so early, and have such an incredibly helpful team with me every step of the way.  By the end of my first month the signup flow A/B test was in production and collecting participants.

* Since then, Raise.me’s engineers have broken out into different squads that focus on a particular part of the product: Student Success, Student Growth, Partner Success, and Educator Success. We no longer have developer and janitor weeks.

The Team

I started working at Raise.me on August 1st and my birthday was on August 4th.  I hadn’t mentioned it at all that day, but sometime in the afternoon I remember just doing some work at the tall center table, and then looking over and seeing the whole team approaching with a chocolate cake and singing Happy Birthday. I think that was a wonderful example of just how thoughtful and welcoming the team is.

Since my first month at Raise.me, a lot has changed. I’m a part of the Student Success Squad now where I get to be more involved in brainstorming and research for the features that I will end up implementing. Things move fast here, which I believe has given me the opportunity to learn a lot more than I would’ve elsewhere.

 

7183729403

Our tech stack is RESTful

Back in 2014, RaiseMe was a classic Ruby on Rails monolith, with MongoDB as the database. In 2016, we still mostly write code in Ruby, but we’ve also built some functionality in more efficient microservices, and have added two new database technologies.

While this post won’t detail every piece of technology that we use at RaiseMe, we describe the core parts of our technology stack that our engineers interact with on a daily basis.

How We Choose Technologies

At RaiseMe, we balance choosing the right technology for the job with minimizing operational burden. Operational burden is the effort that it takes to do something in the development environment – e.g. what it takes to deploy to production, or how long it takes for a new member to learn a technology.

Some technologies like Ruby on Rails decrease this burden by having a large community that documents conventions that work well across many use-cases. Other technologies like Golang are powerful but small enough that engineers can learn them quickly. These are the kinds of technologies we prefer.

Backend Technologies

Ruby on Rails

By far the largest part of our tech stack is Ruby on Rails, which (as of October 2016) comprises 60% of all the code in our codebase.

Language Breakdown

We follow community standards for Rails development, following RESTful design when possible. We use RuboCop and Hound CI to enforce style conventions, which keeps our code clean and concise.

HoundCI
HoundCI reminds us about style conventions, so that engineers can focus on more important aspects of code review

Sidekiq on JRuby

JRuby is an implementation of Ruby in Java. Using JRuby allows us to take better advantage of parallel processing, because Java is multithreaded. JRuby also provides another performance benefit, in that the code is compiled into bytecode and runs on the JVM.

We have a clone of our Rails app that we run using JRuby, for some features that need to run asynchronously. Cloning the app to run in JRuby was the quickest way to reference all of the models and functionality we’ve built so far in Ruby, but still get the performance increases and multithreading that Java provides. We use Sidekiq to orchestrate which functions run using the JRuby version of the codebase.

Golang (Go)

gopherWe chose Go because it allows us to write efficient, large-scale programs that compile very quickly and run on distributed computers. Go is also a small language, which makes it quick to learn – new engineers on the team can be productive in Go within a week or two.

We write microservices for high-throughput features in Go, such as messaging and typeaheads, where the main tasks are transforming strings of text and interacting with other services concurrently.

Node.js

We use node.js for a small but critical service: our in-app notifications. We establish a bidirectional socket connection between the client (web browser) and this service, and use it to push notifications to a user’s browser. For example, when a student receives a new scholarship we immediately push a notification to their browser through this service and its connection to the client.

We send notifications to the student's browser whenever they get a new microscholarship
We send notifications to the student’s browser whenever they get a new microscholarship!

Java

We use Java, running the Spark web framework, to create a minimal service for connecting to our Redshift Database. We use this service to query event logs, which we do whenever we send emails to college partners displaying their weekly updates and progress.

Frontend Technologies

Backbone.js

Most of the frontend code in our system is implemented using the Backbone framework. Backbone is a very simple framework, and this has allowed us to set up our UI interactions quickly and easily.

React.js with Redux

About four months ago, we started using React.js to reimplement core functionality – namely the portfolio page where students add their achievements. React.js provides some more structure for defining reusable components, and is more performant than frameworks like Backbone.js.

react.js interface
We write complex user-interfaces in React.js

SCSS for Sass

We write our stylesheets in SCSS, and use the Sass preprocessor. This allows us to write more complex stylesheets that get compiled into regular CSS for the browser.

Databases

MongoDB

The database that we use to store the current state of the application and its users is MongoDB. MongoDB provides a lot of flexibility when designing and changing the database structure (it is “schema-less”), which has allowed us to change core parts aspects of our data persistence strategy when adding new features.

Redshift

Business intelligence services like Chartio need to integrate with a relational database. We chose Redshift because it’s extremely performant and needs minimal configuration. We determined that we could handle the occasional downsides that come with using Redshift – namely potential data inconsistencies and data duplication. We currently transform our data from MongoDB to Redshift on two different schedules (once per hour for event logs, and once per day for stateful data.)

Redis (via AWS Elasticache)

We use Redis for a few critical functions: queuing, content caching and feature flags.

CloudSearch

When students search for high schools across our web application, we want to return suggestions for each key entered. For this, we need to have performant search functionality, for which we turned to an AWS alternative to ElasticSearch, called CloudSearch. We synchronize our data across MongoDB and CloudSearch on an interval, and use a Go service to access the data in CloudSearch.

Postgres

When we build our messaging service, we knew that it would be a write-heavy feature (as chat features tend to be.) For this, we decided to use Postgres, and keep messaging data separate from our application data stored in MongoDB.

DevOps

AWS Elastic Beanstalk

We deploy our webapp and most other services to Elastic Beanstalk, which provides load-balancing with minimal configuration. Elastic Beanstalk will increase the number of machines running our application during times of high traffic, and distribute traffic among those machines.

AWS EC2

We use Elastic Cloud Compute services for various other services, such as our engineering blog and jRuby applications.

AWS Lambda

We use Lambda functions for transforming our event logs from MongoDB to Redshift. All of our event logs are sent to Segment.com, which are dumped into s3. The s3 dump triggers a Lambda job to transform those data into a relational format, which we upload to Redshift.

AWS S3 and Cloudfront

We store assets such as images in buckets on s3, use Cloudfront for caching.

CircleCI

Whenever we commit code and push to a git branch, CircleCI runs the full test suite and alerts us about any failed tests. After merging into our develop, staging, or master branches, CircleCI runs the suite and (if all tests pass) deploys the application to the appropriate environment.

CircleCI
We use CircleCI for continuous integration

Those are the main aspects of our development environment. If you’re interested in these technologies, and want to use them to increase access to higher education, please visit our jobs page at (210) 498-1321.