Executive Summary

Read and write executive summary 

Descriptionof the Issue

Linkedin​ is a professional networking website that allows employers to post jobs and job

seekers to apply. ​Linkedin​ also has the capability to create “connections” with other people on

the website, usually your peers, coworkers, or recruiters that you met at a job fair. When job

seekers are applying for jobs, it is commonplace for them to first find people that they know at

companies that they’re applying to as a way to get a referral and increase their chances of

landing a job.

We want to create a system in LinkedIn where users are able to categorize their

connections into different private groups. These are not the same as the groups that LinkedIn

already has available because people within your categories would not know they are in your

categories. For example, a possible category would be “Recruiters” and you would be able to put

all recruiters that you have connected with in that group for easy organization. Another example

would be “People that I could ask for a Referral,” where you put your closest connections. In

March 2016, a study was conducted that had shown that 70% of users had over 300 connections

(Statista). This makes it very difficult for job seekers to filter through their connections and find

people that they would be able to seek referrals from. With the addition of the categorization

feature, you will be able to place your connections in a category upon initially connecting or by

viewing your previous connections list.

Description of the Solution

In order to make it more convenient for the users, we will add a new filter called

“categories” so that the users are able to categorize their connections into different private

groups. Unlike the following mechanism which automatically sends a notification when someone

starts to follow a user, this filter is completely private and safe to view and find a person who

matches the category. Being derived from the Group mechanism is the huge advantage of this

feature because we only set a constraint that allows the users to categorize every connection if

they want to. Additionally, adding this feature into the filter list is a non-invasive process, it

means that it won’t conflict with any previous running components. We, however, need to create

a backup and some unit tests to make sure everything works well.

Description of why the solution was chosen

The implementation of making private groups of categorized connections was chosen

because the already existing feature of making groups is known to work on ​Linkedin​. The

implementation is suggested now because we feel that the group feature just isn’t providing

enough for users of the site to connect with other users easily, and the addition of categorizing

connections could add more variety to how users can choose to search for employers or job

seekers.

Since the group feature already exists on ​Linkedin​, implementing an additional option of

being able to categorize connections and make private groups from them should not be difficult.

The implementation simply builds on top of the already existing group feature, and does not

require a completely new component to be created on the site.

Categorization as an option or a minor feature has been implemented on other types of

social networking platforms, one of which is the video game digital distribution service Steam.

Steam’s software client used for distributing video games also has some kind of a social network

system, in which users can add each other on the client as “friends” through the use of a friends

list, similar but not the same as creating “connections” with other users on ​Linkedin​. Steam

provides the option to categorize friends on a user’s friend list by creating different categories to

put those friends in, allowing users to organize their friend list and easily search for a particular

friend. Although a minor feature on the client, the categorization option on Steam works as

intended so a similar system on ​Linkedin​ should perform well.

Description of Challenges

People who have many years of experience using LinkedIn may feel it less intuitive to

find connections by category, because they are used to filter connections by location, company,

school, and so on. The most effective way of minimizing this drawback is to add a new filter in

the filter list, namely, by user-defined category. Adding such a filter will ensure that the new

functionality (categorizing connections into private groups) can be integrated with the existing

filtering features of the platform. Note that when a user wants to find someone who has been put

into multiple categories, the user should be able to find that person by any matching category as

it is impossible to remember the exact categories for all connections. (If your friend A is both

categorized as ‘College Friends’ and ‘High School Friends’, you should be able to find A either

by the filter ‘College Friends’, or ‘High School Friends’, or both.)

People who rely on the main search bar (typing) may not be able to find connections

based on category, because some user-defined category’s name can be identical to certain

keywords recognized by the search bar. For example, Peter Anteater chooses to name one of his

own categories ‘Anteater’, which contains all connections he has made within UC Irvine.

However, since Peter’s family name is also ‘Anteater’, the search functionality may return

whoever has the last name ‘Anteater’ from Peter’s connection list. One solution to this problem

is that the search bar needs to be able to recognize category names and then differentiate them

with their other possible meanings. This ability will be built on existing modules, since the team

who designed the search bar already realized the ambiguities caused by phrases which have

multiple meanings (LinkedIn). (If you type in ‘UC Irvine’ in the search bar, in the dropdown

menu, it will ask you whether you mean People, Jobs, School, or Group. Similar things can be

done for Category.)

There is a risk of putting people into embarrassingly titled groups on accident. However,

this problem is not a direct result from the Categories feature. ​LinkedIn ​has been running the

Groups feature for years, and it requires users to invite members to any existing groups. Even if

they do invite connections into a group unintentionally, the already existing Groups module

should have the ability to cancel or undo the invitation (within a short amount of time). While it

is possible that people get confused about “Groups” vs “Categories”, we will make sure that each

feature has a separate entry point. For example, the “Groups” link will always appear in the main

tab on the left side, and it will sit under the “Connections” so that users understand “Groups” are

different from individual connections. Moreover, “Categories” will only be accessible within the

“Connections” page itself, so that users who are browsing their connections can have the option

to categorize their connections. Once done with a test version, we can experiment with users and

conduct a survey to ask if they get confused with the two features. If the rate is high enough, we

can explicitly add a confirmation pop-up, before any invitation/categorization, to specify the

purposes of Categories and Groups.

Adding the new functionality will probably slow down the website’s

loading process.

While the time it takes to load the website depends on many factors including internet speed,

server capacity, web browser usage and etc, we can use tools like Adobe’s getLoadTime plugin

and Google’s Site Speed Reports to measure roughly how much extra time it costs to load the

page after the implementation of the new feature (West). This problem is so far the biggest and

worth the most of our attention, since a slow page not only affects user experience but also

weakens itself in search engine rankings (Phapale, Tse). One general way to mitigate the extra

burden is to pre-load contents in the web browser’s cache, so that the server side will have more

computing resources. Other than that, combine the new Category functionality with Group,

because they have a lot of overlapping code, packages, and libraries that can be loaded once for

all.

Timeline

For the first two weeks of our plan, we will form a team of business analysts, software

engineers, quality assurance engineers, and a project manager. The team can consist of both

existing LinkedIn employees as well as contract employees.

Once the team is developed, we will create user stories for the new feature. We want to

ensure that LinkedIn users will find value in categories, so allocating time for the development of

comprehensive user stories is very important. This task will be primarily done by business

analysts. The conservative estimate for how long this will take is approximately two weeks.

Before actually beginning development of categories, we will spend another two weeks

drafting a requirements document and high level design document. Business analysts and

software engineers will work together on creating the requirements document, while lead

developers and the project manager will work on the high level design document. One more

week following these drafts will be dedicated to edits and revisions of these two documents.

These documents will be shown to a LinkedIn technical director for revision and review.

The following four weeks will be dedicated to two sprints: one in the first two weeks, and

one in the second two weeks. A sprint will consist of design, review, development, and unit

testing. Our team of software engineers will work on design, review, and development for the

first seven business days and the following three business days are dedicated to unit testing by

quality assurance engineers. Since the feature can be derived from the groups feature, we know

that there will be very stable existing functionality and test suites for the new category feature. In

the first sprint, a team of developers will work on the implementation of the categories feature

building on the existing groups feature. In the second sprint, we expect to work on experimental

server deployment using different UI designs.

Finally, we will have some LinkedIn users participate in a trial of the categories feature

for a full week. They will act as end users and will be randomly sampled from the population of

active LinkedIn users to accurately represent all users. Based on their feedback, another sprint

and trial may be necessary: this could take another three weeks. In total, this project will take 12

-15 weeks to complete depending on the feedback of end users.

Budget

This project will cost the salaries of a small team of software developers, business

analysts, quality assurance engineers, a project manager, and the cost of additional data storage

for users. It would not be difficult to find a team of skilled fullstack developers especially among

the breadth of skilled teams at Linkedin. Although Linkedin undoubtedly manages petabytes of

data every single day, the addition of monitoring user-created groups will not create so much

additional stress that brand new technologies will be necessary. The total cost of this project will

therefore be the sum of the salaries of five software developers, two senior software engineers,

five business analysts, three quality assurance engineers, and one technical manager. One

technical manager’s salary for a month is approximately $16,804 and the salary for a software

developer is $11,276. The total cost is estimated at $73,184.

The following table is based on the average salary of each engineer as seen on

glassdoor.com. It does not take into account signing bonuses, relocation costs, or stock bonuses.

The 1 week salary column will already factor in the number of employees of a specific type into

its total.

Testing

Nothing is better than the end-users’ satisfaction with ​Linkedin​, so testing the new filter is

necessary and essential so that the customer’s expectations could be validated and verified. As

we mentioned above, there are three criteria that we need to pass before publishing this new

feature. The first one is to check if the new filter’s behaviors work correctly, the second one is to

check if there is connection leakage, and the third one is the concern about performance or

loading process.

The Category filter is basically derived from the Group filter, so it inherited all functions

from the Group filter: create and delete a category, insert new connection, find category and

connection. To test them all, we will perform procedures that are used to test the Group’s

functions. Specifically, we will perform sanity testing after adding some changes in functionality

Employee 1 Week Salary 15 Week Salary

Software Engineer (5) $13,010 $195,150

Lead Software Engineer (2) $6,459 $96,885

Business Analyst (5) $11,684 $175,260

QA Engineer (5) $10,083 $151,245

Project Manager (1) $3,162 $47,430

Total: $665,970

to identify bugs which have been fixed and ensure that it won’t cause further issues because of

these changes.

Another concern that we need to keep an eye on is to test the privacy of the Category

connections. Initially, we will create random test cases containing categories which have about

1,000 connections and check if user B could find any connections or categories of user A by

using the search bar. By applying white-box testing and path coverage testing, we will be able to

find invalid data sets which lead to information leakage.

Image: Path Coverage Testing to find invalid test cases

In order to test the loading process of the Linkedin after adding the filter Category, we

will do the performance test to express time per request to measure how long it takes to load the

page. Before doing this test, we need to install ApacheBench, which is a program performing the

load test to benchmark the results, on a developer’s computer. The table below shows the results

that we collected based on the number of requests (with and without cache). Since the average

loading time of social media is 5.5s, the results collected are ideal for loading all connections at

the time.

Table: The average loading time per request

Test Case
ID

Workload Condition Expected Result

1 1 request Load page completely
(1,000 connections)

without cache

< 0.01 ms

2 1,000 simultaneous requests Load page completely
(1,000 connections)

without cache

< 10 ms

3 10,000 simultaneous requests Load page completely
(1,000 connections)

without cache

< 10000 ms

4 1 requests Load page completely
(1,000 connections)

with cache

< 0.006 ms

5 1,000 simultaneous requests Load page completely
(1,000 connections)

with cache

< 6 ms

6 10,000 simultaneous requests Load page completely
(1,000 connections)

with cache

< 6000 ms

Works Cited (MLA)

“1st Level Connections of LinkedIn Users 2016.” Statista, Statista Research Department, 18 July

2016,

www.statista.com/statistics/264097/number-of-1st-level-connections-of-linkedin-users/.

Awan, Aatif. “The Power of LinkedIn’s 500 Million Member Community.” LinkedIn, 24 Apr.

2017, blog.linkedin.com/2017/april/24/the-power-of-linkedins-500-million-community.

“LinkedIn Software Engineer Salaries in San Jose.” Glassdoor,

www.glassdoor.com/Salary/LinkedIn-Software-Engineer-San-Jose-Salaries-EJI_IE34865.0,8

_KO9,26_IL.27,35_IM761.htm.

“LinkedIn Staff Technical Program Manager Salaries.” Glassdoor,

www.glassdoor.com/Salary/LinkedIn-Staff-Technical-Program-Manager-Salaries-E34865_D

_KO9,40.htm.

“Searching on LinkedIn.” LinkedIn Help,

www.linkedin.com/help/linkedin/answer/302/searching-on-linkedin?lang=en.

Phapale, Guarav, and Oliver Tse. “Speed, Performance, and Public Profile.” LinkedIn

Engineering, 17 May 2016,

engineering.linkedin.com/blog/2016/05/speed–performance–and-public-profile.

West, Josh. “The Hard Truth About Measuring Page Load Time.” LinkedIn, 23 June 2015,

www.linkedin.com/pulse/hard-truth-measuring-page-load-time-josh-west/.