Tips for Interns from a Former Intern

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!!

A High-Level Look at NSURLSession

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 (

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:



Unit Testing as Design Principle (part 2)


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!

Unit Testing as Design Principle (part 1)

Formal Unit Testing is usually treated as a trivial and boring subject concerned with tedious testing of low-level implementations. Developers often see it as an overhead, as something that takes time away from feature development, and requires constant maintenance as code changes and evolves. But it is not so, or at least this is not the whole story…


The truth is that if approached properly Unit Testing becomes a powerful method or technique, that not only assures certain quality of the end product, but naturally enlightens all stages of the Software Development Life Cycle (SDLC). It is not something that needs to to be done at the end of the development cycle, but rather a discipline that should be practiced starting at the very inception of the design process.  And as such, it becomes a fundamental design principle in its own accord – just like the famous Open/Close principle, for example. For the sake of this post, let’s name this design principle as Principle of Testability (PoT).


This principle by no means guarantees “bugs free software.” It rather implies that the software product should be designed and implemented in such a way that it could be efficiently tested on any chosen level and in any chosen environment (from local machine to CI server)! It also gives a promise, that if we do focus on achieving and retaining Testability throughout the development cycle, the whole software ecosystem naturally aligns, self-organizes and yields high quality results on many levels.


Let’s now review a some practical examples that illustrate how PoT naturally leads toward strong design and implementation solutions


Selected design principles and best practices

  • Favoring Composition over Inheritance

It is much easier to test code designed around Composition approach rather than code based on Inheritance – because when we can “take system apart” we can focus on testing its individual parts in isolation – which is in fact a definition of Unit Testing. Thinking of PoT will innately promote Composition

  • Favoring Convention over Configuration

From such trivial aspect as naming convention for discovering tests based on their name patterns (e.g. FooManager vs FooManagerTest), to conventions for discovering properties and context files at certain locations at runtime – we can see that lightweight Conventions could be extremely useful and efficient tool for multipurpose testing framework. The PoT will lead to giving preference to flexible Conventions over involved Configurations – and not only in the domain of testing, but potentially in the respective areas of software product itself

  • Adhering to Open/Close Principle

All software systems evolve over time and require changes and modifications. Focusing on PoT will naturally promote keeping public APIs sealed, as well as leaving intact their original tests. Instead of changing existing code, and making a considerable effort to ensure backward compatibility by modifying all corresponding tests, it is simply wiser and safer to add new flavors of APIs, and to complement them with number of new tests – which in essence is favoring OCP over other possible approaches

  • Adopting IoC and DI

For efficient testing of core logic in classes that depend on other classes and resources, it is extremely important to be able to exclude at runtime all unrelated dependencies (example: database based audit trail or logging could be completely irrelevant when testing actual biz logic of a given method; but because auditing is an integral part of the method, it requires full setup and access to the database during the test. When DI is used we can easily provide another audit manager implementation that does nothing at runtime). As such, thinking of these concerns up-front will naturally lead toward use of IoC and DI to enable mocking and stubbing later on for the sake of testing

  • Favoring “Fail Fast” behaviour

When we think about PoT up-front, we are aware that any test may legitimately fail at any point. As such, it may leave the system in some “unfinished state” preventing subsequent re-execution. Detecting failure as early as possible, aborting further processes, including asynchronous and resetting the state of the system are properties that are required for efficient unit testing. At the same time they will most probably benefit the system as a whole

  • Built in retries, recovery, self healing features

When application runs in Production most of use cases related to failures are often interactive – user may be prompted to try again, may be asked to re-login or call support. During the test we can’t rely on such luxuries. We need sometimes to be able to retry number of times, simply as part of the valid test, or allow for a failure in a negative test, followed by restoration of a valid state (even if asynchronously) before the next test. Thinking of these concerns up-front may benefit the overall design. It may help to choose adequate 3rd party framework based on such capabilities (good example is @Rollback(true) feature of Spring Testing Framework)


Optimal granularity and composition of the system

  • Self-contained and properly scoped classes, packages, jar and war files of optimal composition

It is hard to strike the ideal breakdown, but thinking about PoT in this context will help a lot in quest for proper balance. A single class’s content may be revised when we think up-front about complexity of corresponding test class. We may opt for breaking one monolithic class down into number of composing classes, simply in order to simplify and better scope their corresponding test classes. Same may apply to packages and deployment modules. Another aspect that comes to mind is benefits of keeping test classes in the same packages as their corresponding “parents.” This will allow testing of any protected methods (such protected methods could be a legitimate trade off to use of a traditionally prescribed private methods – especially with heavy logic)

  • Using APIs parameters adequate to the application tier or layer

Often we can see parameters that clearly belong to the presentation layer make their way down to the persistence layer, for example (think of HTTP Request, or Session, or some Thread Local Context established at the entry point into the system). It simplifies signature, may be…, but completely hides required inputs and need for validation, making it very hard to test such a method. In addition is wrong conceptually. This can be avoided by applying PoT early enough – more precisely at the time of class / method creation

  • Resisting a tendency to treat commodity services provided by the Container as something granted

Modern application containers provide a full array of commodity services at our disposal: enterprise messaging, transaction management, distributed cache services, etc. These services are easily available almost everywhere in the code. While container offers ease and transparency in accessing these – otherwise hard to configure services – the application itself becomes fully entangled with its container. We realize it, when trying to unit test areas of the application: as the use of the container provided services proliferates through the code, it becomes harder and harder to test application outside of the running container. The PoT suggests number of approaches to this subtle and often overlooked problem. Typically they boil down to creating a well defined layer where application registers with services available in the container and overall treats them as something external. There we can choose to register with the services provided in some alternative way (mocked or standalone). Or not register them at all. Of course, provided that the code consistently checks for their availability and has some default behavior where it is acceptable (example: methods under the test may broadcast some audit events using JMS; this can be completely irrelevant to the business logic that we are trying to test; if we consistently check for JMS provider availability before using it, we can avoid exceptions during test phase, log relevant message and proceed). At the end, addressing or at least acknowledging concerns like these, will result in stronger, more flexible and resilient architecture

  • Wire-On / Wire-Off mechanisms

One setting or wiring may enable or disable a whole feature or a module. It could be extremely important when you want to be able to test some potentially invasive new code without “releasing” it or making it available in the UI. Being concernted with mere Testability in a case like this may bring into the focus originally overlooked but beneficial functionality of Wire-On/Off

(to be continued)