Notes: RESUME RATER V3.0 GOOGLE DESKTOP VERSION

Sunday, 6 January 2008

RESUME RATER V3.0 GOOGLE DESKTOP VERSION

Rahul

Resume Rater V 3.0

06/01/08

We discussed this yesterday.
It has the potential to become a killer App.
We can develop it using Google Desktop API—in which case Google will host it on their own website! This can popularise RR V3 in a very big way, around the World.
I am in two minds – whether to develop RR V3.0 as,

totally separate version, based on Google desktop.

integrate Google Desktop –as an additional feature– into V2.0, leaving intact all the existing features of V2.0.

I think you will be the best person to judge this issue from technology application viewpoint.
From recruiters/users perspective, it would...

...be better if he has to install only ONE version, whether he wants to search & rate resumes lying in

a specific folder

on entire harddisk

eg: two clickable buttons of our main page U/I of RR

After you have downloaded Google Desktop, it will take, from a few minutes to a few hours, to index the content of your harddisk. Of course, this is a onetime/firsttime effort.

Search-results should be displayed as per our existing display-grid, in the descending order of raw-scores.

One more thought.

Today, we are dependent upon user resetting the counter, in order for our website counter to change.

How can we eliminate this "dependency"?

Can our counter change, as soon as user clicks on some button? eg: [SAVE Results]

But then, he may not be online at that time!

Nor can we reduce the "reset-limit" from 1000 to (say) 100!

Chances are, there may be 10,000 resumes on his harddisk—all of which, he wants searched/rated—simply because he is too lazy to select any particular folder.

In fact, the very idea (behind integrating Google Desktop in V3.0) came from the fact that a typical recruiter can only remember the folders that he has created during last 10/15 days—at most.

Whereas, the best resumes may be lying hidden in folders that he created 2 months / 4 months / 8 months ago!

Who, the hell has time/patience to search thru 69 folders created during last 12 months, to find & select, those one/two, which are likely to yield best resumes?

This is simply too much to ask!

This is enormous "process-friction", which limits the benefits of RR V2.0. This is why we need Google Desktop.

Which means, even the current "reset" limit of 1000 may not work! will not work!

We will need to raise it to 50,000! We just don't know, how many resumes are lying on the harddisk of a WIPRO/Infosys/IBM/Accenture recruiter!

Of course, I don't expect "rating process time" to increase appreciably because, like ISYS, Google Desktop has already indexed all documents—and against each document, created a database of several hundred "words".

Altogether several million—or a billion—words.

So finding takes a few seconds at most (see how fast ISYS does it).

Maybe we can employ "reset counter"...

...only when a user uses [specific folder] to rate.

and

use some automatic (counter updates) process when he uses [Rate entire Harddisk] option.

Another thing.

In RR V 3.0, can we "harvest" entire resume, instead of merely harvesting email ID?

Of course, we don't want to harvest all 50,000 resumes on harddisk, again & again 10 times in a day, if a user [rates entire harddisk] 10 times a day, for (in sequence):

— Java

— Asp

— VB

— Ajax

— Windows etc. etc.

But, conceivably, during (or at the end of each rating process), we could harvest only those resumes, which scored 60.

This will eliminate most of "duplication".

Obviously, during each rating, the no. of resumes scoring $\ge$ 60, will vary, from a few to a few dozen which is ok.

We will create, on our webserver

— 86 IT skill folders

— 43 Non-IT skill folders

and,