Your two options would be
1. Have the message start event form ask whether they are a new employee or existing employee first. If they are a new employee, show all the form fields and have the new employee fill out that form. If they are an existing employee, have them enter their employee ID or name (whatever you use to look them up) and submit the form.
Then in the process: On the message start event, select the option to "load next user task if it is assigned to the same user". After the message start event, run the WF to use the information gathered on the form to run an external data query and pass back all the employee information. After the WF service task, have a user task assigned back to the /_initiator with all the variables now populated. Because the task is assigned back to the initiator, it should load up automatically for that user.
The problem with this solution might be the wait time for the user. After filling out their employee ID and submitting the initial form, it may take 10-20 seconds for the next form to load up with the data. Depending on how busy the remote agents are, it may sometimes take longer. This is the reason we need to enhance queuing/prioritization for remote agent requests before implementing this feature directly in forms. Give this a try and see if the performance is acceptable.
2. Store the employee table as a lookup table in the cloud. Since employee's information doesn't change that often, you could do a nightly sync of your on-prem SQL server to a lookup table. Then you can look up data from that table using a lookup table query and those will be fast since the data is all in the cloud. I recommend this option if possible. Even after implementing on-prem SQL lookups in forms, pushing the data to a cloud table and looking it up from there will be much better performance.