> On the other hand, if someone got hired on for a typical mid-level developer/engineer position without any promises of a research/advanced engineering focus, they need to man up and do their job.
I think this is a self-driven promise. Like another commenter said, this is up to your job description. If you work in the research department, you are more likely to do more "innovative" thinking than those who are hired to build a product because your primary job won't be building CEO a search box. "Product" can be interesting or totally banal, whether you are hired to build public-facing application, or internal application.
I say research focus is self-driven because unless you work in an extremely "do what I say or you are fire" environment, normally you can tell your lead or the product team how to build or enhance a feature. If you think your automated testing infrastructure looks broken, offer ideas to folks who are paid to build that part of the infrastructure. Sometimes, overstepping into another team's boundary is actually a good way to tell people you are capable of doing more than implementing a stupid drop down menu. IMO a good software engineer begins with you giving a clear analysis of the problem and providing a clear and competitive solution (pros/cons with other solutions). That's research, that's "leading", that's architectureing. As simple as building a drop-down menu, well, are you tired of writing a whole new menu every single fucking time yet? Well, here is a research, here is an architectural change - make that shit reusable and make your template whatever resuable, convince your colleague your suggestion is better than theirs and that they are idiot this whole time. No not that hash, but along that line.
And most real research job spend a good portion on writing and doing presentation.
Yeah I keep saying implementing a drop-down menu. But why? Because a lot of the tickets will be around enhancing user experience and that can either be very interesting to some, or extremely boring just because.
I think this is a self-driven promise. Like another commenter said, this is up to your job description. If you work in the research department, you are more likely to do more "innovative" thinking than those who are hired to build a product because your primary job won't be building CEO a search box. "Product" can be interesting or totally banal, whether you are hired to build public-facing application, or internal application.
I say research focus is self-driven because unless you work in an extremely "do what I say or you are fire" environment, normally you can tell your lead or the product team how to build or enhance a feature. If you think your automated testing infrastructure looks broken, offer ideas to folks who are paid to build that part of the infrastructure. Sometimes, overstepping into another team's boundary is actually a good way to tell people you are capable of doing more than implementing a stupid drop down menu. IMO a good software engineer begins with you giving a clear analysis of the problem and providing a clear and competitive solution (pros/cons with other solutions). That's research, that's "leading", that's architectureing. As simple as building a drop-down menu, well, are you tired of writing a whole new menu every single fucking time yet? Well, here is a research, here is an architectural change - make that shit reusable and make your template whatever resuable, convince your colleague your suggestion is better than theirs and that they are idiot this whole time. No not that hash, but along that line.
And most real research job spend a good portion on writing and doing presentation.
Yeah I keep saying implementing a drop-down menu. But why? Because a lot of the tickets will be around enhancing user experience and that can either be very interesting to some, or extremely boring just because.