Kartavya
Abhi
Vicky
Inder
ImageBuilder
– “Career History” Section
I
presume (pl. correct me if I am wrong) that once we launch our Webservice, each
& every email resume received (online or offline) would be “extracted,”
then converted to ImageBuilder version
And
then uploaded on our website. Every single resume.
Then
only, jobseekers can log in (using their password/User ID) and “Edit” it
online.
This
(ability-to-edit-online) feature is very important, because nearly 100% of the
ImageBuilders uploaded would contain a BLANK “Career-History” section!
And
I suppose, we would want the jobseekers to log-in and enter this data online
(and, of course, be able to download too).
Now,
it is quite possible that a jobseeker may log-in & edit once-a-year.
In
fact, we will build an automatic reminder system, which would remind him to do
so.
It
is also quite likely that the candidate has changed his job, when he logs-in to
edit/update.
But
in ImageBuilder, there is provision for only 4 jobs history
(including the current).
So,
now what can concerned candidate do? How can he edit? – Career History section.
Does
he re-enter everything all over again?
Or,
he can go on adding any no. of jobs (career-history), since he is ONLINE and
software does not restrict him? Then again, if ONLINE he can enter even 15
job-history, what would happen when he has to print out his updated
ImageBuilder?
Whereas
I appreciate that ImageBuilder may have restrictions “OFFLINE,” we must ensure
that ONLINE there are no restrictions (on no. of job-history), because, for
each candidate, we want to capture entire LIFE-HISTORY from birth onwards! Pl.
confirm.
(Signed,
09-07-03)
PRIVACY
POLICY VICKY INDER
Kartavya
Abhi
Vicky
Inder
06-07-03
PRIVACY
POLICY
Please
examine the enclosed draft and modify the same if necessary.
After
modifications, please upload on our website (Recruit-Guru) under link.
Privacy
Policy
Allotment
of "User ID / Passwords" to "authorized users" by the
concerned subscriber only (and not by us), would have software code
implications. Please examine these.
06/07/03
Our
privacy policy covers two types of users, viz.:
- Jobseekers
- Webservice
Subscribers
Jobseekers
- Jobseekers
either submit their resumes online or send to us by email and
subsequently, we upload these in our webservice, after converting to
ImageBuilder version.
These
are resumes, submitted to us directly and form part of our resume database. All
of these are treated as "public resumes" and made available to our
subscribers who may get in touch with the concerned jobseekers directly on
their own.
Webservice
Subscribers
- Our
webservice subscribers bring in their own resumes and upload on our
webserver for converting to ImageBuilder version. These are Resumes,
received directly by the subscribers against job-ads released by them on
websites or in print media. Then there could be resumes received by our
subscribers, in an unsolicited manner.
But
in all such cases, these resumes belong to the concerned subscriber and are his
"private" database, although residing on our webserver.
These
resumes (this private database) can be accessed only by the concerned
subscriber and by no one else — not even us! Through appropriate software, we
render these resumes "inaccessible" to everyone else (any visitor to
our website), other than the "users" authorized by our subscriber.
The
"User List" can be created by the subscriber only. Any
addition/deletion to the list can also be carried out by the subscriber only
(through an online ADMIN TOOL). Only the subscriber can allot "User
ID/Password" to each of his "authorized users".
No
user can access the private resume database of a given subscriber without using
these subscriber-allotted "User ID/Password".
WWW.Recruit-Guru.com has no
control over data/info downloaded and/or emailed to anyone, by the
"authorized users" of a subscriber, and we take no
responsibility/liability for such data transfers, whether legitimate or
otherwise.
Names
at top:
Kanuja
Arthi
Vicky
Inder
Heading:
Terms & Conditions – RecruitForm Web-service
I
suggest that both, on the FREE TRIAL Registration Form and on the REGULAR
SUBSCRIBERS Registration Form, we have a statement that reads:
“I
have read the Terms & Conditions and the same are accepted by me” ☑ (check-box)
Unless
the person registering checks the check-box, software must not accept
him as subscriber. A pop-up window should remind him to first read the
“conditions” before clicking on Submit.
I
enclose my draft of our Terms & Conditions, for your perusal and
comments, if any.
Acceptance
of our Terms & Conditions by potential subscriber must constitute an
AGREEMENT between parties.
Question:
Under Project BARTER, my email (drafted to Placement Agencies) says, “We
automatically accept you as a Free Trial…” We will send you your (User ID) after
we receive your FORM accepting EXCHANGE OFFER.
How
to tackle this?
“Terms
& Conditions”
- RecruitGuru
(comprising different modules such as GumMine / GumSearch etc.) is a
pay-per-use web-service, based on Microsoft’s .NET technology and hosted
on www.RecruitGuru.com.
- These
terms & conditions apply to all those who become
- temporary
subscriber (by filling FREE TRIAL registration
form) or
- permanent
subscriber (by filling Regular registration form) of
RecruitGuru.
- Subscribers
will pay for whatever transactions they carry out on our web-service, as
per the tariff chart (Menu Card). RecruitGuru reserves the right to modify
the tariff anytime, by giving 15 days’ notice to the subscribers by
e-mail.
- Subscribers
will be able to execute only those transactions which they have selected
themselves by ticking the appropriate boxes at the time of registration.
Subscriber
would have the facility to add/delete the transactions at any time, after
logging in.
- RecruitGuru
webservice is a prepaid service (much like a
mobile phone prepaid service). As a subscriber carries out each
transaction, the prepaid amount standing to the credit of the subscriber
gets reduced by the value of the concerned transaction. The service will
stop automatically when the balance (of prepaid amount) stands reduced to
NIL/ZERO. Before this event, an email will get sent to the subscriber,
alerting him of the balance amount status and suggesting to make
additional payment through the ADMIN tool.
- There
are three types of payments that a subscriber would need to make in
advance, as follows:
a) Activation Fee - b)
User Fee
- c)
Transaction Fee
Activation
Fee is a one-time/non-refundable fee. Activation Fee need not be paid once
again for reactivation of the service after temporary discontinuation of less
than 6 months.
User
Fee is linked to the number of users authorised to access the service. Once the
number of authorised users is predetermined and the fee paid, new users can be
added and old users can be deleted (from the Authorisation List) as long as the
total number of users remains the same as predetermined.
A
subscriber may, however, increase the number of users by paying additional User
Fee. User Fee is non-refundable. In case of reactivation after discontinuance,
User Fee needs to be paid once again.
As
far as the Transaction Fee is concerned, a subscriber would need to estimate
his expenditure in advance and pay accordingly. This fee is non-refundable,
even if the subscriber chooses to discontinue our webservice before the
transaction-fee balance amount gets reduced to NIL/ZERO. This amount gets
lapsed/forfeited and cannot/will not be carried forward as a “credit” in cases
of reactivation after discontinuance.
- Whereas
RecruitGuru will take utmost care and put in best effort to provide a high
standard/level of service, we do not assure/promise/guarantee or undertake
to deliver a service as expected/desirable by a subscriber.
- RecruitGuru
cannot and does not guarantee correctness or up-to-datedness of any
detail/information provided and/or posted by any subscriber or any
jobseeker or any third-party data/information posted/uploaded by
RecruitGuru on its own.
RecruitGuru does not assume/accept
responsibility or liability for any
misleading/lying/fictitious/mischievous/incorrect/malicious/incomplete
data/information posted/made available by subscribers and/or jobseekers. Users
are solely and entirely responsible for the consequences of such information
usage and unconditionally absolve RecruitGuru from any
grievance/harm/loss/damage arising out of such usage or implications. This
equally applies to any misstatement/misrepresentation of data that RecruitGuru
may have carried out, especially in respect of:
- Functional
Exposure Profile
- Career
Progression Profile
- Designation
Profile
- Salary
Profile
- Job
Market Profile
- etc.
etc.
…and
a host of similar profiles, involving jobseekers/subscribers etc. It is
strictly up to the users to draw whatever conclusions/deductions/inferences
they wish to arrive at, by use of such
information/reports/representations/comparative profiles. Whether graphical or
tabulated, or under no circumstances whatsoever, shall RecruitGuru be held
responsible for any consequences, real or imaginary, arising out of such usage.
Whereas RecruitGuru will not grant/permit
access/usage of one subscriber’s private resume database to any other
subscriber, through deployment of appropriate software-based
firewalls/barriers, RecruitGuru cannot take any responsibility in this regard.
On
its own, RecruitGuru will neither access nor use the private resume database of
any subscriber except for the purpose of compiling various profiles such as
functional exposure profiles, salary progression profiles, career progression
profiles, population/key word profiles etc. Our software will use the relevant
values from the resume database(s) of subscribers. At no time, however, will
RecruitGuru link these extracted values to a given resume or a given name or a
given job-description or any such/similar document.
- RecruitGuru
reserves the right to add/delete/modify/alter any of these conditions,
without having to notify the users/subscribers.
- RecruitGuru
reserves the right to admit or not to admit any individual and/or
corporate body as a subscriber of its webservice, if RecruitGuru feels, at
its sole discretion, that this would go against its interest or against
the larger interest of its other subscribers. If necessary, RecruitGuru is
not required to provide an explanation of its decision not to admit a
person/corporate body as its subscriber.
WEB-SERVICE
PROVISIONING
30
June 2003
WEB
SERVICE PROVISIONING
When
we adopt a “pre-paid, pay-per-use” model for our webservice, we are accepting a
legal liability to our clients, to deliver “X” amount/value of “Services”
(measured in, no. of transactions x tariff rate).
It
is nice to have a “negative customer outstanding /a negative working capital,
but this model carries responsibilities / liabilities.
On
our balance sheet, “Cash Inflow” & “Income” are two different things.
“Income” is only the services actually delivered, at any point of time.
Cash
Inflow-Services delivered =Balance Liabilities.
Please
read enclosed notes for implementation.
All
of these must be done in V.I.O> itself.
Never
mess around with your financial matters.
Be
crystal clear / transparent from day one!
SUMMARY
TABULATIONS
Temporary
Registration for FREE TRAIL
|
1 |
2 |
3 |
4 |
5 |
6 |
|
Sr. No. |
Company Name |
City |
Executive Name |
Executive Designation |
Date Register |
|
Chronologically |
For
placement Agencies, this date will be the date on which, they send us their
(EMAIL) ACCEPTANCE FORM for our BARTER SCHEME.
Please
ensure that whatever data/fields are required to be filled-in for
“FREE
TRAIL” FORM
Are
also incorporated in the
“BARTER
ACCEPTANCE” FORM
We
have decided to treat every BARTER ACCEPTOR as an “Early Adopter” and
automatically show his name on “List of Early Adopters” page.
Column’s
1, 2 & 3 can be made visible to all VISITORS to our website.
Column’s
4,5 & 6 only we can see
Statistics
(FREE TRIAL)
We
would need to know following fig’s.
- How
many joined
- How
many completed “Free Trail”
- Out
of those, who completed “Free Trial”,
· How
many converted to “Regular subscriber’
· How
many “backed –out” altogether after trial.
(We
need to know the “yield %”). We need to create an ongoing separate database of
companies which backed out after free trial, so that we can launch an email
campaign to “convince” them & get feedback from them re: “Why”?
And
we need to get this info for
· Any
day (of any month)
· Any
month (of any year)
· Cumulative
(within a month)
· Cumulative
(within a year)
After
first month (viz: Sept.), both, “Free Trial” registrations and “Regular”
registrations, would be taking place simultaneously, every day.
So,
we must have similar 2 graphs for “Regular Registrations” also.
FINANCIAL
SCREENS
|
Data picked-up from free Trial Form |
Data picked up from Regular regi. form |
Asutosh to enter this column upon
receipt of cheque/DD |
||||
|
Sr, No. |
Company Name |
Free Trial Registration |
If became Regular Subscriber |
|||
|
Start Date |
End Date |
Cheque/DD No. & date |
Amount Rs. |
Asutosh created on date |
||
Money
comes in only when companies who have registered for FREE TRIAL, become regular
subscribers, at the end of the trial (or even before 30 days are over), by
sending chaque/DD & entering these details (check No/DD No. / Date
Amount/bank drawn on etc.) in the
Regular
Registration Form
From
these details, a tabulation, as shown on P=3, must get automatically generated,
as soon as a corporate fills-up the regular Registration form only the last
column will remain blank, until Asutosh received the cheque/DD thru courier.
When
he does using his password, he will access. This tabulation & enter the
“date” in last column.
But
the tabulation will also be accessible to kartayvya / Abhi / HCP / NHP who can,
look-up & find out at a glance what “amount” of payments are dispatched /
in pipe-line but still not received.
If
it is more than 7 days, since dispatch of cheque / DD / by corporate (we insist
thru courier),then Abhi can/must pick-up phone & talk to the client, saying
we have not received the cheque so far! He should decide, based on clients
feedback, whether to allow client to continue to use our webservice or to
suspend it temporarily & send an email to client accordingly.
“Overall”
subscription amount to be broken –up as
- Activation
Charges – Rs. 5000/- per Member corporate
- No.
of Licenses charges – Rs. 1000/- per person authorized
- Transition
Charges – Whatever amt Member chooses to pay
From
total of “actual transactions” carried-out by all members, in a given month, we
can arrive at,
“Balance
value of Transaction services charge”
Remaining
to the credit of :
· A
particular Subscriber:
This
is what a particular subscriber would like to see-as a monthly tabulation:
· All
subscribers put together:
This
is what we would like to see at any point of time, in a graphical manner.
For
us this “Balance Amt” represents the “value of Services” yet to be delivered by
us.
It
(this amount) is, kind of a “Liability of the company.
(Cash
Inflow – value of services delivered)
=
Balance liability of company
We
should be able to see/view this for any particular customer or for all
customers put together
AND
As
on any date.
Webservice
Pricing” (Oct. 3, 2003)
cc:
Kartanya / Abhi
|
Period |
5%
increase every 6 months |
10%
increase every 12 months |
|
6
mo |
105 |
100 |
|
12
mo |
110.25 |
110 |
|
18
mo |
115.8 |
110 |
|
24
mo |
121.5 |
121 |
|
30
mo |
127.6 |
121 |
|
36
mo |
134.0 |
133 |
Sanjeev
Webservice Pricing
- See
enclosed report on how cell-tariffs are, once again, inching up, after
dropping for last 3 years.
- In
context of our webservice, remember following guidelines:
• Smaller increases at more frequent intervals are more digestible than a big increase every few years (or every year).
• You should not increase prices of all transactions at the same time. You should do this “rotation” — so, if you have 12 “chargeable” buttons, you raise the price of only ONE button each month! So you end up increasing…prices of all buttons only once a year! - All
price-increases (whenever made/announced) must not be same fixed
percentage. One button, you may increase by 3% in January, second button
by 5% in February, third button by 7% in March, and so on.
- In
between, in a particular month or quarter, you may not announce any
price-increase for any button but you may transfer some one button from
FREE to PAID category.
- Then
in some month, you may be adding an altogether NEW button (new
functionality) which is PAID. In such a month, you must not increase price
of any other button.
- Many,
many organisations have failed to develop a mechanism whereby they can
quickly and easily differentiate between:
- •
the increase/growth in the company’s annual revenue due to
VOLUME/QUANTITY; and
• the increase/growth in the company’s revenue due to SELLING-PRICE increase.
This is a
dangerous/misleading situation!
Let us say
RecruitGuru’s Net Collection goes up from Rs. 1 crore (in present year) to Rs.
1.5 crore (in next year).
That is a growth of
50%!
But is that a reason
to be overjoyed?
This increase could
have been:
- A
→ entirely due to increase in Selling-Price only (i.e., no increase
in VOLUME/QUANTITY)
- B
→ entirely due to increase in VOLUME/QUANTITY only (i.e., no
increase in Selling-Price)
- →
due to some increase in Selling-Price & some increase in VOLUME (No.
of transactions)
In real business
life, you rarely come across situations A or B. Mostly it is C.
In fact, the most
likely situations are:
- D
→ Increase in Selling Price / Decrease in Volume or
- E
→ Increase in Volume / Decrease in Selling Price
So a Company’s
performance must not be judged simply based on %age growth in revenue over the
previous year.
It is very, very
important to know how this growth came about! What factors contributed to this
growth and how much was the contribution of each factor?
This Volume
Variance/Price Variance analysis should be done not only at the overall company
level but also at the level of each subscriber as well.
So, whereas ARPU
(Average Revenue Per User) and specific individual revenue growth for each
client are useful criteria, we must know at each subscriber-level:
- Is
his volume usage growing & contributing to increased billing? — and
how much?
Increase in
selling-prices are like inflation (consumer price index).
A business can simply
increase its product-prices by 15% each year and show a revenue growth of 15%
each year without selling even one piece more, year after year.
Shareholders, employees and the bankers may be misled by such figures.
…results and the
share-price will keep rising, until someday the company is UNABLE to
raise its prices due to increased competition! Then will be the year of
reckoning! The bubble will burst!
So for a
healthy/sustainable growth, both the Volumes and the Prices must
rise, to contribute to overall growth. And we must be able to monitor
separately the effect/impact of both the volume-induced revenue growth and the
price-increase-induced revenue growth, year after year.
For RecruitGuru, we
will use the first FULL YEAR (viz. April 2004–March 2005) as our datum / the
base year and compute for each subsequent year as follows:
|
Base
Year 2004/2005 |
2005/06 |
2006/07 |
|
|
Gross
Net Collection (Rs. L) |
Rs.
150L |
200 |
300 |
|
Index
(Gross) |
100 |
133 |
200 |
|
No.
of Trans. |
5
Lakh |
6
Lakh |
8
Lakh |
|
Index |
100 |
120 |
160 |
Then this can be
plotted as follows:
(sketched graph)
- Y-axis
index from 100 upwards
- X-axis
years 2004/05 – 05/06 – 06/07
- Net
Collection rising to 133 then 200
- Transaction
Volume rising to 120 then 160
- Additional
growth due to Selling Price Increase indicated as a vertical segment.
Or, depending upon
figures, graph may turn out like:
(second sketch)
- Y-axis
index from 100 upwards
- X-axis
years 2004/05 – 05/06 – 06/07
- Transaction
Volume line steep (to 200)
- Selling
Price line shallower (to 140)
- Additional
growth due to increase in volume of transactions indicated.
(02/03/02)
Abhi
Vinay
Sanjeev (circled)
Redesign
of Module 1
(Searching
MEMBER + NON-MEMBER database)
I
enclose a few pages from my notes sent to Cyndi in Aug/Sept. ’98 (3½ years
back).
As
we are in the process of redesign of Module 1 (database/search
engine/shortlisting/migration to Excel sheet/migration to OES/composing &
automatic emailing of jobs/vacancies/covering letters etc.), you may find these
old notes useful/relevant.
Pl
apply your mind & be ready with your views/suggestions, whenever we meet on
11/3.
SEARCH
QUERY (1)
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
PEN
or NAME |
“Janam-Kundli”
of concerned executive including “search-parameters” chosen for self |
|
Designation |
All
executives in our database (including NON-MEMBERS) with that designation;
arranged in descending order by “ACE” (must carry synonyms / designation
rings) |
|
Industry |
All
executives in our database (who have “ACE” in that “Industry” / “Vertical” /
“Ministry” in that self-search parameter) |
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
FUNCTION |
All
executives in our database (incl. NON-MEMBERS) who have specified this
“Function” as their “1st/2nd Function” in their self-select parameter;
arranged in descending order of age. Must cover synonyms/similar functions. |
|
EDUCATION |
All
executives in our database (incl. NON-MEMBERS) who have this Education;
arranged in descending order of age. Must cover similar qualifications
(synonyms). |
|
LANGUAGE |
All
executives who can “speak” this language (descending order of age). |
|
PRODUCT
/ SERVICE |
All
executives who claim to have exposure to this product/service. List also
those who have mentioned this FIRST (+ synonyms), SECOND (+ synonyms), THIRD
(+ synonyms). |
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
COMPANY
NAME (CURRENT) |
All
executives working in this company. List A → Those registered with us. List B
→ Non-Members. Columns arranged in descending order of “designations” (e.g.,
CMD, MD, CEO, President, EVP, VP, GM…). |
|
CITY
NAME (STATE/COUNTRY OPTIONS) |
All
executives posted in this city. List A → Those registered with us. List B →
Non-Members. |
|
COMPANY
NAME (PAST EMPLOYMENT) |
Any
executive who has ever worked in this company. List A → Those registered with
us (also period of working in that co.). List B → Non-Members. (Arrange in
descending order of designation). |
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
GROSS
ANNUAL SALARY |
•
Year-wise lists |
SEARCH
QUERY (5)
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
KNOWLEDGE
/ SKILL / ATTITUDE / ATTRIBUTE words |
•
All executives who have entered this “word” in his self-search parameter |
SEARCH
QUERY (6)
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
(continuation
from previous page) |
•
Subsequent “Knowledge-base” which will gradually evolve over a period of
time. Then use Context Cartridge option or the ARDIS Fuzzy Logic. |
SEARCH
QUERY (7)
|
If
you enter this SEARCH PARAMETER |
OUTPUT
SCREEN / PRINTOUT WILL DISPLAY THIS |
|
FOR
FRESH GRADS / FINAL YEAR STUDENTS |
–
(Ref. see my notes dated 13/11/98, 2/12/97) |
Your handwritten notes (right margin)
7-11-98
“April
I would request you to collect additional info about these products from
Oracle’s site and evaluate with a view to examine their suitability to our own
business.
These
products may not transform our applications but the principles upon which these
are based / formulated are dear to our hearts, viz.:
- NO
(or very little) human intervention – automatic order entry &
confirmation
- automatic
“form” – standardisation (several locations / of candidates)
- Money
transfer (as convenience)
- Body
and cost of jobs (client letters)
- New
variables
- Product
modification (some addition)
- Web-based
relations with candidates / clients
- Web-based
“Status Reporting” & order execution (Module #2)
I
have already brought out some of these points in my enclosed notes prepared
last week – in connection with our plans to change over to a new ESP
(Oracle+NT) based by Nov. 1998, then to complete 1 year on the Canadian
server.”
GURUSEARCH SCREEN
4 Sep 2003
GURUSEARCH SCREEN
Abhi/Inder/Sanjeev/Raju/Sriram,
Present UI is not very intuitive. It is a bit cluttered and
looks quite like other jobsites.
We want recruitguru to “differentiate” from all other
jobsites-in as many respects as possible so that corporate do not confuse us
with other jobsites! We have to be in a class of our own.
Enclosed find & alternatives of search screen.
No. 1 – Only a little more “rational” grouping
No. 2 – Brings focus to “Function” & “Percentile” which
is our USP & this is where we would, ideally, want a corporate to
start/being his search.
Perfectly, only after he gets to see the “results” based on
col#1, he should move right – to col#2 -#3
No. 3 – Here col#1 is same as in option #2 some interchange
is made in middle & extreme right column.
No. 4 – This vertical flow alternative –with explanatory
notes on the right hand side, is I feel, the best alternative. It provides the
“rationale” behind the correct/ideal
It is like leading a child with finger! Step-by step, in the
right direction & in correct “Order”/with least confusion/without having to
“back-track”-in case you get into wrong lane/dead-end street.
Please consider implications with your team then let us
decide.
“For
Best Results, Refine/Filter the Power-Search”
Source
Type:
- Database
- RecruitGuru
- My
Database
- My
Candidates
Function:
- Software
Design
- Executive
Search
- Systems
Design
[Search]
[Clear]
Reason
why you cannot go into resumes directly:
You
may access resumes under one or more names (say V.P. Systems Design). But you
want to shortlist only those candidates who are experts in your chosen
FUNCTIONS / SKILLS / KNOWLEDGE.
You
do not want just resumes. You want to shortlist competence, not resumes!
This
allows you to separate / eliminate:
- Fakes
from the Internet
- Boys
from Pretenders
- Boys
from Men
- Gold-Medalists
from “Also-rans”
Refine
With:
Education
(Graduate Degree / Post Graduate Degree / Diploma / etc.)
Experience
From ___ To ___
Age From ___ To ___
[Search]
[Clear]
At
this stage, your Company-Policy may say “Hey we want a B.E. (Electronics) &
5 years’ exp. Or B.Sc. (Physics) & 8 years’ exp.” By giving this in
Knowledge-Base window, you specify that you want “Deep Sea Divers” not “Shore
Divers.” This is your place to specify / precise.
Filter
With:
[Check
boxes for Education / Experience / Age / Function]
We
are getting closer/shortlist is reasonably there but if this position is in
Mumbai we don’t want Bangalore guys (canvass).
If
this position is “Vice President” level we should interview people who are
currently “General Manager.”
Why
go through this elaborate filtering? — Because it saves time and lets you zero
in on the right candidate pool.
