I appreciate this may be fairly opinion based (and of course will vary from company to company), however - I'm hoping there may be some general rules of thumb in terms of what a hiring manager would expect.

When hiring for a (long-term permanent) mid-level candidate, if not specifically stated, how much learning would a hiring manager expect a candidate to need once hired?

For context, I've been working at a single company since graduating - and while I've moved up twice since beginning as a Junior, this is within a very specific toolchain and organisation.

What concerns me, is if I look for other roles; compensation wise I realistically should be looking for mid-level roles. However, I would expect to need some time to fit in properly and learn the new technologies I'd be working with.

As I've only ever worked in this one company, I'm unsure what the general expectation is from hiring managers (for mid-level roles). Do they expect that I'd come into the role and be fully competent within a few weeks? Or do they expect that a new hire, even at mid-level, will not be contributing near their full potential for some time (e.g. for the length of probation)?

There's no universal "correct" answer to this in terms of time - what does matter though is to understand what the expectations are in the specific role.

Usually this can be garnered during the interview process - to give a couple of differing examples (these were contract roles but are still broadly applicable)

Role 1: Highly regulated industry, extremely complex existing code base

New team members were considered to be only 60% as "productive" (represented as capacity in TFS) as established members until ~3 months in. This wasn't a "you only have to work 4.8 hrs a day" thing - it was just the case that it would take a new person longer to accomplish a given task because they would have to go hunting for something in the code or would need to take some time to understand something or ask someone for info. All things that naturally reduced as your knowledge of the company's code and business built up.

Role 2: Fast paced industry, role specifically to help reduce backlog

The code base was large, complex and labyrinthine - but the tasks being given were small, self-contained and well documented. This was all made clear right from the very first conversation and it was expected that you'd be productive from day 1, and this wasn't an unreasonable expectation.

So it varies quite a bit!

When I've hired mid-level guys I expect there to be a few weeks learning curve to any new environment or technologies. Anything they've claimed competence in during the hiring process I expect them to know though, anything business-specific get's a great deal more leeway.

Onboarding a new developer can vary depending on several things:

• Complexity of Code


• Complexity of Industry


• Organizational Processes


• Development Processes

This assumes you were the PERFECT fit. Often, even mid-level and Lead / Senior hires tend to have missing items on the required toolsets.

Broadly speaking in the simplest of terms, it takes a few months to be comfortable enough to move around in the system and know where things are in a broad sense. But anyone who says less that 3 months is living a fantasy. It can vary greatly between 3 months and 2 years. As a mid-level developer you'll definitely have to navigate not just the code, but also the business too. Maintaining code for a static website with a few forms compared to say, a bank which has legal obligations and constraints on how and what the technology can do will create different kinds of challenges in that regard.

In my view, if it's your everyday web app (few front end pages, simple forms, with some business logic) then I'd say anywhere between 3-6 months.

But if you're working with driver software, banks, avionics, telecom infrastructure... expect a longer onboarding process.

The fundamental truth is normal jobs take some onboarding. In development it's even MORE complex because while the tech stack might be a perfect fit (assuming it is), even then you have to learn how it's been architectured, their style guide, how they do development and how they solve problems. Not all firms are the same. Not all code bases are the same.

Some firms will have massively abstracted and complex systems and others will have very simple and straightforward systems. I'm not making a judgement here, I'm just saying, it can vary widely.

... and all this assumes your skills match perfectly. Often compromises are made in the hiring process. So maybe you have an experienced Java developer who is also comfortable with SQL but has never really worked with React. You might take on this candidate and accept the temporary inefficiency of this dev learning React while working or you might send them for training. Either way, they're not running at 100% efficiency.

Also, this isn't even including the culture of the organization. Are they helpful? Do you get support as needed? Are you on your own? Does the organization push tight deadlines with zero support? Do they provide full support when you're stuck?

All these things play into the onboarding process.

UPDATE:
Peopleware, mentions this as well. They note the value of knowledge workers (developers) and how the onboarding period can make them remarkably inefficient in the beginning. In fact costing a firm more money before they make money. This comes from the fact that a new dev will require support from other devs, thus reducing other people's efficiency. They mention that this process, depending on on a host of variables, can take a very long time. Which is part of the case the book was making about the notion that developers are just interchangeable cogs, they are not and the onboarding process is a clear example of why they aren't.

I'm unsure what the general expectation is from hiring managers (for mid-level roles). Do they expect that I'd come into the role and be fully competent within a few weeks? Or do they expect that a new hire, even at mid-level, will not be contributing near their full potential for some time (e.g. for the length of probation)?

That depends on the skills and and experience that you list on your resume and how you sell yourself during the interviews. If you claim to have knowledge and/or experience of X on your resume and further make claims to X during the interviews and are hired. The company can reasonably expect that you will immediately be able to perform X.

Now keep in mind, that most job listings will have requirements that you may have little to no knowledge/experience on. In those cases, the employer ( if they studied your resume and interviewed well ) will know what skills you are lacking in and will give you leeway to learn or get caught up.

There are also procedures/nuances specific to companies that a reasonable company will not expect you to automatically know.

The bottom line is if you are honest with what you can and cannot do before being hired, you should have no issue integrating with a company after you are hired.

Every code base has the core logic and business logic. I imagine in a scenario where you are hired in to work on X, they would expect you to know the core logic with minimal guidance (ex versioning repo, url, etc). I would imagine getting it set up and ready to code should be relatively painless and without any sort of help other than setting up passwords and accounts.

Now for business logic, I imagine that the employer would expect you to know how to integrate their business logic into the code with minimal guidance from them as far as where to put it in the code or when or how.

It mainly depends on the expectation of a company. At a reasonable pace, I would think the initial environment setup shouldn't take you more than a few days. Setting up the repo, your accounts, etc shouldn't take more than a day. Learning their business logic can be a fluid task where there might need some explanation and perhaps a reasonable slip up on your part (ex you didn't know something about the internal rules of the company).

I think at most, a month is a good time frame. Perhaps 2-3 weeks before you're able to get your first - small - task in. I don't think, at least I would hope not that they'd expect you to start working right on day 1. That might be a indicator of a sweatshop style work environment.

Plus this isn't 1990s where you can get a desktop and start working. There needs to be license setup, configurations, etc, etc done on your part to get things working. That would take some time on their (company's) part as well.

Here's a thought. Someone said this once, and it sounds right to me.

It's the minute / day / week / month thing.

1. Contractors. You instantly (in the literal sense) need to be creating money for the company. There is no time to be doing things like "I'll just set up my repo / coffee machine / email / whatever". You get a phone call, the clock starts running at a few dollars a minute and you start solving the problem at hand, advancing the code base, executing the project scientist's ideas, or whatever the case my be.




2. Senior coders. You can take a couple days to pretend you're setting up your assistant, office, the pipeline etc. Then you need results.




3. Mid-level coders. You can get away with a week thinking about "architecture" or the like. The day after that you need to make a serious contrubution.




4. New junior coders. For the first month you can sau you're freshening up on a language or such.

(Come to think, here's an actual example. We recently started using the services of a bloke, who gets mid-level rates. He's a leading technical expert in his speciality. Now, the guy had to quickly learn a new system never seen or even installed before. Indeed, that took the first week of time. So it's spot on in that example.)

In answer to the general theme of this fascinating QA:

However, I would expect to need some time to fit in properly and learn the new technologies I'd be working with

Hmm, unfortunately I would say no, that's not right in programming.

The nature of programming, the very raison d'etre, is that every thing you do is novel; "everything is learning". All environments and languages change all the time.

Do they expect that I'd come into the role and be fully competent within a few weeks?

I can't really think of anything that could take "a few weeks" to brush up on at the mid level. It can't take more than a few hours to learn any given language or environment. And to "get in to" a technology to the point where you're contribution is greater than your paycheck indeed takes a week or so.

With juniors, everyone will roll their eyes and say "well X is learning to program". But, I don't think, you can be "learning to program" as a mid-level serious employee. Sure, it might take "some days" to pick up on what the team is up to.

Or do they expect that a new hire, even at mid-level, will not be contributing near their full potential for some time (e.g. for the length of probation)?

Sounds like you have a week! You know, this is one reason that, it is often said it is dangerous for programmers to stay at the one job a long time. Flexibility / creation is to programmers what punching is to boxers - changing jobs really keeps you sharp!

Enjoy!