I would say you don't need to be "bossy", but you do need to be clear. You are setting a tone here for what it means to be a member of the team, and if the behavior and output is sub-par, it's fair to both give feedback to the new team member and to the manager. Since you are NOT the manager, giving the input and then letting the manager handle it or being open to his further direction would be a good move.
A good way to give feedback is to make a clear observation and ask for clarification. For the cases you mention:
"I see you on the phone this much" where this much is pretty specific - "3 out of 4 times I've come by", or "for an hour I could hear you on the phone while sitting within hearing distance of you in my workspace" - and then ask what is going on - "is there something going on I should know about. This many phone calls in a work day is not within the standard expectation of our group, everyone takes 15 minutes a few times a day to arrange appointments, touch base with family, etc but it's important to be able to maintain focus for most of the work day." Note that this varies based on culture - some places are fine with big gaps in a work day so long as the work gets done on time.
"The problems I gave you were relatively simple, I expected that they would take you 3-4 hours each to complete, so I was surprised that it took you 14 hours to get the first one done - what can we do to speed up the pace?" The answer could be "help me with my IT problems - they kept me from compiling the code and I've spent 6 hours trying to resolve them on the phone! ARGH!"
The answer "give me more time to learn" isn't universally acceptable but it's a place to start giving feedback about the complexity of the problems and the nature of the work. "We work in an agile environment here, we have a 2 week sprint, and we often get faced with new problems each sprint. So if it takes you 14 hours to learn a simple problem, I'm concerned that you'll have real trouble keeping up with the ongoing pace of our work, where software must be ready to test about 7 days into the sprint, leaving 3 days of slack for test and bugfix...".
With that said, some people take way more time to consider a problem and then deliver a solution that is so awesome and issue-free that it takes much less time to implement and verify it. So be ready to discuss the whole picture and not a fraction of the problem. That's why my example is of a sprint - its a delivery of whole functionality in a lifecycle and not a sub-step. If what you've given this person so far is only the sub-step, then you may not have a valid frame of reference for their capabilities.
It's natural to feel some defensiveness if the person judging you is coming across as unfair or if you don't grant the premise that they have a right to give you this feedback. Hard to tell here. How to deal with it has a lot to do with the details, and it's probably worth a check in with your boss or your mentor in the company, so that you can get a sense of how to handle this within the culture.
With all of this said, there's a limit to how often to give feedback. Giving feedback to someone every day is exhausting for both of you - find a break down in the meaningful chunks of work where you can give small feedback to effect small changes. Weekly is often a good rate, especially with a new person.