4

I'm coming to the end of a summer internship in which I've developed a functional and fairly fleshed out prototype of an IoT solution for a non-techy company with no software engineers employed at any point.

That is to say I've developed this entirely independently, and not too surprisingly a lot of corners have been cut and 'best practice' was often cut in favour of new features/speed of development due to the time constraints of my internship.

Aspects I'm concerned that have not been present include: code review, any real testing (although there is some), any real emphasis on security and in general the lack of overall support has made me concerned that what I've created while functional, is not remotely industry standard.

I've heard a lot of other students talk about how different working for a proper software company has been to the style of university assignments. And I can't help but worry that what I've achieved is pretty much just a glorified assignment (although I am proud of what I've made in a technical sense).

How do I best sell the work that I've done here? I have at the very least used version control and commented my code/made documentation but that's it. I'm concerned about the lack of any real code review and a future employer might consider my code too 'hacky'.

  • 2
    As a hiring manager I would not attach that much weight to an internship project. I would be more interested in your theoretical basis, your potential for growth, etc. – onnoweb Aug 13 at 15:21
  • 1
    Do you get to keep this code? Are you able to show the actual code to potential employers, or just discuss it. Separately - was this internship completely independent of the university, or was the university somehow involved in the process? – dan.m was user2321368 Aug 13 at 15:21
  • 1
    "I have at the very least used version control and commented my code/made documentation but that's it." - without a lot of supervision and advice that's great already and you can be proud of yourself. Being aware of the other points of a software-dev-lifecycle such as unit&integration tests, hallway-tests, security and alike (you might be interested in Joel Spolkey's Joel-Test) is putting you above the average junior already. I would summarize all of that in a presentation and use it in the next interview ;) – iLuvLogix Aug 13 at 16:35
  • Thanks for the advice, I do get to keep a copy of my code and access to the GitHub repository. I was advised to take a summer internship by a member of the university but it's not an official part of any programs at all. Would it be worth my time to look at a lot of areas that I'm lacking on to at least be able to talk about these concepts? It's also worth adding that part of the reason I was concerned about the quality of my code is due to having to learn entirely new technologies/frameworks that I had no experience with prior. – Harrison Fretwell Aug 14 at 7:01
  • @HarrisonFretwell, whoa, what code are you keeping a copy of? Are you talking about personal side projects, or the prototype you created for this company? That code isn't yours, it belongs to the company. You shouldn't have it unless they expressly gave you permission to keep it (most companies don't do that). – Seth R Aug 14 at 15:13
6

An internship is a learning opportunity. It helps you a) pick important skills that you can use in your early career b) have something to talk of during your initial interviews

Other students are right, they've experienced a different way of working than what is taught at the university, and so they've picked up "industry skills".

However, you too have picked up real world skills - becoming an independent, self-learning resource who can build a functional prototype on their own. This skill is not to be underestimated in the real world, and in fact, this self-drive is valued a lot by entrepreneurial organizations.

So, present your work with confidence, focus on your learnings, rather than the learnings that other students may have, and you should be good to move ahead.

As for industry standards and coding best practices, there is no dearth of them, so you will get tons of opportunity in your career to learn about things like code reviews, testing etc in future.

  • Thanks for the help, would it be okay to be upfront and honest in a future interview about my shortcomings? Saying that I don't have much experience in X but would be willing to learn? – Harrison Fretwell Aug 14 at 7:06
  • @HarrisonFretwell, don't overplay your shortcomings, but it is good to recognize the areas where you still need to grow. Don't just talk about your shortcomings, but what you are doing to improve them or overcome them to make yourself better. – Seth R Aug 14 at 14:29
2

Consider that it's hard to sell anything without having an audience to sell to. What kind of job do you want? What kind of employer do you want to work for? How you sell will depend as much on these factors as on the personal experience you're trying to sell.

So, before you go trying to write up the ideal resume, consider the following:

  • What sort of company do you want to work for? Do you want to work for an actual software vendor? Or do you want to work in an embedded software team (i.e. developers working at a bank, or whatever - a company where software isn't the primary deliverable).
  • What size and maturity of company do you want to work for? Do you want to work for a larger, or more stable, or more structured company? Or a younger, smaller, more dynamic and less-defined company?
  • What type of work do you want to do at that company? Do you actually want to just write software? Or have a more zoomed-out architecture role? Or something else specific?

As next steps, I would suggest:

  • Answer the above questions for yourself. Decide what your ideal next job is, and what your ideal career path is over the next x years.
  • Look at job postings and adds to get a feel for what's actually available. You're not specifically looking for your dream job so you can apply to it, first you need to do some recon and get a feel for the market.
  • Look at your competition. You're in school, so this is effectively your peer students.

To answer your actual question of how you sell this experience you have, reflect how your experience applies to the job postings you found, and on how your experience differentiates you from your peers. Then, work those findings into your job search:

  • Make sure you're applying to jobs you actually want, at companies you actually want to work for. If you're not sure, loop back through the above steps to refine your research.
  • In your resume, and in answers during interviews, focus on describing your experience from the perspective of that employer, in terms that show how it fits that specific opening.

In other words, there isn't a single right answer to your question, since it'll depend on the specific job and employer you're trying to "sell" yourself to. If you're applying to a small, unstructured startup that just needs to get things done, you might want to focus on how you were able to perform in an unstructured environment - you could do good work despite the lack of controls. However, if you're trying to get a job in a more stable and formal environment, you may want to focus on how this "fast and loose" project helped you reflect on the true value of structure, and how you've done what you can in the meantime to hone your skills - this might sound like you're admitting that you don't have direct experience in a structured environment, but a fresh grad who actually understands why and how structure can be helpful - because they've seen a sloppy unstructured environment first hand - can be very desirable.

1

Short answer: You don't sell what you have, but you show it.

As you mentioned, you developed a "Prototype" and "a lot of corners have been cut and 'best practice' was often cut in favor of new features/speed of development due to time constraints".

So, you would go demonstrate your prototype as-is and present it to potential buyers, and once someone likes it then you would make an agreement to build the "real deal" which implements all the "best practices" that you vision as a full package (final product).

1

Sometimes the skills surrounding the project are more imressive than the project itself. These could include the following

  • communication and presentation: You did a project for nontechnical people. So you had to talk to them about the project itself, its scope and features, technical details. Communication to nontechnical people or people with a different technical background is immensly important.

  • planing and estimation: you had to plan your project yourself, probably had to break it down into subtasks and estimate and probably change depending on the difference to your estimation. The better your estimations are and the more efficient you can do them, the more valuable you are for an employer.

  • independance: you did your project yourself since there was nobody arround who could have help you. This shows that you don't have to be supervised all the time to get things done.

All these can be spun to show you in a positive light even if your project isn't code-perfect.

1

So as an intern with little professional experience and very little practical guidance worked for a company to take a new application from concept to reality in only a few short month? That's amazing! Definitely an experience worth hyping when you start talking to other employers about hiring you.

So the code quality isn't what you wished it were. As you said yourself, that had to happen because your employer wanted new features and you had tight time constraints to deliver the solution. Don't talk about this as "cutting corners", you consciously made trade-offs in order to deliver the solution on time given the resources you had (it was just you). This is what engineers do, and being able to recognize those trade-offs and their consequences is an important skill. And it's a hard one to teach, so the fact you have already demonstrated it at your level is going to be valuable to employers.

When you go to "sell" yourself to other employers, talk about the problem you had to solve and what steps you took to solve it given the constraints you had - those being that you were the sole developer with limited experience and tight deadline. Talk about the trade-offs you had to make and why you made those decisions. Don't be overly concerned that you never went through a code review or real QA process; those things are a means to an end and incidental to the process (that is, we don't do code reviews just to do code reviews. We do them because it helps improve code quality when we work in an organization that values code quality). The story you want to tell is that you are someone who can work with what they are given and overcome challenges to deliver results. That's what employers look for and care about.

0

On your resume pitch this project as a prototype-- a proof-of-concept project. Emphasize that you got it working. Prototypes are definitely hard work, and definitely work worth doing. You finished a prototype during your internship. That's an accomplishment worth bragging about.

Did you or your internship-host company use your project or the prototype itself to answer any business questions? For example, "will this work?", "roughly what's the parts cost?", or "do potential customers like it?" If so, talk about how you answered those questions.

And, if your interviewer asks "what would you do differently if you could do it over?" then mention stuff like code reviews, and hardening up the security, and other things. That proves you have thought about the limitations of a prototype.

Don't sell yourself short. You did good stuff.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.