Cải thiện Mô hình Dữ liệu Cổng Thông tin Việc làm Trực tuyến của Chúng tôi

Trong thời đại cạnh tranh gay gắt như hiện nay, các cổng thông tin việc làm không chỉ là nền tảng để xuất bản và tìm kiếm việc làm. Họ đang tận dụng các dịch vụ và tính năng tiên tiến để giữ chân khách hàng của họ. Hãy đi sâu vào một số tính năng nâng cao và xây dựng mô hình dữ liệu có thể xử lý chúng.

Tôi đã giải thích các tính năng cơ bản cần thiết cho một trang web cổng thông tin việc làm trong một bài viết trước. Mô hình được hiển thị bên dưới. Chúng tôi sẽ coi mô hình này là cơ sở, chúng tôi sẽ thay đổi mô hình này để đáp ứng các yêu cầu mới. Trước tiên, hãy xem xét những yêu cầu (hoặc cải tiến) này nên là gì.

Chúng tôi đang thêm gì vào Mô hình Dữ liệu Cổng Việc làm Trực tuyến?

Tóm lại, chúng tôi sẽ thêm bốn cải tiến cho mô hình dữ liệu cũ của chúng tôi:

1. Trang tổng quan cá nhân dành cho người tìm việc. Điều này giúp theo dõi tất cả các đơn xin việc của họ và cung cấp thông tin cập nhật theo thời gian thực về bất kỳ thay đổi trạng thái nào (tức là đơn đăng ký thay đổi từ khi được nhận thành được xem xét).
2. Trang tổng quan về Tiểu sử. Phần này thông tin chi tiết về những người đang truy cập hồ sơ của người tìm việc và số lần hồ sơ của họ được tải xuống trong ngày, tuần hoặc tháng qua.
3. Quản lý dịch vụ trả phí. Các cổng thông tin việc làm thường cung cấp các dịch vụ như chuẩn bị sơ yếu lý lịch cho chuyên gia, quản lý hồ sơ xã hội, tư vấn nghề nghiệp, v.v. Các chức năng mới của chúng tôi sẽ có thể hỗ trợ các dịch vụ trả phí.
4. Quản lý Biểu mẫu Trước khi Đăng ký. Khi các ứng viên nộp đơn xin việc, họ có thể được yêu cầu điền vào một bảng câu hỏi ngắn liên quan đến thời gian làm việc, địa điểm và kiểm tra lý lịch. Chúng tôi sẽ xây dựng theo cách để các nhà tuyển dụng tùy chỉnh biểu mẫu này cũng như hệ thống thu thập các câu hỏi và câu trả lời.

Cải tiến # 1:Trang tổng quan cá nhân

Câu hỏi cần trả lời: Tình trạng hiện tại của đơn đã nộp là gì? Nó có được lọt vào danh sách phỏng vấn không? Nó thậm chí đã được xem chưa?

Chúng tôi có thể theo dõi các đơn xin việc bằng cách đặt job_application_status_id trong job_post_activity bàn. Cột này chứa tình trạng hiện tại của một đơn xin việc. Chúng tôi cần tạo một bảng khác, job_application_status , để giữ tất cả các trạng thái ứng dụng có thể có. Một số trạng thái có thể là "đã gửi", "đang xem xét", "đã lưu trữ", "bị từ chối", "lọt vào danh sách phỏng vấn", "đang trong quá trình tuyển dụng", v.v.

Một bảng mới khác, job_post_activity_log , lưu trữ thông tin liên quan đến tất cả các hành động được thực hiện trên đơn xin việc, người đã thực hiện hành động và thời điểm nó được thực hiện. Bảng này chứa các cột sau:

• id - Khóa chính của bảng.
• job_post_activity_id - ID ứng dụng mà hành động được thực hiện.
• job_post_action_id - ID của hành động được thực hiện. Đây là khóa ngoại liên kết đến job_post_action bàn. Các loại hành động mà chúng tôi có thể lưu trữ ở đây bao gồm "đã gửi", "đã xem", "đã phỏng vấn", "đã thực hiện bài kiểm tra viết", "đề nghị đang xử lý", "đề nghị đã gửi", "đề nghị được chấp nhận", v.v.
• action_date - Ngày thực hiện một hành động.
• user_account_id - ID của người đã thực hiện hành động.

“job_post_action” có giống với “job_application_status” không? Chúng khác nhau như thế nào?

Thoạt đầu chúng có vẻ giống hệt nhau, nhưng chúng thực sự khác nhau. Có những lý do hợp lệ tại sao chúng ta cần hai trường giống nhau:

1. Một ứng viên được phỏng vấn bởi hai hoặc nhiều người riêng biệt. Trong trường hợp này, tình trạng đơn xin việc vẫn giữ nguyên (tức là "đang trong quá trình tuyển dụng") cho đến khi tất cả các vòng phỏng vấn hoàn tất. Tuy nhiên, hồ sơ cho từng người phỏng vấn riêng lẻ được chèn vào job_post_activity_log và họ có hành động "được phỏng vấn".
2. Nhiều nhà tuyển dụng trong cùng một công ty có thể xem một đơn đăng ký. Bằng cách sử dụng hai thuộc tính này, bạn sẽ không mất thông tin của người đăng ký.
3. Đưa ra đề nghị cho một ứng viên đã chọn phải có nhiều phê duyệt (nghĩa là phê duyệt từ nhóm tài chính, phê duyệt từ người quản lý bộ phận tuyển dụng, v.v.). Trong trường hợp này, trạng thái của đơn xin việc vẫn là "đề nghị đang xem xét", nhưng cơ sở dữ liệu có thể ghi lại những phê duyệt nào đã được thông qua và những phê duyệt nào chưa qua job_post_activity_log bảng.

Cải tiến # 2:Trang tổng quan hồ sơ

Câu hỏi cần trả lời: Ai đã tìm thấy hồ sơ của tôi gần đây? Nhà tuyển dụng đã xem nó bao nhiêu lần trong tháng, tuần hoặc ngày trước? Các nhà tuyển dụng từ các công ty hàng đầu có xem hồ sơ của tôi không?

Câu trả lời cho tất cả những câu hỏi này có trong profile_visit_log bàn. Bảng này ghi lại tất cả dữ liệu lượt truy cập hồ sơ, bao gồm ai đã truy cập hồ sơ, thời điểm xem hồ sơ, v.v. Các cột trong bảng này là:

• id - Khóa chính của bảng.
• seeker_profile_id - Hồ sơ nào đã được truy cập.
• visit_date - Khi hồ sơ được truy cập.
• user_account_id - Ai đã xem hồ sơ.
• is_resume_downloaded - Cột cờ biểu thị nếu sơ yếu lý lịch liên quan đã được tải xuống trong chuyến thăm. Cột này sẽ giúp chúng tôi xác định số lần một bản sơ yếu lý lịch được các nhà tuyển dụng tải xuống.
• is_job_notification_sent - Một cột cờ khác, cột này cho biết liệu thông báo việc làm đã được gửi đến chủ sở hữu của hồ sơ hay chưa.

Cải tiến # 3:Quản lý dịch vụ trả phí

Câu hỏi cần trả lời: Làm cách nào để các cổng trực tuyến có thể tận dụng các dịch vụ bổ sung có tính phí?

Bên cạnh nền tảng đăng và tìm kiếm việc làm, nhiều cổng thông tin trực tuyến cung cấp các dịch vụ khác, như chuyên gia xây dựng sơ yếu lý lịch, tư vấn nghề nghiệp, v.v. Họ cũng cung cấp các sản phẩm để giúp người tìm việc tìm được công việc mơ ước tại thành phố mơ ước của họ. Ví dụ:một trong những trang web việc làm hàng đầu cung cấp sản phẩm giúp hồ sơ của bạn luôn nằm trong top đầu danh sách của nhà tuyển dụng để bạn có thể nhận được nhiều lời mời phỏng vấn hơn. Hầu hết các sản phẩm hoặc dịch vụ này đều có sẵn trên cơ sở đăng ký. Khi người dùng mua một dịch vụ hoặc sản phẩm, họ trả tiền trong một khoảng thời gian cụ thể (tức là một tháng, ba tháng, một năm) để sử dụng sản phẩm hoặc dịch vụ đó.

Khi tôi nhìn vào các cổng thông tin việc làm này, tôi nhận thấy rằng hầu như không có bất kỳ sản phẩm hoặc dịch vụ nào được cung cấp riêng lẻ. Phần lớn, nhiều sản phẩm và dịch vụ được gộp lại với nhau thành một gói và gói này được cung cấp cho người tìm việc hoặc người tuyển dụng.

Tính đến tất cả những điểm này, tôi đã đưa ra mô hình dữ liệu sau để kết hợp các dịch vụ và sản phẩm trả phí vào trang web việc làm trực tuyến hiện có của chúng tôi:

product bảng chứa thông tin chi tiết về các sản phẩm riêng lẻ. (Chúng tôi sẽ gọi cả sản phẩm và dịch vụ là “sản phẩm”). Các cột trong bảng này là:

• id - Khóa chính của bảng này, cung cấp một ID duy nhất cho mỗi sản phẩm được cung cấp trên cổng thông tin của chúng tôi.
• product_name - Giữ tên của sản phẩm.
• product_desc - Lưu trữ mô tả ngắn gọn về sản phẩm.
• inception_date - Ngày giới thiệu sản phẩm.
• is_active - Sản phẩm có đang hoạt động hay không.

Vì các sản phẩm và dịch vụ có thể được gộp lại với nhau trong một gói và được cung cấp cho khách hàng, tôi đã tạo product_bundle bảng để lưu trữ các bản ghi của tất cả các gói như vậy. Các thuộc tính là:

• id - Khóa chính của bảng, cung cấp một ID duy nhất cho mỗi gói sản phẩm.
• product_bundle_name - Lưu trữ tên của gói.
• inception_date - Ngày giới thiệu gói.
• is_active - Cho biết một gói có đang hoạt động hay không.
• subscription_cost - Lưu trữ giá yêu cầu cho gói.

Có thể cung cấp một sản phẩm duy nhất cho khách hàng không?

Đúng. Trong mô hình dữ liệu này, một sản phẩm có thể là "gói" của riêng nó. Các bảng sau xử lý điều này và một số chức năng quan trọng khác.

product_bundle_map bảng lưu trữ danh sách tất cả các sản phẩm là một phần của gói. Các thuộc tính của nó là tự giải thích.

Bảng tiếp theo, product_subscription , phát huy tác dụng khi khách hàng đăng ký gói sản phẩm. Nó ghi lại các chi tiết mà khách hàng đã ghi chép vào gói nào. Các cột trong bảng này là:

• id - Khóa chính của bảng.
• user_account_id - Người dùng đã mua gói.
• product_bundle_id - Gói sản phẩm do người dùng mua.
• purchased_on - Ngày mua.
• subscription_start_date - Ngày bắt đầu đăng ký. Lưu ý rằng ngày mua sản phẩm và ngày bắt đầu đăng ký có thể khác nhau. Do đó, chúng tôi có hai cột khác nhau cho các cột này.
• subscription_end_date - Khi đăng ký sẽ kết thúc.

Bảng cuối cùng, product_offering , được sử dụng chủ yếu để tiếp thị. Thông thường các cổng thông tin việc làm phân tích các hoạt động gần đây của người dùng (cả người tìm việc và nhà tuyển dụng), sau đó quyết định sản phẩm nào sẽ có lợi cho người dùng nào. Sau đó, họ sử dụng email hoặc cuộc gọi điện thoại để liên hệ với khách hàng với các dịch vụ đã chọn. Các cột cho bảng này là:

• id - Khóa chính của bảng.
• user_account_id - Người dùng mà cổng thông tin việc làm đang nhắm mục tiêu.
• product_bundle_id - Gói sản phẩm mà nhà tiếp thị cổng thông tin đã khớp với người dùng.
• is_email_notification_sent - Liệu một email liên quan đến việc cung cấp sản phẩm đã được gửi đi chưa.
• last_email_sent_date - Lần cuối cùng người dùng nhận được email sản phẩm từ nhóm tiếp thị. Các nhà tiếp thị thường gửi nhiều thông báo cho một người dùng và gửi các thông báo khác theo định kỳ. Cột này lưu trữ ngày gửi thông báo cuối cùng.
• is_call_briefing_done - Liệu khách hàng có nhận được một cuộc điện thoại thông báo cho họ về sản phẩm hay không.
• last_call_date –Ngày của cuộc điện thoại gần đây nhất. Có thể có nhiều cuộc gọi (cuộc gọi tiếp theo) được thực hiện cho khách hàng.

Cải tiến # 4:Quản lý Biểu mẫu Trước khi Đăng ký

Câu hỏi cần trả lời: Làm cách nào để nhà tuyển dụng có thể nhận được biểu mẫu đồng ý tùy chỉnh do tất cả các ứng viên tiềm năng điền vào?

Nhiều lần, người tìm việc phải trả lời các câu hỏi cụ thể khi họ đăng ký ứng tuyển. Điều này thường bao gồm những thứ như đồng ý kiểm tra lý lịch tư pháp. Tuy nhiên, có thể cần nhiều loại đồng ý khác. Ví dụ, một công việc trong lĩnh vực tiếp thị có thể phải đi lại nhiều; các công việc trong gia công quy trình kinh doanh (BPO) có thể yêu cầu nhân viên làm việc theo ca (tức là đêm khuya). Những điều này được giải quyết trong các mẫu đơn đăng ký trước.

Tốt nhất bạn nên nhận được sự đồng ý khi nộp hồ sơ xin việc. Bằng cách này, các ứng viên không muốn đáp ứng các yêu cầu này sẽ không nộp đơn vào công việc.

Trước khi chuyển sang mô hình dữ liệu, trước tiên hãy để tôi làm nổi bật một số thông tin cơ bản về biểu mẫu đồng ý:

• Một bài đăng tuyển dụng có thể có nhiều biểu mẫu đồng ý.
• Mỗi biểu mẫu đồng ý có nhiều câu hỏi khác nhau liên quan đến các phần khác nhau.
• Một câu hỏi có thể được đặt là bắt buộc hoặc tùy chọn, tùy thuộc vào cách câu hỏi được gắn thẻ trong biểu mẫu. Một câu hỏi có thể là tùy chọn ở một dạng và bắt buộc ở dạng khác.
• Mỗi câu hỏi có thể được trả lời là (1) có, (2) không hoặc (3) không áp dụng.
• Tất cả các câu trả lời sẽ được ghi lại.

Tôi đã sử dụng bốn bảng sau để quản lý câu hỏi và biểu mẫu đồng ý. Đầu tiên, question bảng, chứa một danh sách các câu hỏi. Nó có các thuộc tính sau:

• id - Khóa chính của bảng, cung cấp một số ID duy nhất cho mỗi câu hỏi.
• question_text - Lưu trữ văn bản câu hỏi thực tế.
• question_section_id - Phần xuất hiện câu hỏi. (Ví dụ:“Bạn đã làm việc trong lĩnh vực phát triển phần mềm ít nhất năm năm chưa?” Sẽ xuất hiện trong phần “Kinh nghiệm làm việc”.) Đây là cột khóa ngoại được tham chiếu từ question_section bảng.

question_section bảng lưu trữ thông tin phần. Đó là một cách để nhóm các câu hỏi liên quan đến cùng một chủ đề. Ngoài id thuộc tính, là khóa chính của bảng, thuộc tính duy nhất là section_name , tự giải thích.

consent_questionnaire bảng chứa tên biểu mẫu đồng ý. Hai thuộc tính của nó cũng tự giải thích.

ques_consent_questionnaire_map bảng là cốt lõi của chủ đề này. Tất cả các bảng khác trong chủ đề này được kết nối trực tiếp hoặc gián tiếp với nó. Mục đích của nó là giữ một danh sách các câu hỏi được gắn thẻ vào biểu mẫu đồng ý. Các cột trong bảng này là:

• id - Khóa chính của bảng này.
• consent_questionnaire_id - Số ID của biểu mẫu đồng ý.
• question_id - Số ID của câu hỏi.
• is_mandatory_optional - Cho biết câu hỏi là bắt buộc hay không bắt buộc đối với một biểu mẫu đồng ý nhất định. Một câu hỏi có thể là một phần của nhiều biểu mẫu đồng ý, nhưng nó có thể là bắt buộc đối với một số và tùy chọn đối với những biểu mẫu khác. Đó là lý do duy nhất đằng sau việc giữ cột này ở đây thay vì đặt nó trong question bảng.

Một vài bảng tiếp theo, chúng ta sẽ thảo luận về biểu mẫu đồng ý gắn thẻ cho từng bài đăng tuyển dụng và ghi lại câu trả lời của ứng viên. Hãy bắt đầu với job_post_questionnaire bảng, nơi lưu trữ thông tin về những biểu mẫu chấp thuận nào là một phần của bài đăng tuyển dụng. Có thể có một hoặc nhiều biểu mẫu đồng ý được gắn thẻ với một bài đăng tuyển dụng. Các cột trong bảng này là:

• id - Khóa chính của bảng.
• job_post_id - Biểu thị công việc mà biểu mẫu chấp thuận được gắn thẻ.
• consent_questionnaire_id - Biểu mẫu đồng ý được gắn thẻ vào một bài đăng tuyển dụng.

Tiếp theo, appl_questionnaire_answer bảng ghi lại các câu trả lời riêng lẻ của từng câu hỏi trong biểu mẫu đồng ý do người nộp đơn điền. Các cột trong bảng này là:

• job_post_activity_id - Cột khóa ngoại được tham chiếu từ job_post_activity bàn. Nó lưu trữ thông tin về ứng viên đã trả lời câu hỏi.
• quest_consent_quesnnaire_map_id - Một cột khóa ngoại khác được tham chiếu từ quest_consent_questionnaire_map bàn. Nó lưu trữ câu hỏi nào đang được trả lời từ biểu mẫu đồng ý.
• answer - Câu trả lời thực tế của ứng viên. Tôi đã giữ nó dưới dạng cột CHAR (1) vì tất cả các câu hỏi trong mô hình của chúng tôi có thể được trả lời là 'Có' (answer ='Y'), 'Không' (answer ='N') hoặc 'Không áp dụng' (answer ='X').

Mô hình dữ liệu cổng thông tin việc làm trực tuyến mới và cải tiến

Bạn có thể xem mô hình dữ liệu đã hoàn thành bên dưới.

Bạn sẽ thêm gì?

Bạn có thể nghĩ ra bất kỳ tính năng nào khác để thêm vào cổng thông tin việc làm trực tuyến của chúng tôi không? Hãy chia sẻ quan điểm của bạn trong phần bình luận.