Internships at SmartEdge IT Solutions: What to Expect

We run a structured internship programme for students and recent graduates. It exists because the most useful way to learn software work is to do software work, and because we would rather meet people properly than read a CV.

Two things are worth saying at the outset. The work is real in the sense that it ends up in front of users rather than in a folder marked training, and the rhythm is that of a working team, with the same reviews and the same releases. At SmartEdge IT Solutions nobody is given a version of the process that is easier, because a simpler process would not teach anybody anything about the real one.

What the first two weeks actually look like

Day one is environment setup, and it takes longer than it should. Installing the toolchain, configuring access to the repository, reading the project documentation written by someone who no longer works here, and working out which test suite has to pass before anything is merged. Interns who expect to write code on day one find this tedious. Interns who know it is coming treat it as the most useful part of the fortnight, because it is the part that tells them how the project thinks.

Why the setup is not a formality

Nothing in that fortnight produces anything visible, and it is still the part people remember longest. Knowing why a test is failing, where the settings for a feature live, and which folder holds the migrations is the difference between somebody who can work and somebody who is asking where things are for a week. It is also the first place a real constraint shows up: the project has opinions about how code should be written, and those opinions are in the code rather than in a document.

What comes after it

Then the work starts, and the first task is usually chosen for two reasons: it has a clear definition of finished, and it touches something real, so there is a point at which it either works or does not. You will be told which of your paths are covered by a test and which are not, because writing the test for something you have just built is how you find out what you actually built. If a task looks larger than its description, the reason is usually that the person who wrote it knew something you do not, rather than that they expect you to guess. Ask.

What you will actually work on

The honest answer is that it varies, and it is decided per internship rather than advertised in advance. What can be said is about the shape of it, and the shape is fairly consistent.

Small, real, visible

Tasks are sized in days rather than months. A bug that reproduces only for some users. A screen that has to remain usable on a slow connection. A form that has to keep what somebody typed when a validation rule rejects it. A report that somebody currently assembles by hand once a month. None of these is glamorous, and together they make up most of what a product does after the launch period, which is why they are the work you are given.

On a real codebase

Not a sandbox built for the purpose. The constraint people find hardest is that the code you change is read by somebody else tomorrow, so your change has to fit what is already there rather than sitting beside it. That is a different discipline from a coursework project where the only reader is you and the grader only looks for the answer.

Boundaries we keep

If a task touches customer data you will be told, and it will not run against live data without somebody checking it first. That applies regardless of how much you have already demonstrated you can be trusted with. It is a property of the work rather than a judgement about you, and the same rule applies to everybody on the team.

How the review works

Everything an intern writes goes through the same review process as everyone else’s work, and the comments are written to explain rather than to correct. A review comment on a first pull request is read several times: once to understand what is being asked, once to make the change, and once to work out whether the reasoning still holds. That third pass is the part that teaches how a codebase is maintained, and it is the part people remember later.

What a reviewer is looking at

Not whether the code is clever. Whether it does what it was meant to do, whether somebody reading it in six months will understand why it is shaped that way, and whether the tests would notice if it broke. A reviewer is also checking that the person who wrote it understands it, which is why a question in a review comment is not an accusation.

Where you will be asked to change things

Naming, structure, error handling and tests, in that order of frequency. Expect the first round of comments to be mostly about the edges rather than the centre: what happens on an empty list, on a very long value, when the same request arrives twice. Those are the parts a new developer most often leaves out and the parts that cause real problems later, so they are where a reviewer spends attention.

Review is a process rather than a verdict on you. A comment that arrives quickly is a better sign than one arriving three days later as a single line, and a supervisor who sends you back for a second round is doing the job properly rather than signalling a problem.

The parts nobody puts on a poster

Reading an error message properly instead of guessing. Searching a codebase you did not write. Writing a test for a bug you already fixed, because you want to know it stays fixed. Answering a question in a channel rather than in someone’s head, where the next person can find it. None of this is glamorous and all of it is most of the job.

This is also the part that decides whether somebody enjoys software work. The visible version is a small fraction of it; the rest is reading, checking and waiting for a build to finish. People who find that fraction unbearable tend to struggle with the remainder, and people who settle into the remainder usually stop noticing it.

Who supervises you, and how often

Every intern at SmartEdge IT Solutions has one named supervisor, and it is a person rather than a queue. They are responsible for what you are working on, for reviewing what you produce, and for the conversations that decide what comes next.

How often you will talk

A short conversation most days, and a longer one at the end of each week. The daily conversation is not a status report in a formal sense; it is where a task gets re-scoped, a question gets asked, or somebody tells you that what you did yesterday solved a problem they had been thinking about for a fortnight. The weekly conversation looks at what you have learned as well as what you have shipped, and it is where a task gets redirected while there is still time for it to count.

Pairing, and working alone

Some of the time you will be working beside somebody, which is how you learn the parts of the job that are invisible from the code: how a decision gets taken, why something was built the way it was. Some of the time you will be left to solve a problem on your own, because that is the only way to find out whether you can.

If your supervisor is away, that is planned and named in advance and you will be told who to ask instead. If some part of the arrangement is not working, say so in the first fortnight rather than the last, while there is still something to change about it.

What we look for in an application

Evidence that you can finish something and explain it. A repository with two or three small projects you can talk about in detail is more useful than a list of technologies. If you have never finished anything, say so and show the thing you got furthest with, because how you describe being stuck is genuinely informative.

What an application cannot tell us

It cannot tell us whether you will be good at this, and an internship is too short to repair a bad first impression in either direction. What it can do is show evidence of one specific thing: that you can start something, and know what happened next. That is the whole bar.

The shape of a useful one

• A short note on what you have built and what went wrong with it. The second half is the interesting half.
• Something that exists, if you have it — a repository, a small site, an app on a store. A description of what you would build next is not a substitute.
• A sentence about what you want to learn. We read that more carefully than the list of technologies, because it says whether you are expecting to be shown things or to be left alone.

Typos are not disqualifying. A letter that could have been sent to forty companies is, because it says you did not think about this one. Details of what a specific internship involves are set out in the listing itself, such as the web development internship, and what the team is like day to day is written up under how we work.

How we assess, and what that decides

There is an assessment at the end of an internship, and it is worth being clear that it is not a test with a pass mark taken from somewhere. It is a conversation with whoever has been supervising you, and it covers the work itself.

What the conversation covers

What you built and how you went about it, what you would do differently if you did it again, and what you found hard. The last of those is the question people find most difficult and the one that tells us the most. There is no trick to it, and an honest account of something you did not manage is more useful than a confident description of something that went smoothly.

What the assessment does not decide

It does not decide whether you get an offer of employment, and we will say that at the start rather than leaving it ambiguous. Whether a longer-term role is possible is a separate conversation, separately decided, and it depends on what the team needs and on the other people applying. If it happens, you will be told clearly whether it is an offer and what it involves. If it does not, you will be told that too.

Duration, start date and anything to do with payment are agreed in writing before the internship begins, along with who to contact about it. None of that is left to be worked out afterwards, and you should be equally unwilling to begin anything on a verbal understanding.

What you should expect to take away

Working code you contributed to, feedback on how your work is written, and a clear view of whether professional software work is something you want to do. We would rather you conclude honestly that it is not a fit.

The most concrete thing you leave with is software that exists and that you can point at. Not a certificate: the proof is the repository, the merged change, the bug that no longer reproduces. Alongside that you should have a sense of proportion, because code review feels severe for a fortnight and then becomes the thing you rely on. And you should know whether you want this. Some people find they do; some find that what they wanted was the idea of building rather than the doing of it, which is an equally good outcome and an expensive thing to discover later.

How to apply

Send us your resume and, if you have written something, a link to it. Tell us what you are hoping to learn and what you have built before. Applications are reviewed by the team rather than filtered automatically, and you will hear back either way.

There is no keyword search on the CV and no scoring. Applications are read by people, and those people are the ones you would be working with, which is why the paragraph about what you want to learn gets read properly. If you are applying against a specific listing, send it there rather than to a general address, because it reaches the person supervising that work.

Current openings are on the careers page; anything not answered there can be asked through the contact form before you apply. If you apply and hear nothing back, mention it when you follow up rather than drawing a conclusion about yourself. We would rather hear from somebody twice than not at all.