28

It's been 4 weeks into my internship and I have stopped feeling lost, which I was feeling 2 weeks back. I had been asked to build a tool in react. Initially I was very nervous as to how would I build it but over time I figured stuff out. It's been going fine until now. Now it has reached a standpoint where my mentoring is asking me to implement stuff which is not even possible using JavaScript (some feature where you would convert JSON into some API spec).

The tool he is asking me to build is not possible in the timeframe if it's only me who is working on it, which is what is happening. I am not a react/JS expert but it might be possible for someone who has been doing this for years. I am getting bad anxiety about what's gonna happen in the coming days (only a month left for my internship to end). The mentor has no knowledge of JS/react or anything. He is some architect level guy separate from my manager's team with expertise in java kotlin. Manager is clueless about what’s going on as he has hardly ever attended status calls.

Most of the times I am scouring Stack Overflow/Google for help. It's been really stressful; even on weekends and post work I am working on it, basically figuring stuff on my own without any guidance. Sometimes I question myself that “am I doing it the right way? Is there a better way to do this?”. I am worried about how the manager will measure my performance and make a decision on the return offer. Any tips would be really helpful.

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – motosubatsu
    Jul 7 at 17:10

8 Answers 8

97

Slow down. Take a deep breath.

You're an INTERN. Use this opportunity to learn as much about this company's environment as possible instead of focusing on a deliverable. It simply makes no sense that you'll be solely responsible for a production component. If you are, then the company is garbage and ran by morons. If I was a client of that company and I found out about it, I would drop that company in a heartbeat.

Take your time and digest what is happening. Why is a temporary INTERN being responsible for something like this? How are they ramping you up? How do they prevent catastrophic damage done by someone that is incompetent?

And go back to working normal hours. If they complain about you not working "hard enough", ask them what exactly does that mean? Ask for help to learn.

Don't waste your internship by grinding out ridiculous OT hours. It isn't going to help you, and the company is outright abusing you at that point.

5
  • 12
    Unless there is something seriously fishy at this company, they hopefully aren't actually relying on an intern to actually build a perfect, deployable product start to finish. If they are then they are completely ridiculous. But on the other side, sticking at it and making something will look great on your CV/resume and give you lots to talk about in future interviews!
    – R Davies
    Jul 7 at 7:46
  • 6
    I would qualify this a bit. If the intern were working closely with other seasoned developers, it wouldn't be out of the realm of reasonable to be a contributor to production code. But, the contributions would be closely supervised and reviewed as a matter of course. That being said, being the sole developer using unfamiliar technology under a short deadline is completely irresponsible of the company let alone doing that to an intern. The other paragraphs are fine though. Especially the part about being taken advantage of. Jul 7 at 18:04
  • 2
    Could also be that the company does not really care about the end product. Just some nice to have functionality. So they might get lucky with a really talented intern, or they take their loses (which is not much when/if paying an intern) Jul 8 at 12:45
  • 2
    Overtime is an easy habit to fall into as an intern; you're probably used to school/college/university where you have coursework with deadlines on a schedule, and a finite amount of work to do before you finish your studies. Staying up all night to do coursework on time is a strategy that works in that scenario, and you'll have some days or weeks to rest before the next is assigned. At work, if you stay up all night to finish, in the morning they'll give you more and your managers think that's your capacity, so however much you do in a week, that's how much they'll expect the next week. Jul 8 at 14:46
  • Also, note that in some geographies, it's actually illegal for interns to work overtime - check the situation in your area Jul 9 at 14:20
37

Do NOT work overtime on this. 40 hours a week, then you stop. The reasons: One, you don't get paid for it. Two, your performance drops rapidly. Yes, in one month with lots of overtime you will get less done than in one month with no overtime.

First you move the responsibility for this to where it belongs, and that is your manager. If it is important that this is finished before the end of the internship, that's HIS problem and not YOURS. Let him not sleep, instead of you.

If you say "it's not possible in the time frame", that's not negative. That's very important information for your manager. It means he or she needs to drop the feature, or allocate a lot more time. So your plan is: You relax. The fact that this isn't going to be finished isn't your fault (between you being an intern which is less than a junior developer, and your mentor not being able to help), and it isn't your problem (it is the manager's problem). Then you take what you know and take it to your manager. Then he needs to do his job, which is managing.

17
  • 9
    @Evorlor: My personal experience says it's plain wrong. Yes, regular overtime will be bad for productivity in the long run (and has a lot of other negative side effects, too), but there is a reason companies have crunch times, and, no, the reason is not "They are all stupid and like wasting money".
    – Heinzi
    Jul 7 at 16:00
  • 21
    Heinzi, I somehow managed to avoid any companies with "crunch time" for the last 26 years, and they've all be doing fine. It's planning, especially in the long term, not promising what you can't deliver, and respect for you employees.
    – gnasher729
    Jul 7 at 16:46
  • 8
    @Heinzi companies have crunch times because they want to get something to the point it can be shipped and billed not to the point it is good. Experience tells me that most bugs and bad design decisions come about during crunch time, but that's "okay" for the companies, because they believe once the software is out of the door, those things can be patched later on, after the money hit their wallets and the client is happy.
    – T. Sar
    Jul 7 at 17:58
  • 4
    Don't get me wrong: In my company we also don't have crunches, and I wouldn't want it any other way. I'm just saying that the claim that "in one month with lots of overtime you will get less done than in one month with no overtime" is not generally true.
    – Heinzi
    Jul 7 at 18:12
  • 8
    @Heinzi: The "overtime gets less done than normal time" aka burnout is certainly not true in one day (you've reached equal productivity before the overtime clock even starts) and probably not true in one week. For multiple years, it's definitely true. Where the break-even point is I don't know exactly; if I had to guess I'd say 2-3 months but I wouldn't be surprised to find it was only 3-4 weeks.
    – Ben Voigt
    Jul 7 at 22:02
23

Two important skills for a software developer are:

  • Making realistic estimates if something is possible and how long it will take
  • Communicating those estimates

It's an everyday occurrence that a software developer goes to a stakeholder and tells them: "Well, I looked into how we could accomplish [thing] within [constraints], and after some research I found out that because of [reasons] it's technically impossible, or at least not possible within the timeframe and resources we have. So if you really need that, then we need to find a different solution".

What will probably happen next is that you and your mentor start brainstorming alternative ideas together. They might tell you about a way you weren't aware of which actually makes it possible. Or they might start to pitch alternative methods for achieving the business objective, asking you to evaluate if they would be more realistic. Or invite you to think outside of the JavaScript box and come up with alternative solutions.

4
  • I definitely agree with the bullet points. To solve the OP's problem he might produce a plan which will take a long time (and money, even if he is an intern) Start working on phase 1 and show the mentor how good he is at estimating and working to plan and communicating progress. Jul 7 at 16:30
  • 1
    I think this could be improved to help OP deal with lack of knowledge - a common blocker when doing work for the first time in any software team. Their initial estimates and assessment of the task as an impossible mountain could be far off, and won't be helpful in any case. Instead the OP could propose a training/knowledge gathering plan after which they hope to deliver some basic estimates for completing the work. If the employer is willing to fund an online course or similar in the relevant technologies, that may also speed things up compared to frantic Googling Jul 7 at 16:38
  • E.g. the OP could suggest "1) I will do this introductory online course related to the subject, which says it takes 40 hours", "2) I will try a basic prototype of the system for 1 week (another 40 hours)", "3) I will then hope to be in a position to properly plan and estimate the original task". If they need help identifying a suitable technology to learn (I suspect it is Swagger related, but don't know), then that could be a question to their mentor or to Stack Exchange. Jul 7 at 16:42
  • And use the Scotty Principle when doing the estimates. Jul 9 at 21:18
3

I would just be as honest and upfront about it as you can. In the status meetings, talk briefly about any roadblocks you are hitting and, if they don't provide any help, just churn away on the problem in your own pace, without doing OT, or particularly worrying about it. If you're learning some new coding stuff and generally experimenting then it sounds like things are going well.

Because my first thought is that you have been helpfully brought in as an intern by a company (probably out of habit -- they bring in interns every year and oh look, it's another year, time to bring in some interns) and hoisted onto a mentor who doesn't really know what you do, or, possibly, care, and has come up with something off the top of his head to keep you busy and that's really all there is to it.

The purpose of status meetings is to bring up roadblocks and problems so that other people can help clear them up and if that's not happening then you're doing your part and they aren't doing theirs. My suspicion is that there's a glowing letter of recommendation waiting for you (roughly the same one they give every intern, every year, with a slight change of insert-name-here) and stressing yourself out over what is actually just some literal busy work is not what anyone intended.

3

A bit of a frame challange: instead of talking about possibility, try to reiterate with your mentor what is actually required, and confront it with what you can do in the given timeframe.

My hunch is that you may be overthinking what is actually required, or that that you are overestimating cost of some integration. I know I used to do that a lot, and I still do once in a while. A senior dev is likely to have a good grasp of such things, even without language-specific knowledge.

From your story my impression is that you didn't discuss the requirements too much, you were given a task and then you went "figuring stuff on my own without any guidance".

My next goal in your situation would be to set up a discussion with your mentor, so that he can explain to you what needs to be done, and make design decisions. You can start by explaining how you understand the task, what work that implies, and which parts are unclear or require more research, but you can also just ask for explaining it from the beginning by your mentor. Then tell him what you understood and where you see issues.

On the technical side, some basics that you need to figure are:

  • What is the input?
  • What is the output/result?
  • What needs to be handled on client side?
  • What needs to be handled on server side?
  • What needs to be handled during compilation?
  • What external libraries should be used?
  • Do external programs/binaries need to be used? What programs?
  • What is the interface for the external programs, what is input and output?

By clarifying answers to these questions, you should be able to better either pinpoint the actual problem, or answer some missing question. This would also make the scope of the task much clearer, and allow you to point out what you are missing.

The goal of such discussion would be two-fold. On one hand, you get the guidance. On the other hand, you kind of push onto your mentor figuring out what the hard parts of the task are. Be confident in saying what you can do, but feel free to point out what you

  • don't know how to do,
  • don't know if can be done, or
  • expect to take long time.

Good luck!

2

Speaking as someone on the flip side of the situation, generally: as stated elsewhere, it is relatively unlikely that the architect is completely unaware of what can be accomplished with the tools, even given a particular time frame. Much more likely is that there is a communication breakdown. This can be true even if their intent is to "challenge" you: they should have better communicated that that was, in fact, their intent.

What I think a number of the existing answers have missed, however, is this: if this is the person who is primarily responsible for assigning the work that you are doing, on a technical level, your first step (whether you're an intern, a junior developer, a senior developer, or even an architect who has to report to a more-senior architect) is to go to them and simply say "I think that I may not be understanding the request accurately, or missing something else about it, because I'm not seeing any path forward on this that can be successful given the current constraints (of time, technical skill, or whatever else)."

Apart from trying to be very up-front about it to prevent stress or negative situations, I would absolutely up the stakes for an intern who had done something solidly, after praising them and making it clear that they had succeeded at the task I initially set them. Because the initial task would have been relatively low-hanging fruit specifically so that I could be confident that they would have a pretty good chance of succeeding. To give them the best benefit from their internship, I would then give them additional work (read: responsibility) gradually, until it reached the limit they could handle or we ran out of time.

Unfortunately, not managing to "telegraph" this to someone is a really easy and really common mistake for folks to make, especially if they aren't used to needing to monitor such a situation carefully — they may actually expect you to "push back" on it and ask for guidance, especially if they haven't mentored many very-junior folks before and most of their previous mentees were already at a level where they felt comfortable saying "wait, how the heck am I supposed to do that?"

Nothing about this has to be confrontational, mind you — it is, or should be, absolutely expected that an intern should be asking for guidance on something where they don't understand how to accomplish what is being asked of them. If they're really that senior, it may be that they have knowledge of a pattern or "trick" that you aren't yet aware of that makes it more possible than it currently appears. Or it may be that they're trying to see if you are in fact capable of realizing when there is a problem (and, in my opinion, doing a poor job of approaching how to test that). Or possibly some other explanation.

But in every plausible explanation I can think of, even one ones where this is a "bad" company, your best "next move" is to talk to the person asking you to accomplish this about the approach they think you should be taking and what their expectations of the result are. If that doesn't produce anything helpful, your manager is the next stop, to ask for help in resolving the situation.

1

A well-constructed tool that does part of the wanted feature will be the best target for everyone, and what you should organize your work around.

Firstly, @Nelson is right that there's no point burning yourself out.

Secondly, you haven't been very precise with the technical task involved, and this probably isn't the site for more detail anyway. From your brief description, it sounds like you need to convert some information from JSON into another format, or use that information to then construct API calls to some other service. This sounds like it is a solvable technical integration problem, not a research challenge. ((Only you and your team there will know for sure, so let's skip debating this one.))

Thirdly, this is clearly a stretch for you at your current level of programming skill and knowledge of these technologies. That's fine. As many responders have said, you're an intern, and the expectation is not that you know everything. It also sounds like your approach is a bit frantic, not step-by-step.

Fourthly, in my experience, if a person is going to leave the organization, their part-done software work is highly likely to get abandoned. Bugfix fully done and checked in? Great. Experimental new tool that sort-of works if you shake it just right? Dead in a few weeks. It's likely this is a non-production tool, because they make good intern projects.

Given these four things, I suggest you change your approach. You are not going to solve this by grinding out the hours: that only works when it's a task you are already skilled in, but where you have a lot of it to do. Break the task into pieces and get running code working for each piece before trying to make it all work together. E.g., try loading the JSON and outputting a few key bits of information on a test screen. Have another task for calling the desired API with some hardcoded test data. You have four weeks left: that's still significant time. Break the coming week up into tasks you think you can achieve, and which progress towards the goal. Perhaps there is another JavaScript programmer you can pair with for a half an hour and solve some problems together. Be clear and honest about the progress made, where you are stuck, and where you could use some technical insight. Write tests. Keep notes on your progress.

Overall, spend the next four weeks digging diligently, and getting paid to learn how to work seriously on code. That will also be more impressive to an employer than running yourself ragged for a tool that barely hangs together.

0

One of the reasons for having interns is to experiment with 'impossible' projects. Or vanity projects: I was an 'executive perk' for my boss. Although you would like to work on useful or career-expanding projects, sometimes that is not your employers priority.

As Dilbert's evil HR manager Catbert said: "Enjoying your job is the same as stealing from your employer". That is an extremely cynical humorous take on the situation, but it contains a core of truth: you aren't employed to 'feel useful'. That's not a job function. Turning up and obeying instructions is a job function, and one that beginners sometimes struggle with.

1
  • On "impossible" intern projects: The airbag landing mechanism for the Mars Opportunity rover was designed by interns. The team at NASA just gave them the landing problem without telling them they hadn't solved it themselves yet.
    – Adam Burke
    Jul 15 at 8:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .