RPA Hiring process

[opaque umbra]

Hi everyone,
I'm currently in the process of evaluating internal candidates to get trained in RPA.
I've got a certain candidate who has no formal education in IT or finance and no relevant experience, only e-learning. However, in talking to this person I felt like he does have surface-level knowledge about a lot of things and didn't want to instantly dismiss him.
I want to put him to the test and see if he has the skills required for RPA. How would you go about this? Anyone have experience with such cases?

It would be a junior position with training on the job. So he doesn't have to know the tool, but has to be able to think logically.

I was thinking of a Google-like whiteboard interview, but had trouble coming up with solid questions for an RPA developer.
Perhaps I could show the video a process owner made of their process and ask him about how he would go about automating it.

[mighty kayak]

A whiteboard interview makes no sense for RPA, as the whole thing is about dragging and dropping stuff. You don't need to know the syntax or even all of the actions available. Especially initially.

I'd instead give them a few real'life situations of inefficient processes to be automated and ask them if they have any ideas on how to go about it and where to start.

If you have the time, you could also hive them some simple task to automate using PAD at home and send the resulting script to you. But you will need to give them at least a week to do that. Possibly more, if they are currently employed.

[ionic wolf]

This could be one part of the interview: Ask them to build a simple process with some "traps" in beforehand - have them present it at the interview.

[valid ember]

Show them a realtime production issue and see how they try fixing it

[mighty kayak]

A PROD issue might be a bit too complex when they're entry level. Entry level developers would not be working on issues in PROD right after starting anyway.

The focus here should be on the way they think and construct ideas, as well as whether they understand the flow of the process and can actually visualize the steps in the correct order when you describe a task to them in simple language used by end users. So, I suggest trying to simply give them a real life task and ask them to describe what they think the solution could be and the approach they would take, without focusing too much on the technicalities and especially the syntax of it.

[valid ember]

But how cool they try to handle how they try to search or dive into the issue how they debug can let us know how interested they r at work and how good they learned

They don't need to resolve anything infact

[mighty kayak]

I know what you mean, but I personally think that might be a bit too complex for entry level people. It might be okay for juniors/mids who have some experience, but not entry levels who have never seen the tool and never done any automation.

[valid ember]

Oh ekdam entry level it's tough I agree I'm feeling junior devs

[opaque umbra]

Thanks for the feedback all, will go for Agnius' suggestion by showing them a real process and asking how they would approach it.