A day's schedule as an optimization problem
At the Techniek Bedrijven career event, students and companies need to be a good fit, and every schedule has to work. We built a platform that calculates those schedules using Python and PuLP. The work began by translating the practical requirements into a mathematical model.
Client
- Industry
- Education & recruitment
- Location
- Delft
Team
The challenge
Who meets which company?
Stichting Techniek Bedrijven organizes an annual career event for engineering students. Participants attend three sessions with different companies throughout the day. Students indicate their interests; companies look for people with particular qualifications, experience or backgrounds. There are more applicants than places.
That creates quite a puzzle behind the registration form. Which students do you invite, and how do you give each of them a suitable schedule? We built the platform's technology, initially for our friends Sping, which handled product design. We later took over the entire project and continued working directly with STB.
A match does not yet make a schedule
With one student and one company, assessing how well they fit is fairly straightforward. Once you schedule a whole day, those choices start affecting each other. A place assigned to one student is no longer available to another. A student can attend only one session at a time and needs to have met three different companies by the end of the day.
Selection and scheduling therefore belong together. If you first pick each company's favorite candidates, you can run into trouble later: someone might have a place in the morning but no suitable afternoon program. We recognized this as an optimization problem. We needed to consider possible allocations as a whole.
The question behind the question
What should the algorithm optimize?
A registration form tells you who a student is and what they are looking for. Matching also requires the other side: what matters to the participating companies? One company might place a high value on a particular degree, while another gives more weight to experience outside a student's studies.
That insight helped determine which data the platform needed to collect. Together with STB, we worked out the criteria. We structured student profiles, interests and company preferences so the software could use them in calculations. The technical design began with the questions on the form.
From answers to scores
Seemingly small choices matter here too. Similar degree programs have different names at different institutions. We grouped them under shared education tags so that a company preference could apply consistently to students from different institutions.
Using profile data and weighted criteria, the application calculates a score for every combination of student and session. Those scores become the input for scheduling. Keeping scoring separate from allocating places lets us address both questions individually: how do we value a match, and which combination of matches fits the program?
Write down the rules before calculating
We chose linear programming. With this approach, you describe the available choices, what you want to optimize and the constraints the outcome must satisfy. An existing calculation engine, called a solver, then searches for a solution to that model.
For STB, the objective is to maximize the total score of all assigned visits. We also specify that all available places must be filled, every selected student must receive a complete schedule and nobody may visit the same company twice. Those rules are explicit in the model. That gives us a basis for discussing with STB what a rule or a different weighting means for the allocation.
Technology that makes the difference
The entire allocation in one calculation
A small example shows why we calculate these choices together. Suppose there are two candidates and enough places for one complete daily schedule. Candidate A scores 10, 2 and 1 for the three companies. Candidate B scores 8 for all three.
Start with the first company and you choose A. Across the whole day, B scores higher: 24 versus 13. That is easy to see in this fictional comparison. At the actual event, the software has to consider all candidates, places and preferences together.
Python and PuLP for the model
We build the model with PuLP, a Python library for linear optimization. Every assignment is a yes-or-no decision: this student gets this place, or does not. Participation itself is another such decision. Since you cannot assign half a student, we use the variant with whole numbers: integer linear programming.
The solver then searches for an allocation with a high total score that satisfies every constraint. We do not have to write our own search algorithm. Our work lies in modeling: which choices are connected, which rules are mandatory and which preferences can be weighed against one another?
Running the calculation outside the web application
A calculation like this does not belong in a web request that leaves the browser waiting. We set up the Python engine as a separate computing task. The TypeScript backend calculates the scores and starts the task on AWS. Python reads its input from S3 and writes the result back there. A message in a queue then brings the outcome back to the application.
That separation lets us use Python and PuLP for the calculations alongside React and TypeScript for the portal and admin interface. The backend turns the result into daily schedules the board can review.
A failed calculation is part of the design too
We check the input before the solver starts. Are there enough candidates and different companies? Does each time slot have the same total capacity? That last condition is necessary to fill every place while giving every participant a complete day.
The result is checked too: do the capacities, assignments and complete schedules add up? A calculation that stops without a valid solution must not produce an incomplete schedule. The tests therefore also cover impossible allocations and time limits with and without a usable result.
What it made possible
From registration to a schedule ready for review
STB can collect registrations, manage criteria, start a matching run and inspect the calculated schedules within the same platform. The board can look up scores and decides when to publish the allocation. Each student can then see their own schedule in the portal.
We deliberately made that review part of the workflow. A high score reflects the criteria we have configured together. If an outcome looks strange, we need to revisit the input and the weighting. We discuss the model and possible improvements with successive boards; technical board members also look at the code.
Adapting the technical foundation as the product grows
We built the first version partly on Strapi's registration and admin features. That allowed us to deliver both the design and the matching within the available budget. Later, custom functionality around user data and substantial CMS upgrades made that combination increasingly difficult to maintain.
We therefore gave the student portal its own backend. Strapi remained available for content and event information. That is part of our work with STB too: continuing to assess whether an earlier technical choice still fits the product it has become.
The same tool for our own planning
We use PuLP within 10KB as well. For our monthly planning, we allocate available developers to projects, with requirements for hours, teams and preferences. The rules differ, but the work starts in the same way: understanding the scheduling problem well enough to turn it into a model.
Our blog on linear programming explains more about the technique. It is one of the tools we use when building matching platforms, where preferences and limited capacity jointly determine the outcome.
What we take forward
From practical rules to working software
At Techniek Bedrijven, modeling, application development and maintenance come together. We apply these considerations to other scheduling and matching problems too.
Model connected decisions together
We calculate who can attend and which companies they will visit in a single run. That allows the full day's schedule to count.
In future projects
We examine which decisions affect one another before splitting a process into separate automations.
Make the rules explicit
Company criteria and student preferences become scores. Capacity and full attendance are hard constraints in the model.
In future projects
Together with the client, we decide what the software should optimize and which rules every outcome must satisfy.
Build in the checks
The application checks inputs and calculated schedules. The board can then review scores and publish the allocation.
In future projects
We also design what happens before and after a calculation so that users can work with its outcome.
Ewout
Does your planning keep getting more complicated?
People, preferences and limited capacity can make an allocation difficult to work out. We can help you find a suitable model and build the software around it.