I just hired a web developer and I am having some issue with his performance. The problem is that he is very slow and sometimes he will ask me programming questions.

When I hired I knew he was new to the language that I was hiring him for but I gave him some time to learn the language. He already knew other languages. But now when I gave him some task he is not performing that well.

He will come and ask me how to do something which is kind of programming common sense. Some would say I didn't interview him well but I did interview his concepts and they were good. It is more about his problem solving ability, which I didn't test.

How do I deal with this situation. I am thinking of giving him feedback on his work till now (I hired him a month ago). I want to know if you guys have a better way of dealing this situation.


  • Do you have a boss yourself? Is the workplace pretty much just you and this new recruit? Commented Jan 9, 2015 at 0:43
  • @SteveJessop I do have a boss and I am this new guys manager.
    – trio
    Commented Jan 9, 2015 at 2:36
  • How long is "some time"?
    – Alnitak
    Commented Jan 9, 2015 at 11:53
  • 6
    Have you really expected someone to be expert after 1 month?
    – user1023
    Commented Jan 9, 2015 at 14:02
  • 1
    @РСТȢѸФХѾЦЧШЩЪЫЬѢѤЮѦѪѨѬѠѺѮѰѲѴ - the OP is not requiring him to be an expert after 1 month. The OP wants to know how to handle the fact that after one month he does not appear to be moving along the road to expertise at the desired pace. Perhaps acquiring expertise will take two years - but the potential to get there should probably be evident after a month, while in this case it appears not to be.
    – Vector
    Commented Jan 9, 2015 at 22:46

4 Answers 4


As someone who recently went through a stint like this, I would find no problems with his/her current performance. A month is enough time to learn the language, but at the same time they are learning company procedure, getting involved with the team, etc... This individual is also likely learning things specific to your company rather than the overall language. There's quite a bit going on for the first month of a new hire, so I wouldn't be surprised if it takes a couple of months before the programming really starts to take.

With learning a new language, speed is one of the last few things to come in. While he/she might understand all of the aspects of a particular language (and realistically they're never going to understand all of it), they're going to be slow while they think of new design choices. Simply put, the more this person uses the language, the better they're going to be.

What you can do is support this user's development. Give them some optional studying that they can do in the office to broaden their working knowledge of the language. Allow them to sit down with a senior developer with the focus on drilling down the basics. This person needs as much exposure to the language as possible. Ideally they would be doing small projects at home with this language to better hone their skills with various tasks, though that's not something you can enforce.

Of course if you don't have the time or resources to properly train this individual, then it might be time looking for a replacement. This individual tried their best to convince you that they would fit the role, and it's ultimately up to you to decide whether or not they're living up to expectations.

  • 2
    +1 the most significant learning hurdles on a new company/team are often with the existing codebase, processes, and way of doing things, not the language or specific technologies. It very frequently takes much more than a month to adjust.
    – TM.
    Commented Jan 10, 2015 at 2:47

Seems normal to me that someone only a month into learning a new language will be slow with it, even given that they know other languages.

Seems normal to me that anyone at any level will occasionally ask questions that are just common sense to their colleagues. People overlook things, and at least asking is better than getting it wrong.

You should:

  • revise your ideas about how quickly people get up to speed. You expect people in non-junior positions to be at least somewhat productive almost immediately. Junior people often aren't net productive at all to begin with (in the sense of producing more than the value of other people's time they occupy), although it depends on the tasks at hand. Unless you're bringing someone on board because they already have precisely the skills and experience to do the job, 3-6 months is not outrageous for the time period during which someone is and acts like "the new guy". Or put it another way, if your experienced developers aren't significantly faster most of the time than someone with only 1 month's experience, then what the heck is wrong with your experienced developers?

  • you should give them feedback on what's expected of them and where they are relative to that. But I'm reluctant to say you should do that straight away because there's nothing in your question to indicate that you have experience of a solid baseline to compare them to, and as you can probably tell by now, I suspect you don't have that. So you need to check with others in your organisation who can tell you what they think is reasonable/expected before giving your recruit a baseline.

  • unless I'm completely missing the point in your question, consult your boss for advice and training on how best to train your new recruit. I don't think an answer on this site can really do that topic justice, but I'd love to be pleasantly surprised by another answer. To start with, though, identify in more detail what's occupying their time. "Having nobody available who welcomes questions" can easily be a huge time sink. If they genuinely can't think of any way to solve the problems they need to solve then maybe they're not at the level you thought you were hiring, in which case training them up might be more effort and risk than you ever intended to commit to. After a month it's fairly normal to be able to think of any number of ways of cracking a problem in the languages you're familiar with, but to be slow at expressing them in your new language and to be unable to find the best idiomatic way in the new language at all. So it's quite possible they're struggling with the new language, other aspects of the technology, your company's ways of doing things. If this is their first job then getting to grips with the basic nature of employment might be occupying a fair amount of their time. Find out which and help them with those things.

  • ensure that your recruit is evaluated fairly in line with company policy. They may or may not still be in their probationary period, in which case they'll expect regular evaluation anyway. If they're getting nothing done at all, or are objectively much worse than other recruits at similar points in their careers, then perhaps they're unsuitable for the job (or just not a good fit for the level of support and training you provide, but unfortunately for them that amounts to the same thing). If they're getting something done, and are improving according to your measures, and are only slightly below what's typical for people of their experience, but they're not doing as much as you'd like, then that's pretty normal. Even I'm not as good as I'd like, never mind other people being as good as I'd like ;-) During evaluation, pay close attention to their training and development.

  1. If his problem solving ability is miserable, that's a very heavy strike against him. Because no matter how well he understands the programming concepts and how comfortable he gets with the syntax of the programming language, his programs will be a reflection of his problem solving ability and consequently, they will always suck.

  2. If the issue is his lack of grasp of the programming language syntax, then you'll have to grin it and bear it until his grasp of the programming language syntax gets stronger. His problem solving itself may be hampered by his weakness with the syntax but you should see improvement over time.

  3. If the issue is some bad habit of rushing into coding without thinking anything through, then you'll have to require him to brief you on what he intends to do and how he intends to do it before he writes a single code of code.

I'd say, if you give him a task, tell him to work out how he sees himself doing it and brief you on how intends to execute the task before he writes a single line of code. You absolutely, positively want to see how he thinks. If his thinking sucks, then you should hand him his walking papers and wish him luck.

If he is hampered by his lack of comfort with the programming language syntax and the scope of his solution is limited by his lack of command of the syntax, walk him to the appropriate solution and let him work out the details on how to get that solution. At least unless and until you decide that your patience with him has run out.

Having said that, some people fall apart when they have to practice what they preach and when they realize that their walk has to match their talk. I hope that he is not one of those who can talk a good game about concepts but collapse into a mass of jelly when they have to code something.

  • +1 - I think many people are missing the point. The point isn't the new programming language, it's that the OP didn't test for problem solving and made a hiring mistake (probably). They need to cut their losses ASAP.
    – Telastyn
    Commented Jan 9, 2015 at 15:26

Since you say the issue is his problem solving skills, not knowledge of the language or your shop's rules and practices, I really don't see what the question is here. Certainly you should give him feedback on his performance - not to do so would be an injustice to him: By doing so you give him a chance to improve. If you don't do so, he may think everything is fine and never try to improve, making things only worse, such that you may have no choice but to terminate him.

As an employee I always appreciate constructive feedback from management, especially if I'm new to a job. Just make sure to present your criticism in a delicate and respectful manner, particularly if you believe he has the potential to overcome his shortcomings and become a valuable employee - you don't want to lose someone who may be talented because you came down too hard on him.

In addition, once you have given him your feedback, you will have done your duty as a manager by putting him on notice, so if subsequently he does not develop the way you hoped, terminating him will not be a great shock to him.

As an aside, this incident should be a lesson to you when hiring a developer: Problem solving skills are probably the single most important thing a developer needs, and they come from talent and experience - not really something you can learn in school or from a book very well. Not so for most of the other skills required to be a good developer. IMO problem solving skills within a programming and IT context should be the main focus of such an interview - the rest can be learned on the job if you are sure that the fundamentals are there - that the candidate is indeed a competent programmer in the general sense, with respect to the position you need to fill.

Having said that, his future with you may not all that bright, because problem solving skills are indeed difficult to acquire, if the innate talent just isn't there.

Not the answer you're looking for? Browse other questions tagged .