I’ve got some bad news for you bhamlin:

You aren’t an intern. Rather, you are an unpaid/cheap employee.

An internship is a unpaid or low-paid position where you can practice your newly aquired skills in a safe, (usually) relaxed environment, and get a chance to observe ‘real’ professionals in your field doing ‘real’ work, while getting feedback on the pieces that they allow you to modify (usually under supervision and/or approval).

What your company wanted, was not in fact, an intern, but rather a free/cheap source of software development. This is fairly common, in my opinion. I live in a college town, and at my last place of work, managers were often heard saying “Hey, the IT dept is too busy to do Project X, lets see if we can get some interns in from the University to write it for free/cheap!” We would grumble and groan and gnash our teeth to the heavens, but this was the reality of the place, and I could understand why the managers would suggest such a thing. Sadly, the results weren’t great: the software delivered by the interns was never cohesive/scaleable/clean/etc (but to be honest, neither was the stuff the IT dept put out anyway…)

Its up to you what you do. My advice is to just develop whatever you can (sometimes pressure is a great motivator), BUT you should also plan to taking on a ‘real’ internship elsewhere when this one is over if possible.

So don’t blame yourself, but what you walked into was NOT a real internship.

As a CS major you have problem solving skills at your disposal. It’s unclear what type of projects they want to develop. If I had to guess they probably want you to help automate some of the internal processes. I’d start by trying to get a big picture diagram of what processes are currently in place and the dependencies between departments for each of these processes.

Next, I’d look for some low hanging fruit that could be automated or at least streamlined.

Foolproof Way of Documenting Any Process

Ask these questions in the following order:

1. What is the output? (Get as specific an answer as possible)
2. What are the inputs?
3. Are there enough inputs to create the output?

If the answer to number 3 is NO, then go get the missing pieces. This could be formulas or business rules or whatever.

If the output from step one is too complicated then break it down into manageable chunks and attack each chunk as a separate process.

Document what you have discovered. Identify potential single point of failures. Identify weaknesses or scarce dependencies.

I know it sounds overwhelming but you have the skill set. Just turn it into bite size chunks. If you can learn how to explain “geek stuff” using “non-geek speak” then you will be worth your weight in gold.

Here’s my take on this whole situation: They are asking for more than you can reasonably accomplish, not giving you any feedback or guidance, and generally making your job not so pleasant. But there is a silver lining to this cloud You’re learning something.

Particularly, you’re learning the sort of environment you DON’T want to work in when you get your degree. You’re also learning how to deal with a project that is too large for you to feasibly accomplish. Both of these are important pieces of knowledge to hold on to, as no one is going to give you a job that they think is below your ability. They will always ask for more than what you can give, and it’s your job to work with them to manage expectations and deliver something that they want.

On to what you can do in the here and now. I would start by keeping a journal of everything that you do in each and every day. This gives you accountability. Even a simple end of day “this is what I worked on today” will give you something to fall back on when they don’t get what they want and come looking for answers.

I would also talk to your immediate superior and see if there is any way to break down one of these larger projects. If you don’t feel comfortable doing the whole thing, maybe they’ll just have you do research and the architecture for the project, and maybe have another intern later implement it. Just be clear what you think you can reasonably accomplish in the time you have left in the internship, and make that your goal. That way you are still delivering something relevant to your employer at the end of the day.

Finally, see if you can join the engineering interns. I’m going to assume that these interns are also developing software, and I see no reason why what you’re doing and what they’re doing are so far separated that you can’t learn from each other. I work with electrical engineers, software engineers, computer engineers and computer scientists alike on my projects, and each person brings their own strengths to the team. Identify where your strengths lie in development, and try to make a case for why those abilities would lend themselves well to the engineering team.

Talk to Your Internship Advisor

All of the answers I’ve seen so far seem to focus on the employer, which is important.

However, you must have been set up with this internship through a program or office at your school. I can’t imagine that you’d be the first student they’ve had that has run into this kind of situation. They should be able to guide you in a certain direction.

Even if they cannot help you now (which I find difficult to believe), then you will be helping the next student that finds him or herself in this situation, which is something that cannot be underestimated.

I had two internships like that, and enjoyed them immensely. There are significant bright sides that you seem to be missing:

• At this moment you are enjoying the kind of creative freedom that programmers working on large teams of programmers can only dream about. Everything from language choice, to source control, to editors, to software architecture is completely up to you. Trust me, you miss that when it’s gone.
• Working with people who don’t know much about software is a significant part of the software development process. School conditions you to expect well-defined assignments from people with a lot of experience teaching software development. Even in teams of programmers, your assignments are never that clear cut. Learning to deal with it now will give you an edge.
• Acquiring domain knowledge without the benefit of mentors is a significant part of the software development process. Once every year or two, I get an assignment like, “Become our subject matter expert on X technology.” Someone has to be the first one at a company to learn a new technology. You will get more interesting assignments if you can show that person can be you.
• From your point of view, it feels like a lot of pressure, but you should know that their expectations of you are really quite low. They know it’s more difficult for you without a proper mentor. Just do your best and you’ll be fine.

That being said, tackling your first large project can be overwhelming. The following may help:

• Try not to think about the whole project at once. Think about what you need to do right now.
• Get a list of features that need to be done, and get them to put it in priority order. That way if you don’t finish the entire app, the most important features will still be there.
• Break the first feature down into smaller and smaller tasks, until you get down to tasks you can finish in a day or two. Don’t be afraid to make them sound stupidly simple. My first task on brand new projects is always to get hello world working and checked into source control. Especially if it’s a new language, or one I haven’t used in a while, that tells me my build environment and tools are set up properly.
• Get your progress reviewed frequently. Don’t try to dump a finished product on them at the end of the summer. Show them at least once per week what you have so far.
• Spend some effort up front to try to find existing projects and components that can meet your needs. It’s much easier to customize an existing system than to do one from scratch. A lot of companies need similar kinds of internal apps. This is one I wish I had known about for myself. One of my internship projects basically reinvented (poorly) a CRM.

So, relax, do your best, and learn as much as you can, whether it’s about software or not.

The other answers here are very good, read them over and over and really try to figure them out. If you do that then, with a more than average effort, you’ll be able to emerge “alive” on the other side of your internship. Given your situation, it will be tougher than you expected, but it can be worth it.

This is crucial because, when you’ll apply for a position to another company¹, one of the key questions will be:

I see here you did an internship at the company X. How was it ? Why
did you leave ?

If you can then show them that you handled your difficult situation in a professional manner, this will count A LOT, employers are usually very impressed with something like this.

Even if it kind of sucks, you can make it a valueable experience from which you have the opportunity to learn what your classmates never will…

¹ = I hope you will, ’cause staying there will be a career suicide (sooner or later… probably sooner)

I was in a similar position last year, where I had to develop everything from ground up and had no one else with any development experience.
I did finish the project they gave me but I wouldn’t call it a polished application or even a maintainable one(since the only person that knows how it works is me and no one at the company has looked at the code.)

Here are some things I did and would do if I was in that situation. Some of these have already been mentioned in the previous answers

Figure out:

• What do they want the product to do (inputs and outputs, the bare minimum)
• What are your limitations? (i.e which programs can/cannot you use?)

This will give you a picture in your head about how the product should look. Draw this out on a piece of paper and show it to your manager/supervisor. See what they say about it. If they don’t like it ask them what they want changed, change it and repeat the process. If they like it, do the bare minimum amount of coding and create a simple demo.

Show the demo to them (ask them if this is what they have in mind), this will show them your progress and help you understand what they want.

Whenever you need coding help, read manuals/tutorials, google search and finally post on stack overflow for help.

Don’t get hung up on small details. You will waste a lot of time if you do this.

Code in small chunks, each chunk being a major functionality for the application.

Comment your code. If they are planning to pass this on to another intern or an employee it will be a huge help to them.

Keep communicating with your manager/supervisor about the project and your progress on it.

And don’t worry if you cant finish the project, you are an intern and you did the best you can. They are at fault for hiring someone who is under experienced for such a project.

TL;DR

• Communicate with your manager every step

• Code the major functionality

• Get help from Google and stack exchange

• Dont worry if you cant finish

1. Seek clarification on the internship’s goals – why were you assigned so many projects?
2. Clarify to management that within the allotted time, you cannot complete the requested projects
3. Prepare an analysis of how to best use your time. For example, suggest working solely on one project and dropping the others.

Your time would best help your company if you worked solely on one small project. Make sure to keep it well documented. Focus on creating useful documentation of architecture, project goals, project progress, and source code.