Dtyjlui

I think you're asking the wrong question. I'm going to go ahead and say that challenge was probably designed for you to fail it:

• You've been given a really impromptu test, which is kind of weird outside of an interview setting. I've never heard of it happening like that before. If my manager suddenly did that, I'd stare blankly at him and ask what the heck this was all about (with more pointed language than the above.)


• Unless they're really trivial, 30 minutes to complete 9 separate programming challenges seems kind of insane, even for a "high flying" programmer. That's less than 3 1/2 minutes per task. Even if I were given a task to write in Java (my primary language for over a decade) I'd usually want to take around that length of time just to understand the problem, before writing any code at all. I think I'd certainly struggle with that timeframe, and I don't consider myself particularly awful.

So, taking a step back, looking at the facts and linking a few points here:

• You were hired knowing that they'd have to train you up. That training doesn't seem to have happened, so your knowledge probably isn't where they'd like it to be.


• You've had issues with your manager, which probably means (from his perspective) he's had issues with you and possibly sees you as a pain in the backside.


• He's given you an impromptu test that you were designed to fail, and then a definite 6 month timeline for you to significantly improve. (Of possible further concern is the fact this means they've given you until you would have been employed for two years to significantly improve, as further protections for employees kick in after 2 years in some areas.)

To me, this all looks like they're moving towards showing you the door while covering their backsides in the process. If it were me, I'd be looking to get out of there ASAP.

First, Update your resume, and submit it to a few recruiters and start job hunting.

This was a setup with unrealistic time constraints. Your manager has given you an undefined goal and is setting you up to fail.

The reason I say this is from the key points in your post.

• You and your manager have been having difficulties


• Your manager just sprung the test on you with no time to prepare


• Your manager gave you an unreasonable time to complete the test


• You were told that there needed to be "significant improvement", without a definition of what that entails.


• You have asked what I should be learning specifically but just get told 'it's your career, you decide'

You also mentioned that you haven't learned as much from your team as you liked.

This all makes it very clear that they don't want you there and the manager is setting you up to fail. You are being given unclear goals. They are refusing to tell you where you can improve, and yet say if you don't, you're gone.

What can I do to show 'significant improvement' from here?

NOTHING
You are being set up to fail, and to be fired for cause. Update your resume, apply to other jobs and get out as soon as you can before they ruin you.

Personally, if your goal is to improve, I would analyze the test itself.

Not with the intention to search/memorize the solution, but just to check why you didn't do well. What skillset are you lacking that is needed for this particular test.

Is the problem you don't know enough about different data structures? Then study in that direction.

Is the problem you struggle with algorithmic design? Then study different algorithms and how they approach to different problems.

Etc..

HOWEVER

I've never heard of this kind of impromptu test except during interviews, and I don't think anyone can solve 9 different tasks in 30 minutes, unless they are extremely simple. And the lack of help/guidance isn't a good sign either. You might want to think about other motivations here

Actually two things:

1. Get your resume ready. As suggested by @Richard U, you may need another job. Also, you should ask yourself if this is the right company to work at. As presented, it does not sound like they have a constructive and healthy way to deal with their employees. So if that´s the case you may want to move on anyways.




2. Work actively on your failures. Whenever you are unable to fulfill a task, try to identify why. Ask for help. In general, ask for feedback regularly. You should not be in doubt over your Managers satisfaction with your performance - only to discover differently, out of the blue. If you are struggling and you don´t think you can fulfill the role at all, with the resources at hand, you should have a discussion with your Manager if there are options to switch roles or get additional help.

On a side note: When ever you are presented with a coding challenge that you failed, the next thing to do would be learn how to pass. From your Manager´s perspective, you got a test you already knew and you did not show him that took it seriously. May be that they just want to see you take the initiative. After all, it IS your career!

Let's number the issues here:

1. I've had personal issues with my manager


2. and have struggled to complete some work


3. (and also successfully completed work within my skill-set)


4. and feel I haven't learnt from the team as I hoped I would.


5. In a follow up meeting, I was told that a 33% success rate is not good enough and that I need to show significant improvement in the next 6 months.


6. I have asked what I should be learning specifically but just get told 'it's your career, you decide', which frustrates me.

The other answers have been largely focusing on #5, but there are six items here, and #1 and #2 are the central ones. You didn't go into what all the issues in #1 are, but if there's anything you can do to address them, that should be one of your priorities. If you're having trouble completing some of your assigned work, that's also an issue you should be looking at. #5 is rather strange. The test was originally for screening applicants, and in that context a 30 minute test makes sense: the interviewers don't want to spend several weeks with each applicant seeing how they work on a team, so the necessities of time constraints induce them to use a proxy. But now that you've been on the job, it's odd to be using a proxy for your productivity, rather than your productivity itself. While perhaps the test has some usefulness in producing a quantifiable number representing your proficiency, you and your manager should be focusing on your actual day-to-day activity; the two of you should be focusing on #2 and #3. Why are you struggling? How can it be improved? Why have some tasks gone well, and can what happened there be translated to areas where things aren't going well? Can more of your workload be shifted towards tasks within your skill-set?

You should also be looking at #4. Why aren't you learning from the team? Can you do anything to improve that? Can the team do anything?

Item #6 is also very problematic. In #5, your manager said that it's up to them what you need to improve on, and then in #6 they said it's up to you. That's quite inconsistent. You do have a career, and it's up to you how to pursue that career, but you also have a job, and it's your manager's job to tell you what they want out of you at that job. It's not up to you to decide what skills and tasks would be most useful to the company, it's the company's.

The most charitable interpretation of your manager's behavior is that they have been frustrated with #2, and did #5 simply because they felt that it would be easier to talk about a concrete, quantifiable example of you not working to their expectations, rather than trying to talk about 18 months of day-to-day experiences. The less charitable interpretation is that they really think that #5 is the proper focus. In the first case, you should be talking with other stakeholders and finding out what is important to them and how you can improve on delivering it. In the second case, your should be trying to get your manager to focus more on #2 and, as the other answers say, working on getting a back-up plan (i.e. another job).

I have a completely different take on this. Maybe treatment and test were not the most clever ones possible (I will not delve into this), I think that giving you 6 months to improve yourself while paying you is a great opportunity.

First of all my recommendation would be to suppress your ego and be grateful that they don't kick you out but want to give you 6 months to improve while paying you. Sounds like a reliable workplace to me.
If they wanted to kick you out, there are shorter methods in a matter of a few weeks. I believe 6 months means they want you on board. Maybe they don't have capacity or don't know how to help you. Here lies an opportunity for you!

Then try to remember the tasks from the stupid test and make sure you can do it next time even if tasks are different, make sure you know the things well enough to do it next time even if tasks are somehow different. I've been in a situation in uni where we were given some logical tasks. Not hard but time was greatly limited. I had to spend a couple of days exercising so I can do them very quickly to get a reasonable score.

Then try to be helpful to the team. Even simple things like helping with documenting the products/infra/CI. See where things are flaky and try to improve them. No need to show that you became a rock star. Just honestly helping the team as much as you can will most likely be enough to get the necessary support and become a valued member.

When you have a practical coding task, try to understand what you are doing. This is very important because I see many people not realize that they do not really understand what are they doing. E.g. we need to read something from a file. You need to understand everything from opening in correct mode, handling errors while reading it, reading it in a memory efficient way, making sure file descriptor is always closed regardless of errors while reading, etc. Truly understand why you do something and how you do it. This is what will make you successful.

Another thing I see lacking in many "workers" is truly understanding why a feature is implemented. Try to understand who will use the feature, how will it be used. Imagine you are the user and how need the feature work to really please you.

Think about maintainability. If something is on the performance critical path, then optimize for speed. But otherwise think a lot about maintainability. e.g. do not add more external libraries than needed, consistent coding approaches, proper separation of concerns, etc., etc.

But again, try to help others. When you help others, you are building credit like in a bank account. You can then use that credit to seek help and support for yourself, ask for rises, etc.

HTH

While I agree with other answers that the best call is probably to polish the resume and jump ship as soon as a better opportunity presents itself I think this is a classic example of Hanlon's Razor - the manager isn't necessarily setting you up to fail. Far more likely that they are a one-trick pony when it comes to evaluating programming ability. And that trick just happens to be this "kata" thing.

It means you could probably easily game the system by just practicing this artificial test a lot over the next six months but why bother? If they don't have a clue how to evaluate your performance properly it's going to be an on-going battle to get any good work recognised.

I'm just going to give it you straight and hard. Your boss is a hapless twat. Katas don't prove any knowledge about programming aside from the ability to solve katas. Just make this job look good on your resume and then find another job; just dipset.

Also, no one can do 9 parts in programming in 30 minutes without having specifically prepared for that. There are entire communities dedicated to studying for coding interviews. Your work very likely has nothing to do with whatever question he gave you. If your manager thinks it does then they can't code. Your being hired despite failing it the first time is proof that your manager is grand standing without any deep knowledge of the subject.

Others have suggested looking for a new job, and I agree but would like to add some understanding of why you should do that.

Some companies are toxic. They are driven by silly, unrealistic tests such as this one rather than the demonstrable results of your work. It's actually quite hard to measure performance, e.g. if you help others with debugging it doesn't benefit your output but it's of great value to the company.

This kind of testing suggests that the company sees developers as machines that are there to perform certain tasks, not as individuals with useful skills and who contribute to a team and the department as a whole.

When looking for a new job you can check for warning signs that a company is like this. A little bit of testing at interview is fine, especially if you don't have much experience or work history, but ideally they should be talking to you about how you would solve problems and looking at examples of your work. You should also ask about how your performance will be evaluated, looking for consideration of your results and contribution to the team. Being able to agree specific goals with your boss is another great option.

It’s been said before but you should get out. Eighteen months is fine for you to be looking to “step up” to a new role in development elsewhere.

It’s often hard to shake off an image of “not an X”. You are “not a dev” at your current firm and that will stick around for way too long given the way they are behaving. Moving to a new job as a “self taught dev in first role” somewhere that mentors devs will be the ideal start.

It’s been said on comments what your boss seems like. How can you learn mastery of development in such an environment? Ideally pick your next job because you get to learn from people you want to be more like. Your biggest barrier will be “imposter syndrome” where you don’t have the courage to join as they seem so far ahead. Overcome your doubts and fears I did...

Think hard if your being held hostage to the current job as they “gave you a chance you might not get again”. It’s only the only option till you find something new.

A final point is that real devs learn and code from google and stack overflow like everyone else. So code tests only have use for screening people who claim they are experts and want to charge max rate. So sure it’s something you should practice at some point in your career but people should judge what you score based on your claimed expertise and claimed experiences.

As an aside an interview technique I used is to ask devs to draw the systems they worked on and deliberately ask them to explain the parts they didn’t work on. Not to give them a hard time but to see if they can honestly say they don’t know. Then we talk through what that bit needs to do and figure out how that bit might have worked. What I am really doing is seeing if I asked them to work on something new we can figure out how to build it together. We co-design how we might build whatever it is. So it’s a real world job scenario for an agile developer talking about something neither of us really know about to see how we could work together. I have had men be angry at me for this type of interview (“I said I didn’t work on that bit stop trying to discuss it with me!”). I have had people just make up nonsense. Women tend to do way better in such an interview.

Agile software engineering has many soft skills aspects. On my current gig on java microservices we just took on a self taught ruby dev. She is nailing sorting out getting a new piece of functionality spun up due to her enthusiasm and openness. She can learn java from the code we have and the other devs as she goes.

Good luck!

Can you find the test somewhere online? or a similar one? or do you remember the tasks? Hard to assess what you should do if we don't know if the test is reasonable. Might be a bad practice from your manager but he could also have tried a lot before and that was his last resort.

What would you do if it was a normal work assignment? Just start coding? A reasonable response from an experienced developer could for example be an estimate, only you know how long it takes, so that's your job:
- task 1 I can do in 5-10 minutes
- task 2 I need at least 20 minutes, probably 30
- task 3 I have to lookup how to do an aggregate in C#, then it's 10 minutes, without internet I can code it manually using loops in 30 minutes
- task 4 ...

Then you add them all and ask your manager for priorities, that's his job:
All together will take longer than 30 minutes, so which tasks should I focus on?