What The Business Does To Earn Money

During the Dotcom bubble, the most likely answer would have been "looking for new investors while we desperately try to find someone who wants to buy us outright". SCNR

When a new developer is hired, you want to give them the best possible opportunity to become productive as soon as possible.

I agree. Within reason, there aren't "too many questions", as long as you can see that the new hire listens to your answers and tells you when they don't understand it. And the person does at least some research on their own into some of the basics.

Unfortunately, i've had too many candidates lately who always pretended to understand what i had said, giving me no feedback at all what (and if) they had learned so far.

Plus, it would be nice for a change for candidates actually having the skills they pretended to have on their CV. My last "junior developer" candidate with "basic experience in multiple programming languages", during a basic "let's test your skills" thing during the one week evaluation period didn't even come as far as reading in the text file. (Exercise: "Read in this CSV file. First column is a filename, second column is some text data. For each line, generate a QR code image (PNG format) with a library of your choice. Data is the second column. Write file to the filename given in the first column.").

In that last case, the candidate also asked too many questions, yes. "Too many", because those were questions that person should have already had the knowledge to answer them. When you want to get hired as a Perl developer for software running on Linux, questions like "How do i copy a file on the command line?" or "What is 'source code/version management'?" shouldn't pop up. It should have been basic knowledge before filling out the job application...

But, as long as the questions are on the appropriate knowledge level and the new developer can show that they actually listen to and learn from your answers, the problem of "too many questions" doesn't exist. The old carpenters motto could be shoehorned here: "Ask twice, code once".