Most Common Mistakes🔗︎
1. Not using category weights🔗︎
The most common integration mistake is to not use category weights to fine tune the results. Customers will execute a match with the default values, Textkernel will calculate default weights based on the data provided, and return the results it believes are the best. As the integrator you have much more specialized knowledge into the specific transaction and typically know more about what data points are important. For example, we recently had a customer that compared our matching to an internal process they already had for candidates and were not initially satisfied with the results of the engine compared to that of their internal process. We setup a call to discuss and discovered that they were only evaluating candidates based on job titles and skills. We then coached them on setting the Category Weights to reflect the same criteria, and the results were then superior to their internal system. The key was that the default weights were taking into account other pieces of information such as Certifications, Management Level, and Education that weren't of interest to the client. Make sure you take the time to understand category weights and reach out to support@textkernel.com with any questions.
2. Filtering documents prior to the request🔗︎
When recruiting, it's common to need to reduce the candidate pool based on certain criteria. For example, a temporary staffing company is trying to fill a role that starts tomorrow, and only wants to see candidates that have already made it through their onboarding process. This allows their recruiters to pursue candidates that are ready to start the position immediately and makes the recruiters more efficient; however, this information isn't available from the resume and is only stored in their database. It's a mistake to calculate the list of candidates in your database and attempt to pass massive amounts of document ids into the filter. Instead, you should index the data points needed for filtering as custom values, and filter those in real-time during the matching transaction. In this example, you would index a term for each document representing the status of that candidate in the ATS.
3. Small candidate pool🔗︎
When the top candidate in a matching transaction has a really low score, it's a mistake to automatically assume there was an issue with the query. The Search & Match Engine evaluates many data points to determine the best candidate in the index, but sometimes that candidate is still a poor fit. This is most typical when working with smaller sample sizes, but it still can happen in larger document sets if they are spread across many industries or have very restrictive filters. Textkernel doesn't scale scores up because the top candidate isn't a good fit; instead, we report the score exactly as calculated to further show the we agree the candidate didn't score well.
4. Thinking indexes are your database🔗︎
Textkernel's Search & Match indexes are only intended to be used for searching/matching, and not to be used as your database. You must store the parsed documents in your system and keep track of what has been sent to the index. You should never need to retrieve a parsed document from an index or need the list of ids in the index. You completely control all CRUD operations to the index and need to keep track of that status.