Coding tests -- I don't think so. Within three months of practice, folks were generally proficient at the "Cracking the Coding Interview" style of problems. When you have a curriculum that's partially designed for that purpose, any question you have that would stump bootcamp graduates is also going to flummox some amazing engineers with years of experience.

I'd instead try to pair with people on solving a problem that translates well to the problem domain that you're trying to hire for. Anybody who's new to the industry is going to need a decent amount of support & mentorship starting out before they're able to contribute meaningfully to a team and working with someone for a day is a good way to figure out how much support they're going to need and what it's going to be like to mentor them. Bootcamp graduates would likely be open to a day of paid pairing to figure out if a job would be a good fit.

If you did want to go with the more traditional coding test route, I'd try and do something relatively concrete:

- download a set of log files & group them based on a search

- hit an API route & use that to render and update a list of items

- connect to a database, figure out what schema migrations are necessary to support a new feature, and then talk through how to do the migration

- figure out why a test is occasionally failing on a CI server

- add metrics, logs, tests, and alerts to a service with two routes (/healthcheck and /doSomethingImportant)

Like all interviews, the closer the interview maps to the day-to-day of what your needs actually are, the better it will be. There's something beguiling about questions about dynamic programming or red-black trees, but being good at answering those questions has almost no relationship to day-to-day work. (Unless you're at a place where deeper knowledge of data-structures and computer science really matters... and in that case, you're not going to have much with recent bootcamp graduates anyways)

I have some luck with a question that needs you to use a standard “interview” data structure in a slightly nonstandard way. People who can bring up the data structure and tell me all about it, but not see how to actually solve the problem with it, are easy to reject. People who can derive it on the spot, or at least figure out how to use it after I give it to them, tend to be impressive hires.