> Needless to say, I will be leaving my company very soon to go to a place where there is a coding test and filtering to prevent most of these bootcampers from getting in.
I went to a bootcamp, and the first hour of every day was spent learning to solve the types of coding tests that companies use in interviews. So, when companies look at the graduates of these bootcamps, it's really hard to differentiate between people who perform really well on the interview but will require significant investment before they're useful (this was me) and people who have been programming and working with computers for years and simply lacked a little bit of polish & training (like some other people in my program).
All that's to say -- traditional coding tests & filtering doesn't necessarily work that well when you have people training for the test (rather than training for the ability to do the work that the test is supposed to be a proxy for).
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.
I went to a bootcamp, and the first hour of every day was spent learning to solve the types of coding tests that companies use in interviews. So, when companies look at the graduates of these bootcamps, it's really hard to differentiate between people who perform really well on the interview but will require significant investment before they're useful (this was me) and people who have been programming and working with computers for years and simply lacked a little bit of polish & training (like some other people in my program).
All that's to say -- traditional coding tests & filtering doesn't necessarily work that well when you have people training for the test (rather than training for the ability to do the work that the test is supposed to be a proxy for).