Zrjydtj

No, it is not okay to expect that of your employees.

You say:

Assume a non-toxic environment. A manager saying "You better study over the weekend or you're fired first thing on Monday" is, unquestionably, a reason to pack your things and go.

But how is that not exactly what is implied when you tell a junior walking in the door that you expect them to spend their own personal time learning the stack. If I explicitly tell one of my employees what I expect of them I am prepared to have repercussions if they don't meet those expectations.

What you can do instead is reward people who go above and beyond. But I would caution that you watch the culture you are establishing and be careful that you don't implicitly make it an expectation.

TLDR: It may be appropriate to expect an employee to study a new technology outside of their 40 hour work week, but such expectations should be reflected in their compensation.

I think the issue is more nuanced than the question you refer to might indicate, and the question contains confounding factors. It may also depend on local custom and labor law.

In the US jobs are divided into exempt and non-exempt. Roughly, exempt employees are paid an annual salary, and routinely exercise their professional judgement in their work duties. This may include making their own judgment about how many hours they will work in a given week. Non-exempt employees are generally more closely supervised, and work for an hourly wage. The exempt worker is expected to work enough hours to accomplish their duties. If that means putting in 80 hours in a week, so be it. A non-exempt worker may be required to work overtime, but they absolutely must be paid for it.

So the question arises: why would anyone take an exempt job over a non-exempt job? Well, the primary attraction is the greater scope for exercising professional judgment. It also usually includes a salary that is higher than the expected annual earnings for the hourly worker. However, the unpaid overtime for the exempt worker may result in a lower "effective" hourly wage than the non-exempt worker. To sweeten the pot, employers may throw in 'upside' for the exempt worker: bonuses and stock options. They may also get more flexibility in their working hours. For example, I don't have to go off the clock if I have a dentist appointment in the middle of the day. If all my tasks are in order and I feel like leaving early on a Friday I can do so.

The problem comes because some employers view exempt employees simply as a way to get free overtime. Bad employers may require the long work weeks, but not really come through with the financial upside, flexibility, or professional autonomy. The worst employers will try to bully their exempt employees into making a silk purse out of a sow's ear. Demanding that a very junior software developer convert an even more junior Java developer into a full-stack web developer on their own time without some sort of generous compensation is an example of the later approach.

I would expect a computer science graduate in a salaried position to be willing to put in some study time at home to pick up a new technology for their job. I'd even expect them to put in very long hours (say 60-80 hours in a week) for short periods to accomplish some business critical task, but I'd also expect the employer to make it worth their while with salary, bonuses, or stock options.

TLDR: Expecting employees to do regular work (incl. self-training) in their spare-time is not okay. Expecting employees to do emergency tasks outside of work hours in a reasonable amount, taking the wishes of the employee into account, and compensating that with money/time off is okay as long as it's officially communicated early or not enforced (clearly voluntary).

There are some different aspects that might be mixed up in what you are asking and that might be conflated in what you perceive as the norm:

1. A general view by developers that part of their profession is keeping up with new technology.


2. A general expectation from an employer that developers study the stack used at work in their spare time without payment.


3. A general expectation from an employer that developers do extra time when there is a deadline or otherwise critical issue with a time constraint (e.g. emergency on a live system).


4. Developers putting in more work than required.

As for 1), yes if you want to retain or improve your market value you better keep up with technological developments. How you do that, i.e. during work time or in your spare time does not matter. This is nothing you absolutely have to do to stay employed, but it's a good helpful attitude to help shape a successful career. If you value your free time and prefer to spend it with non-coding things, you make sure you can do the bulk of this keeping up with technology on the clock. Otherwise you might do part of it for fun in your spare time. And if you don't care, you just don't do it, but it will likely limit your options regarding jobs and projects.

As for 2), this is absolutely not the norm in any decent company! However, especially in startup culture and companies that manage to attract many people who want to prove themselves and/or are unexperienced enough it may be widespread enough to appear like the norm. But a one-sided expectation to work unpaid is not a healthy work relationship and I would quit any such job in the long run.
Suggestions from superiors to learn something or do some other low relevance work related task over the weekend would irk me, likely be countered with a sarcastic remark and I would very likely simply not do it (unless I really need the job for now, but that would trigger the job hunting really fast).
Again, if a developer feels he wants to spend time learning something by himself on the weekend, that's totally fine, any pressure from the employer is not.

As for 3) as long as any emergency extra time is compensated with extra time off at another time, i.e. as long as there is a give and take relationship, that is totally fine. In particular, the employer needs to do proper planning, and respect time commitments of the employees outside of work, i.e. approved vacancy should stay approved unless absolutely necessary to cancel it. If an employee needs to leave early sometimes, that should be part of the give and take and not require much hoops. In such a relationship, there's typically "official" over-time, that is lawfully requested (in European countries this might require a certain notification time in advance) and can be enforced and unofficial over-time that is done by the team knowing the deadline/problem without any pressure by the employer. I.e. the relationship needs to be so healthy that the team does this out of their professional ambition.

2) is different from 3) as there is a mutual benefit and a mutual understanding that both give and take and that each partner only takes when it's necessary. Learning a new framework is part of the daily business and thus is something that the employer needs to factor in when doing the planning for a project. If all hell breaks loose and learning a new stack is part of trouble shooting or emergency deadline run-up (perhaps because the relevant developer with that skill got hit by a bus), that's okay (again, if properly compensated), but it cannot be a standard expectation.

4) is also okay, if this isn't based on any fear that people who don't do this get fired. However, it is typically also in the interest of an employer to make sure his employees take time off to relax, as more time spent working does not necessarily mean more work being done and burn outs etc. are also damaging the company as it may loose a valuable worker for quite some time. So such voluntary work should be limited in general.

From a legal point, at least in Europe working times are often strictly regulated officially. E.g. in many country working on the weekend or beyond a certain daily hourly rate can get employer or employee in legal trouble. Same goes when there is an expectation from the employer for employees to do over-time, often that needs a special contractual basis and/or needs to be decided in agreement with employee representatives and announced well in advanced by law.

As long as it's reasonable, and you're not being forced, it's okay.

Admittedly, the line is blurry. You must set a good work-life balance early on and keep it throughout your career.

For some people, "going the extra mile" (assuming said work-life balance) for a role is a must, and they well spend numerous hours of unpaid overtime to better themselves and appear more passionate and commited to their employers. Maintaining the balance is tricky, however, and the situation could get complicated if your employer "learns" to expect you to work overtime for free. I personally feel that this is okay when you are starting out and have a lot of stuff to learn, but the limits must always be clear to everyone involved.

On the other hand, when the employer (or the supervisor) asks for such unpaid overtime, you might feel pressured to spend hours studying and show results of such studying in the workplace. If at any point you feel forced to do something you normally wouldn't do without the fear of getting scolded or fired, you might be a victim of toxic management and should probably seek employment elsewhere.

BUT a lighthearted suggestion from a "mentor" that you could read up on this article or watch this tutorial over the weekend as you might find it helpful, is entirely appropriate, and if you are a junior eager to learn the ins and outs of software development you should take advantage of any chance to improve your knowledge! Again, without compromising your work-life balance. Only commit time you're willing to invest.

Free time is your time. Unless agreed otherwise, you're free to do whatever you want.

Those are your legal rights, and your manager should respect them.

That is, a manager that ...

• 
  directs you to learn in your free time violates the law
  


• 
  honestly advises that learning in your free time would advance your career is ok
  


• 
  asks you to agree to learning on your free time when negotiating your contract of employment is ok.

In the linked question, the team lead "told him he needs to". That is, the team lead directed, which is not ok.

In your case, you came to an agreement with your future manager that you would learn in your free time in exchange for getting the job. You knew your manager's expectations up front and could freely decide whether you want to do it.

The employee in the other question was denied that opportunity.

No it isn't.

I'll link this question because it's relevant to the situation. In short, it's your responsibility to develop your career and it's also your responsibility to be a better coder. The nature of our industry demands continuing education. It's not a new idea. Robert C. Martin suggests it, about 20 hours of it actually every week. Outside work. It's not unreasonable for an employer to expect career professionals to be developing their careers. We aren't making burgers, we're building complex systems that require a lot of work and a lot of developed skillsets

Part of your job as a developer is to understand the stack. No always muddle through similar problems over and over because you haven't taken the time to internalize any knowledge. It isn't an unreasonable request and more importantly, it's your job.

Finally, to not expand your knowledge in a knowledge economy seems, absurd. Forbes suggests exactly this to new grads.

“As we move to a knowledge economy, the number of jobs where people
can simply turn up and be told how to do the job and be well paid for
it is diminishing rapidly,”

From the Wallstreet Journal

You have to. Because if you don't, the person who replaces you likely will be doing it.

Other, well-established SE community members, with high point scores, are very intelligent and competent coders... but I'm afraid that maybe they don't remember what it was like to be junior developers trying to eke out a living in a competitive job market. I think maybe their answers are somewhat misleading, for the OP's situation.

Being a junior developer is tough. You will occasionally (okay, frequently) be asked to invest a higher level of uncompensated time and effort that is not fair, and may possibly be contrary to the letter of the law. But you won't complain. (The company can readily find a more time-efficient replacement; you do yourself no favors by trying to track your time accurately.) You will have to sacrifice evenings and weekends to even begin to be capable of listening and doing as your are told to do on Monday mornings.

The listening will be one-way. Bugs you find in existing code, inadvertently placed there by your bosses and mentors, must be handled with a great deal of finesse; feature requests you make, or UI/design decisions you make, will be placed at the very bottom of the organizational queue and probably ignored. You will have limited access to system passwords and configurations, which gives you fewer options to quickly build something that demonstrates outside-the-box thinking. There are other anti-perks to being a junior developer, depending on the company culture.

That doesn't mean that your supervisors and mentors are bad people! They are probably very optimistic, and over-confident that you can quickly pick up the relevant skills from a couple hours of off-the-shelf tutorials. (They can!) And, if they are willing to review your code on "Hello World" demonstrations, open source contributions and hobby apps--things that add nothing to the company bottom line, and give you transferable skills--they are willing to make that small sacrifice for your success.

The alternative is to not be employed at all in the industry with your current skill level. The only way to acquire skills would be to (slowly) learn 100% on your own, unstructured free time, for no pay; or learn in college, university or trade school, which costs money and leads to student loan debt.

When you get past that level, you will look back on it and you will believe it was worth it, absolutely.

Note: I am the person who wrote the top-voted answer you referred to. This is my opinion.

The situation you describe I would consider to be acceptable, while (as you noted) the situation in the other thread was not. The difference is that, in your case, the situation was presented upfront. If you walk into the interview and the interviewer says to you "We're willing to interview you and consider you seriously for this position, but your tech stack doesn't match ours and you're going to need to do outside work to catch up", at that point you are free to say "Thanks, but I don't want to do that, see you later" and go on your way.

In the referred answer, the person in question was hired based on a skill set they had, with no indication they'd need to retrain. They accepted an offer and got blindsided by this situation. The important part is that, while you can interview simultaneously with many different places, you can only accept one offer, and that means you have to decline all other offers. It's possible in this situation (from the linked question) that the person in question declined offers that he would be better suited to in order to take the offer at this company that blindsided him, and that's not acceptable. That's not even to mention that if the situation is presented in a first interview (or even a phone screen, which is more common), you can save a whole bunch of time; it takes 30 seconds to make such a decision, and save hours of interview time which would be otherwise wasted (by both parties!) in going through an interview for a job which doesn't fit.