RECOMMENDATION SYSTEM

The Internet told me to do it

Shailaka

Poonam

Alex

Rahul

11/08/09

Shailaka → Poonam, Alex

→ In V2.0, we recommend Jobs to Jobseekers

→ And Resumes to Recruiters

→ Based on what other Jobseekers / Recruiters "LIKED" (clicked, visited, viewed resume etc.)

Recommendation System (Recommending Jobs to Jobseekers and Resumes to Recruiters)

• It is human nature to be guided by “Expert Recommendations” while taking any decision. Take a look at “Investments” – whether in property, shares, gold, etc. Newspapers, magazines, TV, Internet are full of so-called “Experts” recommending what you should do. And such “recommendations” are eagerly lapped-up by the investing public.

• See the above article. This trend is catching-up on the internet as well. I have seen job-portals, which say,
  “Other jobseekers who looked at this advt, also looked at following advts:”
  1.
  2.
  3.

• Underlying assumption is that SIMILAR people have SIMILAR tastes (likes/dislikes etc.)

• In V 2.0 of IndiaRecruiter, I propose that our “Recommendations” operate at the following two levels:

At INDIVIDUAL level

At this level, we will compile the “search-parameter-selection-history” of every (logged-in) user, whether a jobseeker or a recruiter.

What “search-parameters” did he select during his search?

(of course, only if he clicked SUBMIT button after selecting).

Store these & arrange each parameter in the descending order of the FREQUENCY with which it was used by THAT user.

(PERSONAL USAGE HISTORY)

Then, every time he returns to the “search-page” (i.e. logs in), display the

SEARCH PARAMETER DROP-LISTS

in the descending order of his own “personal usage,” so his “favourites” always show-up on the TOP of the drop-list. We might, if possible, show inside a bracket, the no. of times he has selected that parameter in the past.

This fig. inside bracket will assure him that we are not pulling a fast one on him! It only shows that “we care to remember”!

This system will apply to both jobseekers & recruiters.

At “COLLECTIVE WISDOM” level

At this level, we want to “recommend” to the user, what SIMILAR people have been doing.

Let us, first take the case of Jobseekers.

What kind of jobseekers are SIMILAR (to one another)?

These are Jobseekers who are:

1. ▶ belong to SAME “function”

2. ▶ have SAME “raw score”

3. ▶ have SAME “desig. level”

4. ▶ have SAME “Edu level” (or even SAME degree/diploma)

5. ▶ belong to SAME “Industry”

6. ▶ draw SAME “salary”

7. ▶ are of SAME “Age” etc. etc.

---

Till we have LAKHS of resumes in our database, such FINE BREAK-UP would be meaningless.

Hence, to begin with, we will take only the first two attributes, viz.:

▶ SAME FUNCTION

▶ and within that function, SAME “RAW SCORE”

---

So the database-table will look like:

                   Raw Score
Function         | 1 | 2 | 3 | ... | 99 | 100
------------------------------------------------
Sales            |   |   |   |     |    |
Mktg             |   |   |   |     |    |
IT/VA            |   |   |   |     |    |
ASP.net          |   |   |   |     |    |

Each CELL will store “Job-Advt” viewed history of all the candidates within each CELL – arranged in descending order of no. of times that Advt was viewed.

Here is the transcription of the handwritten content from Page 4:

So, the most frequently “viewed” (job-advt) by SIMILAR co-professionals

will show up at the TOP and the least frequently viewed will be at the BOTTOM.

Now we are ready to tell that user:

“Here is a list of Job-Advrts which were most frequently viewed by your co-professionals”

Sr. No	Advt ID	No. of times Viewed	Advt. Details	View ✅

There is no need to tell the user what is our definition of his co-professionals.

If he opens/views, we add that instance to our table.

Of course, this Recommended Advt. Display Table will be below

the normal display table of Job-Advrts which meet his current search-criteria.

And, if he opens/views any of those job-advrts,

those too must get added to the CUMULATIVE SEARCH HISTORY –

(CELL WISE) – SIMILAR CANDIDATES.

This (above) logic can be extended to Recruiters conducting Resume Search

at INDIVIDUAL LEVEL

by coupling his own “Search Criteria History”.

Let me know if you’d like a visual diagram for this recommendation logic, or a compiled Word version of these pages.

But, at COLLECTIVE-LEVEL, how do we compare

SIMILAR Recruiters?

There is nothing like “Same Function & Same Score”?

What, if anything, is COMMON between any two recruiters — so that we may treat them as SIMILAR?

As of now, I find that “INDUSTRY” is the only common thread between recruiters — and we are capturing this info in Registration form.

But, when 2 recruiters belonging to SAME Industry login to conduct resume searches, they could well be conducting searches for altogether different types of resumes:

e.g. one is searching for Sales candidates and

   the other is searching for R&D candidates.

So we will need to compile FUNCTION-WISE Resume Search History of all recruiters belonging to SAME INDUSTRY. Once such a search (say for “SALES” function) returned a table containing 49 resumes, then:

WHICH resumes did that recruiter open/view?

Example:

All recruiters from AUTOMOTIVE industry, while conducting Resume search for function SALES, opened/viewed following resumes:

Sr No	PEN No	No. of times Viewed	Candidate Data			View
						☐

Would you like a complete digitized version of the entire 6-page set with uniform formatting in Word or PDF?