Completely agree with your take on estimates. Being able to foresee problems and give reasonably accurate estimates is critical.
I have an amazing junior engineer on my team, very motivated and learns fast. The problem is he his ALWAYS too optimistic, no matter how much time we discuss it. Nobody pressures him to give low estimates for tasks, but the fact is he is always late and it’s hard to count on him. I started to just buffer it myself, but it feels patronizing.
Estimates will remain one of the hardest problems in software engineering. And that’s understandable; the trick is not to get the right estimate from the start, especially in large projects.
The trick is to:
1. know when to flexibly adjust the timeline estimates, and
2. Clearly, promptly, and honestly communicate that with the team and higher management.
I still remember the faces of Junior applicants when I told them during the technical interview they could use Google and StackOverflow or anything they could think of. If you do this long enough, you still have plenty of time to assess their qualities.
As for the first interview - no developers were available, so someone from HR came. I was given a coding challenge, but I gave a (working) solution different from what was written in the HR notes. This is how I failed my first interview. 🙂
Completely agree with your take on estimates. Being able to foresee problems and give reasonably accurate estimates is critical.
I have an amazing junior engineer on my team, very motivated and learns fast. The problem is he his ALWAYS too optimistic, no matter how much time we discuss it. Nobody pressures him to give low estimates for tasks, but the fact is he is always late and it’s hard to count on him. I started to just buffer it myself, but it feels patronizing.
Estimates and working on legacy code are facts of life as a software engineer.
The good thing is, legacy code has value, greenfield is more likely to get canned in a bad economy - it's unproven.
Estimates will remain one of the hardest problems in software engineering. And that’s understandable; the trick is not to get the right estimate from the start, especially in large projects.
The trick is to:
1. know when to flexibly adjust the timeline estimates, and
2. Clearly, promptly, and honestly communicate that with the team and higher management.
I still remember the faces of Junior applicants when I told them during the technical interview they could use Google and StackOverflow or anything they could think of. If you do this long enough, you still have plenty of time to assess their qualities.
As for the first interview - no developers were available, so someone from HR came. I was given a coding challenge, but I gave a (working) solution different from what was written in the HR notes. This is how I failed my first interview. 🙂