This blog post would be better suited if I wrote it in the beginning of the summer but whoops. I’ve been working full-time at Personal Capital for over two months now. Last summer I interned here and in this post I’d like to share to all current and future interns some tips to maximize their internship experience.

tl;dr Summary:

  1. This is your time to shine. Show them what you got!
  2. Always be eager to learn and ask how to improve.
  3. Seek out help if you need it.
  4. Dabble in different things.
  5. Go out to lunch.
  6. If you’re interested in returning, let them know!

1- This is your time to shine. Show them what you got!
Congrats! You made it past the interviews, offered an internship, and now spending the next couple of months working for them. This is an audition for both sides. They’re trying to further evaluate your skills and how you interact with others. From your perspective you want to see if this is a company that you see yourself working for after college.

2- Always be eager to learn and ask how to improve.
You’re probably the youngest person in the company. You’re surrounded by people with years of experience who have been through a lot. You can learn so much from them! Also soliciting feedback on the work you’re doing is very helpful in developing you, the professional.

3- Seek out help if you need it.
If you’re stuck on something or just don’t understand the task/problem at hand be sure to ask questions. There’s no such thing as asking too many questions. You might spend a lot of time on something that was not needed or wrong. I’m sure your supervisor would rather take a little time in the beginning to ensure you don’t spend unnecessary time down the road.

4- Dabble in different things.
This is your opportunity to try out something you don’t really know about. Some companies will differ in how much you can explore outside what you’re brought into do, so your mileage may vary on this one. Every company has many projects happening or want to happen, and this is your chance to see if it’s what your passionate about.

5- Go out to lunch.
You’re surrounded by many fascinating people, all with different backgrounds and journeys they took to get where they are today. Unfortunately in the office we’re just so focused on the task at hand that we really don’t get to know the people we work with. Grabbing lunch is an excellent opportunity to really get to know about them. Be it one-on-one or a group; I know I really enjoyed “Lunch Crew” when I was an intern.

6- If you’re interested in returning, let them know!
Lastly if you are interested in working there in the future, communicate that towards the end of your internship. After having a great time last summer I spoke with our Ehsan, our VP of Engineering, and was fortunate to be offered a full-time position after graduating. I’m not alone. According to the National Association of Colleges and Employers (NACE) 2015 survey, employers converted 51.7 percent of their interns into full-time hires. You can be a part of the majority!

That’s it! I hope you enjoyed this post and find it useful!!

I had a great time as an intern here at Personal Capital. I worked as a member of Personal Capital’s Data Team, getting my hands dirty in a range of projects, from data validation, to daily monitoring, to expanding/updating our ETL process into Amazon Redshift. One of my biggest takeaways was the paramount importance of not allowing the fast pace of the company to erode the use of best practices. Specifically, I grew to appreciate how important it is to write solid tests of all new code, keep good documentation of all changes to the database, and always keep security in the back of your mind.




The Personal Capital codebase is primarily written in Java, allowing us to write solid unit tests through a Spring framework. We hold ourselves to a high standard, mandating that our unit tests must touch a significant portion of all new code.  One of the larger tests that I wrote used Mockito to mock large portions of data through which to test our transformation, allowing me to better focus the test as well as maximize its robustness. This test operated on most of the tables in our most important schemas in Redshift, and I wrote it in such a way that it would be as easy as possible to add new tables to the test/amend it to accommodate changes to our Redshift schemas. Coupled with extensive logging, these tests allow us to pinpoint bugs when they are introduced into the codebase.




During my time here, I was part of an ongoing effort to create a general-purpose data warehouse on Amazon Redshift, a single source on which all data exists, thus greatly improving the ease of analysis. By consolidating our data on Redshift, we can now run queries in seconds, queries that would previously take hours. As one might expect, throughout the process, it’s typical for fields to become deprecated, and for fields to be created with ambiguous meaning. Part of my job at Personal Capital was aimed at addressing this problem, through a unified data dictionary that resolves discrepancies in the definitions understood by different teams, as well as consolidates the documentation. This is still a work in progress, but it will ultimately make analysis of Personal Capital’s data much more meaningful. In addition, throughout my time here, I did work that involved deprecating/adding many new fields in existing tables, as well as adding new tables, and I made sure to bolster Personal Capital’s documentation by documenting my changes thoroughly.




I was really impressed by the security measures put in place at Personal Capital. Shortly after I began working here, I was given a rundown of the security practices used by Personal Capital as well as information about how to avoid introducing vulnerabilities in the code. The engineers here always keep security in mind when writing new code, something that can be easy to forget in the effort to move quickly. In addition, all new code goes through a rigorous review process before release.




I’m very grateful to have been given the opportunity to work at a startup quickly establishing itself in the financial technology sector. While it is a very fast-moving company, I’m glad that the engineers here don’t lose sight of the long-term picture, always meticulously subscribing to best practices that will greatly improve our outlook years down the road.

Though Apple introduced NSURLSession in 2013, NSURLConnection has served as such a strong networking infrastructure that there really hasn’t been a need to update it. With the upcoming release of watchOS 2 and iOS 9 in September, refreshing Personal Capital’s tech stacks seem appropriate so we can take full advantage of Apple’s latest technology offerings.

The NSURLSession API comprises of the same components as NSURLConnection (NSURLRequest, NSURLResponse, NSHTTPCookieStorage, NSURLCache and NSURLProtocol) but replaces NSURLConnection with NSURLSession, NSURLSessionConfiguration, and NSURLSessionTask.


NSURLSession: divide and conquer

NSURLSession introduces the concept of configuring cache, cookie, credential, and protocol policies into sessions instead of sharing these policies throughout the app. This allows you to separate network tasks into appropriate sessions as needed so changes to protocols, credentials, cookie storage, or cache storage can be localized to only the tasks in that session. This is done by initializing an NSURLSession with an NSURLSessionConfiguration. After initialization, you cannot change a session’s configuration. If you feel a need to do so, this probably means the network request or task belongs in a different session. If needed, you can override HTTP header values set in the HTTPAdditionalHeaders property of a session’s configuration by setting them in the NSURLRequest.


NSURLSessionConfiguration: persist/share, private, and background

NSURLSessionConfiguration has 3 types of constructors.
+ defaultSessionConfiguration returns the default configuration and defaults to using the same shared cache, cookie, and credentials storage that are familiar with NSURLConnection.
+ ephemeralSessionConfiguration returns a configuration that uses no persistent storage for cache, cookie, and credentials. This configuration would be used if you wanted to create a feature similar to private browsing.
+ backgroundSessionConfigurationWithIdentifier: returns a configuration that allows HTTP and HTTPS uploads and downloads while the app is in the background. If an upload or download is interrupted because the app is terminated by the system, the upload or download can be resumed by creating a new NSURLSessionConfiguration with the same identifier that was used for the interrupted configuration and passing that to a new NSURLSession. Interrupted tasks cannot be resumed if the app was terminated by the user.


NSURLSessionTask: reminds me of NSURLConnection with a completionHandler … and background support!

NSURLSessionTask is analogous to NSURLConnection because it’s the base class for handling requests for data as well as the uploading and downloading of files. NSURLSessionTask consists of three different subclasses.

  • NSURLSessionDataTask is used for making HTTP and HTTPS requests and return the server’s response as NSData in memory. An NSURLSessionTask can be constructed by providing an NSURL object or an NSURLRequest. These tasks are only supported in default and ephemeral sessions.
  • NSURLSessionUploadTask is a subclass of NSURLSessionDataTask but these tasks provide an easier way to upload content. For example, you can create an NSURLSessionUploadTask by passing an NSURLRequest with either NSData representing the body data of the request or an NSURL object for the URL of the file to upload. These tasks are allowed in background sessions and provide callbacks to the session’s delegate as data is uploading. Since these tasks are allowed in background sessions, you can technically create an NSURLSessionUploadTask (pass nil for the body data) instead of an NSURLSessionDataTask if you really require the task to continue in the background.
  • NSURLSessionDownloadTask is a task that directly writes the server’s response data to a temporary file. After completion, the app needs to move the temporary file to an appropriate place. These tasks can run in any type of session.

Instead of allocating an NSURLSessionTask on it’s own, tasks are instantiated by an NSURLSession object. An NSURLSessionTask can be constructed with and without a completionHandler. If a completionHandler is provided, it will be executed after the request is completed on the delegate queue. For NSURLSessionDataTask and NSURLSessionUploadTask tasks, the completionHandler will return the NSData and NSURLResponse object returned by the server or an NSError object if an error occurred. The completionHandler for an NSURLSessionDownloadTask task returns the location of the downloaded file as an NSURL object, the NSURLResponse from the server, or an NSError object if an error occurred.


Delegates: why to not construct with a completionHandler

You may be wondering why you would ever create an NSURLSessionTask without a completionHandler. If you require finer control over the progress of an NSURLSessionTask, you need to provide a delegate. If you provide a delegate and also provide a completionHandler, you will notice that none of the callbacks related to progress are called. (You will still get URLSession:task:didReceiveChallenge:completionHandler:.) If you want to receive all of the callbacks, you need to construct your task without a completionHandler. The combination of NSURLSessionDelegate, NSURLSessionTaskDelegate, NSURLSessionDataDelegate, and NSURLDataDownloadDelegate cover the delegate methods that NSURLConnectionDelegate and NSURLConnectionDataDelegate provided for NSURLConnection. Each of these delegates are well documented so there’s no need to go over them in this article. One thing to note, though, is that both NSURLSessionDelegate and NSURLSessionTaskDelegate provide callbacks for authentication challenges. The callback for NSURLSessionDelegate handles authentication challenges at the connection level (NSURLAuthenticationMethodNTLM, NSURLAuthenticationMethodNegotiate, NSURLAuthenticationMethodClientCertificate, and NSURLAuthenticationMethodServerTrust). If URLSession:didReceiveChallenge:completionHandler: is not implemented at the session level, the callback at the task level is called. URLSession:task:didReceiveChallenge:completionHandler: will additionally handle authentication challenges at the request level.


Further reading

All of the information mentioned in this article can be further studied in the NSURLSession Class Reference from the iOS Developer Library (

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:




Efficient SDLC

To be tested continuously, as term CI suggests, the code under the test must be running fast, failing fast, be as idempotent as possible, be easily configurable and produce adequate and quickly actionable output and logging

  • If requirements like these are taken into account up-front, they change dramatically the way we think about code we release. They may sound like irrelevant concerns in the beginning of development cycle, but practice shows that at the end, software that satisfies such requirements is stronger, more resilient, and of higher quality. Also, it implies that we are “forced” to think about big picture when “simply coding” in our seemingly isolated environments
  • If code that we release is to be tested continuously it must be “nice” to the database, file system and any limited or expensive resource that it may eventually hit. Also, it is very desirable that state of any “external” resource after the test will be left intact (not always possible, but at least desirable)
  • Notifications of the test failures should be concise and well targeted – this why we should be concerned with efficient and precise error logging and reporting at all stages of development
  • During Agile planning it is very useful to keep in mind Unit Testing. If scope of the Task makes Unit Testing effort impossible, it could be a sign of warning and prompt for an additional breakdown of a Task or a Story (it is not a rule that set in stone, but it is useful point to keep in mind)
  • Thinking of Fast tests vs Slow tests, or Unit Tests vs Integration Tests and their effects on CI process helps to optimize this process, make the most of it, and in addition, helps to better understand the code base itself


Knowledge Transfer and Documentation by example

  • One of the best ways to explain how system works internally is to show a fellow engineer a few running Unit Tests. Of course, tests could be too fine-grained to reveal the big picture. This why it is always good to have a few very straightforward, high-level tests that simply demonstrate the essence of the feature or selected piece of logic. We can think of them as Demo Test, or Spec Test. In a team environment and especially in any distributed team environment it could mean a lot
  • Good Unit Test will self-document the code and can efficiently complement or illustrate any Javadoc entry. More importantly,  “documentation” of this kind will naturally be kept up to date – otherwise build will break 🙂
  • Good Unit Test can demonstrate not only a feature, but the idea or concept behind the feature


POC and R&D work plus some non standard applications

  • When prototyping a new feature or when doing preliminary research we often end up writing standalone programs that are eventually become a throwaway code. Implementing these tasks as Unit Tests has certain merit – they become part of the code base (but not part of the production code line), they are easily executable as part of the standard testing framework, available to be revisited later, and discoverable by others for review and study (again, it does not apply to every situation, but it is something to think about)
  • Many proprietary frameworks and 3rd party systems often feature certain internal or proprietary  configuration parameters that frequently lack documentation. We often make use of such parameters, usually after considerable effort to tune them up for certain needs of our applications. But those parameters and their effect may change from release to release, or from environment to environment (for example, Oracle DB, its optimizer with its proprietary hints…, or only suggested JDBC fetch sizes used for batch processing). If effects and baselines of such “boundary” configurations are captured as part of automated Unit Testing, any unwanted change in behaviour could be caught proactively before it will reach Production environment. For example, Unit Test can automatically produce and capture explain plan for the query used in Java code, and assert against absence of Full Table Scans. This technique is also useful to detect changing data selectivity as it  affects applicability of existing indexes.


Efficient bug fixing and troubleshooting

  • When Unit Test coverage for some module or feature is sufficient enough, we can often completely avoid expensive cycles of deploying and running application in the container, requirements of database connectivity and other configurations, as well as need to attach to the running process with IDE or debugger of choice. Running a few unit tests (even after some modifications) to reproduce the scenario based on data collected from error logs or from user input, may be all that is required to locate the culprit


Happy Unit Testing!