"Hey, you made this X change to that Y function. This change breaks my
code because it's not taking Z in account, and Z is what happens on my
side. Is it ok with you to do K to fix it?"
You need to make this less personal. There is no my code and your code. Both of you are employees of a company, and that company owns the code. You merely wrote it, but ...
There's a couple of things that I've found help a lot with the reception of code reviews:
Don't say "you", or variations on it ("your code", etc).
You're not ripping apart "his" code or "his" solution. It's our code, or this solution, and we need to do things to it.
As soon as someone starts talking about "your" code, a lot of people's natural reaction is ...
What do you advice me to do?
Grin and bear it. Pay attention in spite of your boredom. Take notes.
Not everything can be within your control. Not everything can be exactly the way you'd prefer.
Remember this when you are eventually in the position where you can lead meetings. Create and follow a tight agenda. Make sure only those who need to be there are ...
As a slight frame challenge to your question, you need to get some clarity on what the role requires and then ask questions specific to that. In other words, I have the feeling that your real problem is that you don't have a clear idea of what skills you want in this person. Find that out and the questions will follow.
Stop over-thinking "easy" versus "hard"...
However, I have no problems working with very junior employees but I
know that in the first half year/year they will require a lot of
tutoring and may even slow down the projects our team is working on.
Every new employee slows down projects while they are being trained and becoming comfortable in the position.
In fact, we are looking now for a new ...
I did a series of talks on what makes code simple and readable. There is no absolute answer. Much depends on the vocabulary the reader brings. Take for example:
if (x > 0)
retval = true;
retval = false;
Compare this to
To the complete beginners it's possible the first seems simpler, more ...
Bring a pad and write, write down anything.
It will keep you from looking like a zombie and if the person says something useful, you'll already have pen and paper in hand.
I have a hard time sitting still, so this works for me, I need to get that energy out of me. If you're restless as well, this may help.
For a Junior, it's less about what they know, and more about who they are.
If they don't know the answer to a technical question, follow up with something like?
You said you don't know. How would you find out, and then implement it?
For the tech questions themselves, have sets of Basic, intermediate, and advanced. Climb the difficulty tree until you ...
After two weeks, I can say with confidence that I clearly didn't create value for this company and the other developers that helped me could have done my job instead of spending time with me.
You will not create "net positive" value for the company for much longer than that (even when I hire senior developers I assume they aren't net positive for 6 months). ...
Talk to your manager. That's what managers are for.
The behavior of a colleague impedes your ability to work effectively. Keep detailed notes. Describe to your manager the behavior and how it impacts your productivity and efficiency. Don't judge. Just stick to the facts. Tell your manager that you would be happy to change your code style in whatever way is ...
All code should be peer reviewed (but I've worked in a lot of places where that never happened). How clean is clean? There should be coding standards and guidelines; ask for them. As to how "picky" you should be; that depends on the code being reviewed. Some people like having blank lines pointed out to them, and spacing. Others prefer you spot potential ...
I've always been a believer in following your "gut" and your gut is telling you that this guy won't be a good fit. You'll probably turn out to be right. If it were me, I'd follow that feeling and tell the guy "we're going in a different direction" and just leave it that.
If you have to bring him back in, interview him as you normally would but when he ...
A few points in addition to the other answers:
Accept that, as a junior, you don't know everything :-) There may be reasons for the style of code that you are unaware of, such as:
Avoiding unnecessary changes to working code (keeping diffs manageable, avoiding introducing unnecessary bugs, &c).
Keeping related code so it can be seen together. (No ...
Let me restate things a little bit and provide some interpretations:
Difficult tasks are being assigned to you. That means people think you can do it.
As a junior developer, it seems like you make significant contributions to the project. You can be proud of that.
There is lack of support from your senior dev, but other team members fill in the gap. Maybe ...
Unfortunately, it's not your decision. You can either do it or they will find someone for your position who will.
Tell him and then write him a letter of recommendation and offer to speak on his behalf to anyone wanting to hire him.
You just need to make sure that you support management with your recommendation, if asked. You can talk him up about how ...
I think it would be extremely rare (e.g. almost never) to let anyone go after 2-4 weeks (for performance related things), and rarer still for that to happen to a junior developer, so take a deep breath and relax. Now let's figure out how to "get up to speed" and begin to feel a bit better about your position.
They hired you after looking at your resume and ...
You’re ashamed because you’re growing as a software engineer?
The more you learn, the worse your old code looks... just comes with the territory. Keep looking forward, that “horrible” code you’re referring to helped you get to where you are today. You’ve learned, and that’s nothing to be ashamed of.
Worrying about those who are judging you is rarely a ...
Disclaimer: this answer will be written as if OP's coding style really is as complex as necessary (not over-complicated) and it's really good, efficient code (not something that could be done easier and in a more understandable way with the same result).
I think I was in your position before. I was the "expert" guy working on integrating and ...
Senior engineers usually have a lot of "off book" work that isn't very visible, even less visible if you are working remotely and can't see the foot traffic to their desk. You see a tiny sliver of it when you get stuck and ask for help, but you don't see the half hour of research he does before getting back to you, or the three other people who ...
Upon request to make it an answer...
It sounds like you've already gone to bat for this employee, but management wants him gone for their own reasons. And that really sucks, but you can help mitigate the negative impact of his firing.
If you've supervised his work directly, you can offer to supply him with a reference or letter or recommendation for future ...
You are the technical lead. You have a subordinate that is not only stuck on a problem for a long time without delivering, but actively refuses to accept help.
You need a one-to-one where you explain the problem, that she is not delivering anything, and that she was given help that would have solved the problem, but refused to accept it, and ask her what ...
As Joe mentioned in the comments, smile and deal with it. You are a junior developer. Unless you are the guy organizing the meeting and everyone that is attending the meeting is inferior to you, you don't get to "do" anything about a boring meeting.
Although, I've found this one trick VERY helpful when I am bored in a meeting.
INVOLVE YOURSELF! Contribute. ...
As a precaution, update your resume and start putting out applications. You want to be in a strong position regardless of the outcome.
Document every last bit of hostility with an email trail. Here's a point by point way of doing this
*He held a presentation about code review practices, where he said that you should not argue about the requests on ...
Hmmm....so instead of training an already known value (the jr. developer), the management wants to fire him, bring in someone new they don't know, hope that person 'fits' into the org/team, can understand the business quickly, and start contributing to the team. Also, if money is no object, makes one wonder why they don't just bring on another without ...
I worked there only 2 weeks
You need to give it a lot more than just 2 weeks.
Everyone feels a bit overwhelmed when they initially start a programming job.
Your first few weeks/months will involve unlearning lots of things you were taught in school/bootcamp and learning how real software work is done.
Nobody understands all the code at first glance. ...
You have junior teammates, and your organisation needs your code to be comprehensible to them.
This is critical. You've been given an unwritten requirement - your code must not only do the job, but it must also be maintainable by others.
This is a very difficult balance to play. Compare the abstract factory pattern with a simple hash table of factory ...
Let's review your company options:
Wait months for a perfect candidate - If you have reasonable expectation that such candidate will appear, and you can handle workload for months without him, this is a decent option.
Hire more junior candidate and train him - At first, this will cost money and increase workload. "may even slow down the projects" is usually ...
I never made any progress in these things formal parts of his job
That may be part of the problem.
People (and particularly juniors) respond to incentives. It's possible this individual is focusing on whatever he views as the formal parts of his job duties and not so much on these other tasks.
it's as though he thinks that being a developer ...
You seem to be a part of a team that is more experienced than you yourself are. The fact that these people have been working together for longer, and perhaps feel that their work is higher quality may lead to the attitude you're experiencing today.
I have no way to tell whether you've done anything to make the rest of the team feel like their behavior is ...