First Job Interview

The first thing we need to be clear about is that when we say "first job interview," we are referring to the interview that will give us our first job, whether or not it is technically our first interview.

We must keep in mind that the more interviews we do, the easier it becomes to handle the next ones. Also, this video is mainly aimed at developers, although it may be useful for other fields as well.

Here, we will discuss how to perform in-person interviews to win over the interviewer, mainly for graduate or perhaps junior positions with little or no experience, since interviews change a lot depending on your level.

Keep in mind that the first filter, your resume, has already been passed at this point. Of course, you should know your CV perfectly in case you're asked about something. If you don’t know how to create your own resume, here's a link where you can see a video to learn how to do it.

1 - Study the company and the position.

When you show up for an interview, keep in mind that the HR person, or even the technical people interviewing you, in some way "love" the company they work for, so you should show interest in it.

You demonstrate that interest if you've spent some time Googling the company and reading mainly what they do. For example, if a company sells oranges, mention that you saw they sell oranges, and that oranges are one of your favorite fruits.

As for the position, you need to show interest; you need to prove that you’re not just there for the pay. Money is important, but from experience, I can tell you it’s better to earn a little less and enjoy the company you work with.

They will ask you about technologies that you have on your resume and that they also use. You’ll know these technologies from the job offer, and if, in addition, you can Google the company or check them out on LinkedIn to see what else they work with, even better.

If they ask you any questions, they won't be especially technical at this stage; if you've seen a specific technology or methodology, maybe you can explain it a bit.

They'll use this to check that you haven't lied on your resume and that you aren’t just making things up.

You should use this moment to explain why they should hire you; use what they've just said as a springboard to talk a bit about yourself, your goals, and your ambitions regarding the job, whether those are related to the technologies or the company if you truly feel passionate about it.

- And that brings us to the second part

2 - The technical part.

In this part, they will ask you more technical questions, mainly related to the position you'll be filling, and here they will want more specific answers. But interviewees have one thing in their favor: most of the questions are repeated in all or almost all interviews.

Suppose the position is for a graduate in C#

Most likely, you'll first be asked about

• Inheritance, polymorphism, and encapsulation. If you don’t know what these are, there’s a link up here.
• They might also ask what SOLID is, which we’ll cover in a future course.
• Maybe something about general programming, such as if you know about O notation.
• Something about version controllers, etc.

At this stage, if you have a GitHub account, this is the time to mention it, as well as if you have a blog or any programming-related activities.

3 - A more relaxed chat

In my experience and that of all my acquaintances, interviews for these kinds of positions mainly stand out for the friendliness of the interviewer.

Remember that the interviewer understands this is your first job and you’re nervous. They'll focus a large part of the interview on asking questions to put you at ease: about your studies, how things are going in class, etc. Answer appropriately , no oversharing or getting too casual , but also, if you’ve stood out in any way, like winning a university prize, or if you watched a movie when you were five and that inspired you to study computer science, mention it.

Of course, they'll be interested in your life outside the office as well , do you do any sports, do you travel? For me, my first interview was outside Spain, so it was 5–7 programming questions followed by 35 minutes about why I left Spain and how things were going in Dublin, etc. If you play basketball semi-professionally, they'll ask the same: how are practices, teammates, etc. Pretty much everyone I know had the same experience with their first interviews: five minutes of technical questions and then lots of chatting.

It’s important for you to also show interest in life at the company and outside it. Mainly, this will help you relax.

4 - Dress and presentation.

A - Punctuality

Punctuality is key, not just in interviews, but in life. Don’t arrive too early or late , aim for five minutes before your scheduled interview time.

Still, we may get nervous and leave “with plenty of time.” If your interview is at 10 and you’re already there at 9, it’s better to go have a coffee , decaf or a herbal tea. And be careful not to spill anything on yourself.

B - The suit

Personally, I’m not a fan of suits , in fact, I work at a great company and attended my interview in a blue sweater. But let’s leave that for another time.

This is your first interview and you need to show what my grandmother would call “good manners.” So, you should wear a suit. It doesn’t have to be an expensive one; a €50 one from El Corte Inglés works perfectly well. What it should NOT be is the wrong size or old , make sure it fits well and is presentable.

C - Sit up straight

Remember you’re at an interview; try to keep your back against the chair at all times. All the body language gurus say it inspires confidence. Slouching creates a bad impression, so sit up straight and that’s it.

D - Use gestures

When you speak, move your hands like a late-night presenter , it will add emphasis to what you’re saying.

Of course, when you’re listening, stop moving your hands and pay attention. That means listening, which is also shown by nodding your head.

5 - Final question

At the end, they will always ask if you have any more questions. If the topic hasn’t come up during the interview, ask about their development process, from when a problem arises in the system to when it’s released to production.

This question will show you how much they care about technical aspects, and probably, how much you’ll learn there.

From my experience, there are a few typical answers, grouped more or less as follows:

A - The one with no system

These companies stand out because they don’t even have a task system like Jira or GitHub tasks. Instead, they use email or even paper. This means that when something breaks, you get an email to fix it immediately.

If you’re lucky, they’ll have a version controller, but don’t expect code reviews or tests. And if something has to be deployed, it’s straight to production since there’s no test server. Most likely, there are no tests in the code either.

The code is probably a mess , they prioritize urgent fixes and patch things up, which makes the code unreadable.

You won’t learn anything here , well, maybe you’ll learn bad habits you’ll have to unlearn later, frustrated and bitter, because almost everything technical is done badly.

B - The one that doesn’t quite make it

This is the “wants-to-but-can’t” company , they’d like to stay up-to-date but for various reasons can’t keep up with everything.

They usually have a task management system and version control, though version control is used mostly as a backup in case something breaks after a release.

You’re likely to have a test server as well as production. Also, it’s likely that the main parts of the program are tested in the code, but maybe not everything , still, that’s better than nothing.

Forget about continuous integration, but deployment might be better , maybe it’s done by running a command, but they’re afraid to automate the process.

In these companies, you can learn; they’re usually open to changes and improvements, especially if you can make a strong case to your boss. As a starting point, it’s not bad.

C - High tech

Finally, we come to the companies that do everything by the book.

When there’s a problem, a user story is created. Different parts of the company analyze the impact and assign a priority.

Based on this priority, a task is created in the task manager (Jira), which is linked to a branch created specifically for that task.

We’ll have to write tests for the functionality, both for the "works as expected" and "should fail" cases. Finally, a colleague will review the code, and if something doesn’t fit or look right, they’ll ask us to change it.

Once that colleague approves it, we’re done. We merge to the main branch through a service like GitHub or Bitbucket and forget about it.

Continuous integration (CI) will run the tests and if everything passes, the continuous deployment (CD) system will deploy our app to the designated server so that testers , if it’s not automated , can manually check the change.

This is the ideal company, usually up to date with the latest technology. Working for one can make your professional life much easier in the future, since being surrounded by talented people means you’ll learn much more.