Our Engineering Values

What We Do

We align our engineering efforts with our company’s mission: Better financial lives, through technology and people.

Just like our financial advisors abide by the fiduciary standard (meaning financial advice they give must be in the best interest of our clients), we develop products and services that serve the best interests of our users and clients.

We create new business opportunities by tackling complex financial problems facing millions of American families.

Every day we create a more connected and data-driven financial ecosystem for our users.

We take pride in our intuitive user experiences and a high quality of service that delights our users.

We filter out the noise to surface the most important information via data visualizations that show how financial actions create a storyline our users can follow to understand their current and future net worth.

We empower our users with personalized financial planning tools.

 

How We Do It

We believe the best solutions come from empowered cross-functional teams of engineering, product, marketing and advisory, and we believe in the spirit of collaboration.

We believe an important way to deliver financial advice is through data visualization and intuitive user interfaces.

We believe everything we do should be measurable,transparent and accessible to all.

We value open and streamlined communication from documentation in code, automated tests and captured product discussion; we speak our minds openly and freely.

We believe quality is everyone’s concern, and together we work hard to create a product that will improve people’s lives.

We embed best security practices in everything we do, at every level of our organization.

We value accountability, with the goal of fostering leadership and focus.

We work smarter, not harder: we use data to create and refine our business rules to get better results and use automation to scale them.

We promote our processes and best practices by automating them.

We let our code speak for itself through documentation, unit tests and test cases.

 

At Personal Capital, we’re all about changing the face of financial technology, and we are always looking for great talents to join our team. And you will join a team that works together to motivate, inspire, and change an industry.

We are Growing our Engineering Team!

This is your opportunity to be a disruptor in the financial industry while creating a service that serves families and improves lives.

What sets us apart is the way we use both data aggregation and machine learning technologies along with certified financial advisors to model a family’s financial life. No one has ever had the data, the technology and the people to do what we do: combine the power of an abstract computer model with the expertise of certified financial advisors to help families understand their current financial situation and help them optimize it for the next stages of their lives.

The amazing thing about working at Personal Capital is that when I leave the office each evening, I’m pumped with more energy, enthusiasm and optimism than when I came in. And that’s because I get to build a noble service with great people; it can’t get any better than that. Every day I work with the most talented engineers that I have ever worked with, building sophisticated services that empower thousands of American families to take control of their finances.

We are looking for curious engineers. We are looking for thinkers and doers. You need to be smart and build smart products. You need to be ambitious. This is not an easy job. You will need to wear multiple hats, work with many unknowns, travel many unpaved roads to tackle large-scale problems. But it will be your finest work and creation, and an amazing engineering team is here to collaborate with you and support you.

Here are our current open positions:

 

 

Six Tips on Defining WebService APIs

Frameworks such as PhoneGap or Sencha created a great promise of rapid development of fast and impressive apps across different platforms by focusing on client code reuse. We want to share a more holistic architecture across the server and client that let you go native on each client platform and still take advantage of code reuse.

The idea is simple: if you have control over both the server and the client design, you should not settle for a solution that only optimizes one.  If you “look at the whole board” and optimize the server for the clients, you won’t need to sacrifice the user experience for the sake of client code reuse.

Primary design goals for Personal Capital include:

  • Perfect balance between an feature-rich application and an intuitive navigation scheme
  • Creating the absolute best user experience; and
  • 100% accurate data presentation

With these design goals, we’re not satisfied with the defaults of each client platform, let alone defaults of shared code across multiple client platforms! At Personal Capital we have customized every component and every interaction in the pursuit of user happiness and achieving UX nirvana: a wowed and happy user each time that she uses our service.

Our Architecture

Our approach is simple: Go Native but optimize the server’s Web Services APIs for the client by following six simple tips to gain the time and flexibility we need to make our app stand out, on each platform, in its own way. We started experimenting with these rules two years ago when we created our Second Generation APIs, and optimized them as much as possible for the clients. These six principles allow us to streamline design and QA, and free up our client developers to spend the majority of their time on what they do best: making amazing user experiences.

Tip #1 Let Your Client Developers Write the Server API Definitions

API definitions are normally dictated by the server engineers, and REST enthusiasts and typical server-driven development paradigms have made it uncommon for client developers to be more than tangentially involved in server API definition before coding starts. We flipped this model on its head and relied on our client developers to drive the API definition, and as a result the server became much more attuned to how the clients expect the data to be structured, and minimized re-work later by maximizing communication early on.

Tip #2 Let Your Server Developers Take As Much Logic Out of Client Code as Possible

Avoid replicating code across many clients that you support and move as much logic as possible to the server. Having business logic in the client code is analogous to hard coding a configuration value. The pivotal point for us was realizing it’s better to have simple, thin, and pretty clients than complex, thick ones that have duplicated and hard coded business logic. Smart clients are a burden. Now each of the discussions between client and server developers is about “how can the server make the client’s code simpler?”

Tip #3 Don’t Be Afraid of Specialized APIs

Let’s just say this: it’s OK to serve the same data from more than one API. Why? Because when clients get data in the format they need, directly from the server, they can get it on screen faster by skipping complex transformations. And when the data format changes on the server, those changes are transparent to the clients. This has the added benefit of also not needing to care how the data is being used elsewhere in the client, making your client more loosely coupled and modular.

Tip #4 Let the Server Enforce Uniformity Across Clients

When it comes time to support multiple clients, the more you push responsibilities like rounding of amounts, calculation, and string formatting up to the server, the more time you will save your development and QA teams. You won’t need to spend time re-writing the same formatting and calculation rules on each client and fixing the same bugs on each platform. If it’s correct coming from the server, it will be correct everywhere.

Tip #5 No Workflow State Machines on the Clients

Likewise, when dealing with multiple clients, the more you push the complex state machines that deal with business logics into the server, the faster you will be able to iterate. For example instead of having a logic on the client that says “if user is in state x, and this is the first time that she is attempting to do y, show message z” just tell the client to show message z. All that logic can be encapsulated on the server and the API can just tell the client what to do. The time to market gained between each client writing and testing a complex flow versus each client simply responding to server flags is huge. It’s the difference between crazy nested ifs and a simple switch statement. Keep the complex state machines tucked safely in an API. Let your clients focus on display logic, and not managing business state.

Tip #6 Fast, Rich and Flexible APIs

If you follow all these tips, the payoff is huge: shorter time to market, simpler client code, less bugs. But if you want to pull this off, you must:

  • Make calling an API fast, really fast. Round-trip time of a request has to be as short as possible. This means server-side caching, is a must.
  • Create rich APIs that can deliver a lot of data in one call; this is especially important for mobile applications where the network overhead is much greater.
  • Add enough controls in the API definition to allow the client to ask for the right amount of data based on their flow. E.g. iPhone may not show transaction details and would just need the summary, but iPad and web do want to show these data. Give the clients the control to request the right data amount.
  • Gzip your responses as much as possible. The performance lift you get on mobile and web apps from this simple change are amazing!
  • Client-side caching of the API responses is just as important and reduces reliance on network stability to a great deal.

Go Native!

With loosely coupled client modules that receive pre-formatted data, and client developers that don’t need to implement tons of complex business logic, you can focus your client developers on what they do best. You’ve successfully freed up enough cycles that you can afford the extra spit and polish that will make your app stand out from the rest.

Last month we held a Meetup that we discussed these principles and how through this architecture you can reduce your client code base by not sharing client code, but rather sharing server code. You can watch the video here.

November Architecture Update

 

We have a simple engineering philosophy: our user experience has to be the absolute best, and our calculations 100% accurate, while everything else just needs to be “good enough” for “now.” This is why we can release high quality products early and fast. Behind the scenes, however, we are continuously refactoring our code base as “good enough” changes over time.

Our November release went live with a new HTML5 dashboard and account detail screens, as well as many interaction, performance, and refactoring upgrades for the web application as a whole. Here is how we did it:

Distributing Static Content We now serve all web application assets packaged and minified from Amazon’s CloudFront. This helps us serve our static content (js/css/media) to end users with low latency and high data transfer speeds. It also helps us separate the concerns of static content (front end) and server webpages (back end), which reference the static content. This gives us the ability to change static content at any time without having to re-deploy our entire application. Faster iterations. Better products. You can read more about it here.

Responsive Design One of the biggest variables in web interface engineering is client screen.  Our new HTML5 dashboard uses CSS media queries to offer a responsive design, rendering a single column for common resolutions, and two columns for wide resolutions. This wider resolution provides an efficient use of space and access to interface elements without the need to scroll. This gets us one step closer to providing that “financial picture at a glance” goal.

Financial Visualizations These are the interface embellishments that bring our web application to life.  We chose Raphael.js, a vector drawing API which makes programming SVG with javascript a pleasure.  We took this customized approach, rather than an out-of-the-box charting solution, because at Personal Capital, the defaults just aren’t good enough. We work very hard to design the most effective charts we can, and even harder to make sure that when we release them they live up to customer expectations. New visualizations featuring custom algorithms can be seen on the new dashboard and account management screens.

Datagrids This is the bread to our visualization butter. In one month, we switched over to a custom HTML5 implementation (from our previous Flex-based implementation) improving not just performance, but the set of features as well. Searching, sorting, and editing are all upgraded and we added a couple new features like multi-row editing and tag sorting. Angular.js is the technology that allowed us to achieve these gains in such a short period of time. Angular makes re-rendering based on live updates a non-issue, as the markup itself clearly and concisely documents what it will express as the data changes.

Polymorphic Backbone Views: Backbone framework has proven to be both scalable and fast. On the scalability side, the ability to extend and polymorph Backbone’s views helped tremendously in simplifying the code for Account Details. On the performance side, we were able to greatly reduce the number of unnecessary HTML redraws by writing custom functions that would update specific DOM elements.

That’s it for the new web app updates this month. Stay tuned for the next round of web app improvements in January!

Personal Capital Launches Android Mobile App

Personal Capital Engineers have ambitious vision, and as a friend put it, we’re always pregnant with more projects than we have engineers for. Our latest delivery is Personal Capital Android App.

Like our iOS app, the Android app is filled with interactive custom components and visualizations, from the rotating pie chart for cash management to the asset allocation tree map. Our philosophy in both design and implementation is to create custom native components tuned to the each device’s unique attributes to allow for an intuitive design and controlled behavior across varying device resolutions

In our Android app, we use many of the design concepts and lessons learned from our earlier development of our iOS app. For example, we implemented the same unique navigation system in Android that we use in iOS – it employs the concept of live views to speed up wayfinding for the user. We will be talking about some of these “shared clients that don’t share codes” concepts in our meetup as well.

If you haven’t downloaded the app yet, you can do so here: https://play.google.com/store/apps/details?id=com.personalcapital.pcapandroid

Watch this blog for more posts around our experience with Android Development.