Depends on the job. If the company is looking for someone to come in and produce code than C1 is obviously the right choice. If they, on the other hand, is looking for an employee, someone that they want to be part of the company, then I would go with C2 (if we are talking about two candidates that both have personalities that would fit with the team they would be working with).
Reason 1: People who evolves and grows with a company are more likely to get attached to that company.
Reason 2: C2 doesn't know it's own value. That means that you can top their own perceived value and it will be easier to make them feel valued. Another reason to be loyal.
Reason 3: Good experience is easy to give (if you have a good company) but testing how you react to bad experiences is harder. You have one that has persisted through bad experiences and one that hasn't been tested. If you have become better than expected through a bad experience you know more about how you'll react to good experiences than the other way around.
Reason 4: If you are looking for a coder, sure, go with C1, but if you are looking for a developer, you want someone that tackles problems.
I might be biased in this. I'm not the best 'producer' of code. I tend to be slow when it comes to routine tasks. Where I shine is in problem solving. I am good at turning a problem inside out and upside down until I solve it. I can jump straight in to just about any language and given a day or two start finding issues and (even though I don't understand everything) manage to find solutions that better coders have been unable to. Not because I'm such a great programmer, but because my mind loves to solve problems. Most companies need both these types of minds, and in my experience they often have the coders in place and could use more developers. The exception to this is smaller companies and start ups where you usually have more developers and fewer coders and need those that can come in and tidy things up and get the product shipped.
Basically, like way to many questions like this, the answer must be:
Yes sure I know it always depends, just wanted the topic to be discussed and thank you for commenting.
I like the way you have presented the arguments especially R3 and R4 I could not have said those myself.
I feel more like the problem solver type of developer and I do feel that problem solvers are undervalued very often or perhaps companies are not much in need of them (us).
I believe that the reason it's easy to undervalue problem solvers is because when you don't need them, you don't need them. When you do need them it's mostly to late to get them and you manage without and loose money, and when you have moved on you are again in a state of not really needing them.
It's easy to see that you need problem solvers, developers, when you are developing a product. It's a lot harder to have the foresight to see that you will need them when you are managing a product.
Another reason, let's call it:
The senior dilemma
We will need more seniors, there's a lack of seniors, it's expensive to keep more seniors around until we come to the stage where we'll need them, when we need them it's probably to late to start looking for them or we'll have to overpay someone that mostly wants as much money as possible.
The sollution to the senior dilemma?
Reason 5: The junior solution
We get juniors now, some will stick around and be seniors when we come to the stage where we need seniors. Others will move to other companies and remember us as the ones that gave them a break, brought them further along their journey. Not only will this give us seniors that we won't have to overpay due to our need being so high while the supply being low on seniors, it will have given us help along the way with things we don't want our seniors to focus on and now that these people are seniors they know our products, company and, and this is a big one, the needs of our customers.
A junior isn't a title that tells you how long someone has worked in tech, it's simply how much responsibility they are able to handle in the area where they are working. If someone comes in with a score of 85% due to lack of experience with a good working environment with correct work flow, readable code, testing and code reviews, that is a junior. With the kind of experience you are talking about, it's a junior that won't take to much effort to make into a senior.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Depends on the job. If the company is looking for someone to come in and produce code than C1 is obviously the right choice. If they, on the other hand, is looking for an employee, someone that they want to be part of the company, then I would go with C2 (if we are talking about two candidates that both have personalities that would fit with the team they would be working with).
Reason 1: People who evolves and grows with a company are more likely to get attached to that company.
Reason 2: C2 doesn't know it's own value. That means that you can top their own perceived value and it will be easier to make them feel valued. Another reason to be loyal.
Reason 3: Good experience is easy to give (if you have a good company) but testing how you react to bad experiences is harder. You have one that has persisted through bad experiences and one that hasn't been tested. If you have become better than expected through a bad experience you know more about how you'll react to good experiences than the other way around.
Reason 4: If you are looking for a coder, sure, go with C1, but if you are looking for a developer, you want someone that tackles problems.
I might be biased in this. I'm not the best 'producer' of code. I tend to be slow when it comes to routine tasks. Where I shine is in problem solving. I am good at turning a problem inside out and upside down until I solve it. I can jump straight in to just about any language and given a day or two start finding issues and (even though I don't understand everything) manage to find solutions that better coders have been unable to. Not because I'm such a great programmer, but because my mind loves to solve problems. Most companies need both these types of minds, and in my experience they often have the coders in place and could use more developers. The exception to this is smaller companies and start ups where you usually have more developers and fewer coders and need those that can come in and tidy things up and get the product shipped.
Basically, like way to many questions like this, the answer must be:
It depends.
Yes sure I know it always depends, just wanted the topic to be discussed and thank you for commenting.
I like the way you have presented the arguments especially R3 and R4 I could not have said those myself.
I feel more like the problem solver type of developer and I do feel that problem solvers are undervalued very often or perhaps companies are not much in need of them (us).
I believe that the reason it's easy to undervalue problem solvers is because when you don't need them, you don't need them. When you do need them it's mostly to late to get them and you manage without and loose money, and when you have moved on you are again in a state of not really needing them.
It's easy to see that you need problem solvers, developers, when you are developing a product. It's a lot harder to have the foresight to see that you will need them when you are managing a product.
Another reason, let's call it:
The senior dilemma
We will need more seniors, there's a lack of seniors, it's expensive to keep more seniors around until we come to the stage where we'll need them, when we need them it's probably to late to start looking for them or we'll have to overpay someone that mostly wants as much money as possible.
The sollution to the senior dilemma?
Reason 5: The junior solution
We get juniors now, some will stick around and be seniors when we come to the stage where we need seniors. Others will move to other companies and remember us as the ones that gave them a break, brought them further along their journey. Not only will this give us seniors that we won't have to overpay due to our need being so high while the supply being low on seniors, it will have given us help along the way with things we don't want our seniors to focus on and now that these people are seniors they know our products, company and, and this is a big one, the needs of our customers.
A junior isn't a title that tells you how long someone has worked in tech, it's simply how much responsibility they are able to handle in the area where they are working. If someone comes in with a score of 85% due to lack of experience with a good working environment with correct work flow, readable code, testing and code reviews, that is a junior. With the kind of experience you are talking about, it's a junior that won't take to much effort to make into a senior.