Campus Recruiting System Work, 2023

This work supported the autumn recruitment cycle for the 2024 graduating class. It combined business-driven features with local structural improvements. The main design challenges were rule abstraction and data-model change within an existing system, rather than building a new platform architecture.

The work covered feature improvements, batch operations, limited model changes, and configurable automation rules.

1. Automatic Resume Assignment Rules

This was the most substantial design area in this phase. Resume volume arrived in concentrated bursts, recruiters used different rules, departments formed a hierarchy, and manual assignment did not scale well. The system needed configurable rules, batch execution, inheritance or coverage across department levels, and predictable conflict handling.

Three Layers

1. Condition conversion: Turn business filters into a structured DSL.
2. Scheduling and control: Order, trim, and validate rules before batch execution.
3. Execution: Run registered business actions.

Condition Conversion

Business-configured filters became a structured expression containing fields, operators, value sets, and logical relationships. The system did not concatenate raw SQL or infer business semantics. It compared explicit structural relationships.

For example, a parent department might target school types {A, B} while a child targets {A}. Set inclusion shows the child rule has a narrower explicit scope. It cannot, by itself, prove a semantic subset that was never expressed in the rule language.

Scheduling and Conflict Control

The control layer ordered rules by department hierarchy and priority, trimmed covered scopes, detected conflicts, and scheduled batch execution.

• Independent scopes: Execute normally.
• Contained scopes with the same action: Execute the child rule first, remove its covered scope from the parent rule, and execute the parent on the remainder.
• Overlapping scopes with different actions: Treat rules in the same phase as conflicting and block the configuration before execution.

Registered Action Executors

The execution layer used action enums, an executor interface, and a registry. It supported a primary action and combinations of subordinate actions. A new action required a new enum value and executor, without changing the scheduler. This separated rule ordering from the actual business operations.

Data Model

The core model contained a strategy table, a strategy-condition table storing the DSL, a field-definition table limiting the rule language, an action-definition table, and a strategy-to-action association supporting primary and subordinate actions.

Structured storage avoided opaque rule strings, supported conflict detection, and left room for new actions while keeping rules governable.

2. Interview Scheduling Model

The earlier model allowed one interview instance per round: round -> interview. It could not represent multiple parallel interviews in the same round.

Introducing an interview group changed the relationship to round -> interview_group -> interview. One round could then contain multiple interviews, support batch scheduling, and manage resources at group level.

That data-model change required corresponding changes to interviewer-resource assignment, conflict checks, progression through the process, batch-scheduling APIs, and state synchronization. It was a full-path adaptation caused by a local structural change.

3. Two Sources for Interview Rooms

Interview-room workflows needed to handle both campus and experienced-hire recruiting. Reads and writes were routed according to the business source and called different implementations. This was multi-source adaptation, not a merger of the two recruiting systems.

4. AntStar Workflow and Data Masking

On an existing workflow engine, the changes added campus-recruiting branch conditions, adjusted node transitions, and masked fields by role. These were feature-level improvements, not a redesign of the workflow model.

5. What I Learned

This phase was my first complete design of a rule-abstraction system. It showed how organizational hierarchy complicates rules, how a data-model change affects an entire workflow, and why batch execution needs explicit boundaries. It marked a move from implementing individual features toward thinking through their structure.