Hacker News new | past | comments | ask | show | jobs | submit login

Even startups should be willing to train. The skills really aren't that hard to pick up with the right mindset and knowledge a CS grad ought to have.

We had an intern come in that was still stuck in that student-mode of needing to be told everything and not asking pointed enough questions. After a few weeks they were up to speed and productive.

Frankly even experienced workers will still require a period to absorb specific knowledge.

I think the time required for fresh grads to be productive is way, way overstated and overestimated provided they have the right direction.

They should. Often, they aren't. There are a number of reasons there - some don't have the time.

> Because startups need to bring their products to market quickly, applications are built iteratively, with rapid prototyping. The timing of the product release is crucial because it has a direct impact on acquiring customers and affects the bottom line. Significant delays can put a company out of business. While time to market is also vital for large companies, their software releases are typically for established products, and if they run late, such companies usually have the money to survive.


Some don't have enough people to properly mentor and train a new hire.

The page for the startup of the engineer featured in the article: https://www.linkedin.com/company/datarista/about/

> size 2-10 employees

I would contend that any company in the 2-10 range hiring a new grad is a mistake for both particles.


Some acknowledge the "they get a job, they get trained, and they go on to greener pa$ture$." In this case, the mentoring is a lost ROI in many cases.


My reading of the desires of the person featured in the article... they want to hire a person at new grad wages who knows how to debug a legacy code base, architect a cloud solution, come up with new product ideas, do market research, and be a participant in the "devops means we give developers root" culture... and be able to do this within single digit number of days.

Those are things that come with experience and failure. No class or boot camp will teach those things to a point where the person is competent in them without some good time to work on those skills (side note: this is where college often produces better candidates than boot camps - they've got more time to learn the tools).

Rambling on the above... I now have a one question that will distinguish a good candidate from a poor one: "How do you set a breakpoint in your preferred debugger?"

Concede that time may be a factor, in which case, companies have little choice but to shell out real money.

> mentoring is a lost ROI in many cases.

What investment? Grads are cheap, and time to productivity as I argued isn't that long, before which they aren't merely learning. Most of the investment here is on the worker's part, and greener pastures aren't available as quickly as productivity sets in. If you're fresh out of school and working, leaving a company is unthinkable in the first year, unlikely in the 2nd.

Investment of time by other developers who could be working on the features.

This isn't saying that mentoring can't be a positive ROI - just that the person needs to stay long enough.

> If you're fresh out of school and working, leaving a company is unthinkable in the first year, unlikely in the 2nd.

You should check out reddit /r/cscareerquestions and consider how many people advocate leaving under a year.

I will also note that for my own experience, while there are some developers who stay for a long time, there are more than a few that start and leave within a year.

In trying to get two developers that would stay on, we went through six developers. Four of which left within a year. This is for public sector and the lack monetary compensation shouldn't be a surprise to anyone... still, had four developers that we trained up and left.

The investment of time in getting them to that point where they could be useful contributors if they had stayed was more than what it would have taken the developers who mentored them to just do those tasks and not have hired anyone.

That doesn't touch on the actual pay and paperwork to hire someone.

So management decided it's cheaper to keep compensation low and have a revolving door of developers than try to retain them, or is it merely short-sightedness?

In the public sector, management has very little they can do about raises. Raises are an act of legislature or the governor. The number of people at each level within a bureau is likewise an act of legislature or governor.

Likewise, the pay isn't anything hidden either. This number is well known https://projects.jsonline.com/database/2019/4/Wisconsin-stat... (much of the technology side gets classified as IS SYSTMS DEVMNT SVCS ...). Compare those numbers to the averages for the area https://www.payscale.com/research/US/Location=Madison-WI/Sal...

People applying and taking the job know exactly what they are getting and going to get for compensation and benefits. Pay is a bit on the lower side, vacation is on the higher side, the pension is fully funded (actually at 102.9%).

Thus the ability to juggle things to retain a person is very limited - especially when that person hasn't been there for a full year.

Consider then, that the person is accepting the job, knowing that this is the public sector, knowing the wage history, and looking for another job elsewhere (many have left to move out west). It is not exactly practical for state government to try to match west coast compensation.

> It is not exactly practical for state government to try to match west coast compensation.

It isn't, though there may be a sharp difference in cost of living and that's a strong consideration with wages. That, and a pension and benefits is taken for granted by younger people. Besides govt positions tending to be less exciting, you can really put some money away. Moving up, though, is a sluggish process.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact