You're listening to Business English Pod, the Business English podcast for professionals on the move.
Hello, and welcome back to Business English Pod.
My name's Edwin and I'll be your host for today's lesson on succeeding in a technical interview in English.
While we have lots of lessons on job interviews in English, nearly all of them are about the first round of an interview or the initial screening interview.
If you succeed at that, you'll get called back for a second interview, and it's the English interview skills for these second round interviews we want to look at now.
Today we'll focus on the technical interview and in the next lesson we'll look at the behavioral interview.
Just like any interview, preparation for a technical interview is key, and you can think beforehand about how you might show things like innovative experience or a learning attitude.
You might also decide to highlight certain attributes that you think are beneficial, like being a team player.
But what about the problem-solving part of the technical job interview?
Can you actually prepare for every possible problem?
No, you can't.
But remember that the purpose is not to trick you or make you feel stupid.
The interviewers just want to see how you approach problems.
So it's important for you to start by clarifying the question and then clearly explaining your solution.
In today's dialogue we'll hear a software developer named Kevin who's doing a technical interview for a new job.
Kevin not only has to face questions about his experience, but he also has to explain a solution to a technical problem.
He's being interviewed by Mick.
We'll hear how Kevin navigates the interview.
As you listen to the dialogue, try to answer the following questions.
1.
What kind of experience does Kevin demonstrate when he talks about an exciting project he worked on?
2.
Besides having a happy client, why was the project so successful?
3.
When Mick gives Kevin a technical problem, what is the first thing Kevin does?
Alright Kevin.
Just going back to your time at Entek, you mentioned a few of the things you worked on.
What would you say was the most exciting project you worked on there?
Kind of hard to pick a favorite, but I think the most exciting project was an analytics suite we built for a finance client.
They wanted a way to analyze unstructured data, like tweets and blog posts and such.
Not a lot of precedence for that, so it really felt like we were doing some cutting-edge stuff.
And we did parts of it in Haskell, which I really enjoy working in.
And teaching, actually.
Turns out, not a lot of people had worked with it before, so I took it upon myself to run a few training sessions.
And how did everything turn out in the end?
Overall, it was a big success.
The client was happy and that's important, of course, but I also think it really brought us together as a team.
I mean, lots of learning together and working through some really tough challenges.
I think the whole experience was very positive.
Okay, then let's look at the other end of the spectrum.
I want you to think about a project you worked on that failed.
I mean one that really didn't work out as planned.
How do you think you could have improved that project?
If you had to do it again, what would you do differently?
Well, the project I'm thinking of was for a pretty tough client.
I mean the scope was constantly changing and I tried my best to adapt to change course, be flexible, but it was a real lesson in the importance of clear communication.
And if I had to do it again, I'd set up weekly status calls right from the get-go and then support that with some regular office visits.
Maybe some... Alright, let's move on to some problem solving.
If I can just ask you to come to the whiteboard.
I'm sure you've done this kind of thing before.
Yeah, all good.
Great.
So I'll just give you a problem, and you can walk us through your solution.
And take your time, no rush.
Okay, here we go.
Given two integers, write a function to sum the numbers without using any arithmetic operators.
Sum the numbers without arithmetic operators?
So just for clarity, that means no multiplication division, subtraction or addition, of course, but also, I assume, no power functions or logs.
Right, none of those.
All right then.
So I'm going to choose two integers.
And since we can't use basic math operators, we'll have to do this in binary and use bitwise operators.
So let me just write out those numbers in binary.
We can then XOR both numbers bit by bit, shift over the result for our carry bit and then iterate through from right to left.
Now let's go through the dialogue again and look at the language and techniques Kevin uses during his interview.
All right, Kevin.
Just going back to your time at Entek, you mentioned a few of the things you worked on.
What would you say was the most exciting project you worked on there?
Mick is giving Kevin a chance to talk about a favorite project.
This is a fairly common question in a technical interview and it's important that you answer effectively.
Even though it's about what you find exciting, it's also a chance to show some good experience, as Kevin demonstrates.
Uh, kind of hard to pick a favorite, but I think the most exciting project was an analytics suite we built for a finance client.
They wanted a way to analyze unstructured data, like tweets and blog posts and such.
Not a lot of precedence for that, so it really felt like we were doing some cutting-edge stuff.
Kevin is showing excitement about building an analytics suite, or software used for analyzing data, and not just any data.
He's talking about analyzing data that isn't usually analyzed, like the text in tweets and blogs.
In this way, Kevin is focusing on his work on a cutting-edge project, or one that is new and different from anything before.
This clearly demonstrates innovative experience.
It's great to show an interviewer what kind of thing you think is interesting, but it's even better to show how the work was innovative.
Let's run through some more ways of demonstrating innovative experience in an interview.
We decided to take a completely different approach to the project.
We were one of the first companies to use this technique.
I helped to transform the company's approach to scheduling.
Kevin uses the opportunity to talk about a couple of other aspects of his experience as well.
Let's listen, and we did parts of it in Haskell, which I really enjoy working in and teaching actually.
Turns out, not a lot of people had worked with it before, so I took it upon myself to run a few training sessions.
As you can hear, Kevin is not only demonstrating innovative experience, but also leadership ability and initiative.
Let's listen as Mick follows up with a question about the final result of the project.
And how did everything turn out in the end?
Overall, it was a big success.
The client was happy and that's important, of course, but I also think it really brought us together as a team.
I mean, lots of learning together and working through some really tough challenges.
I think the whole experience was very positive.
Kevin mentions that the client was happy, but he also talks about how the challenges of the project brought them together.
In other words, the challenges helped the team develop stronger relationships.
Of course, very few people work completely alone.
In most companies, work is done by teams.
And for this reason, it's very important to show that you are a team player or that you care about your team.
And this is especially important if you're applying for a leadership position.
How else can we show concern for a team during a technical interview?
Let's try a few more examples.
I realized that my teammates were getting tired and I had to do something.
Yes, it was interesting work, but it was also a great team with great people.
I wanted to make sure that my colleagues felt rewarded for all their hard work.
Sure, I got the award, but it was really a group effort.
Next, Mick wants to know about a different kind of experience.
Okay, then let's look at the other end of the spectrum.
I want you to think about a project you worked on that failed.
I mean one that really didn't work out as planned.
How do you think you could have improved that project?
If you had to do it again, what would you do differently?
Mick's question is a tough one.
Kevin has to talk about a failed project and then explain what he would do differently.
But once again, this is an opportunity to show a positive quality.
Let's hear how Kevin deals with this.
Well, the project I'm thinking of was for a pretty tough client.
I mean the scope was constantly changing and I tried my best to adapt to change course, be flexible, but it was a real lesson in the importance of clear communication.
And if I had to do it again, I'd set up weekly status calls right from the get-go and then support that with some regular office visits.
Kevin talks about a project where the scope or requirements changed a lot.
You'll notice that he talks about adapting and being flexible.
He also mentions that it was a real lesson.
Kevin's using the language of learning to explain the situation and he suggests some solutions to the communication problem that he identified.
Some people say the mistakes are just learning opportunities.
It's important that you can demonstrate that kind of attitude in a technical interview.
Companies want to know that the people they're hiring can adapt and learn new things.
Let's practice some more ways of demonstrating a learning attitude.
So I thought to myself, how can we learn from this experience?
Yes, there were problems, but those problems taught us how to work together.
I was glad to have so many experienced people to help me develop my skills.
It was a new situation for me, so I had to read up on how to deal with it.
Now let's skip ahead in the interview.
We're going to rejoin the conversation as Mick is giving Kevin a problem to solve on the whiteboard.
In other words, he wants Kevin to write out his solution on the board.
All right.
Let's move on to some problem solving.
If I can just ask you to come to the whiteboard.
I'm sure you've done this kind of thing before.
Yeah, all good.
Great.
So I'll just give you a problem, and you can walk us through your solution.
And take your time, no rush.
Okay, here we go.
Given two integers, write a function to sum the numbers without using any arithmetic operators.
Make once Kevin to walk him through a solution.
With problem-solving questions like this, your purpose is to explain your thinking clearly.
In Kevin's case, he's been asked to write some code to add numbers without using arithmetic operators such as plus or minus.
Let's hear how he begins.
Sum the numbers without arithmetic operators.
So just for clarity, that means no multiplication division, subtraction or addition, of course, but also, I assume, no power functions or logs.
Kevin doesn't jump into his solution too quickly.
Instead, he clarifies the question.
He wants to make sure he understands the constraints, or exactly what is meant by arithmetic operators.
If Kevin doesn't understand clearly, he might go down the wrong path in developing his solution.
You can start by asking one or several clarifying questions.
Even if you're clear on the question, it can buy you a bit of time to think about your solution.
How else can we clarify a technical aspect during an interview?
Let's go through some more examples.
Okay, so just to clarify, you want the solution in JavaScript?
Before I start, can I assume that the input will be in English?
So, just to confirm, the output will be a series of numbers?
Now, for starters, are you looking for the shortest solution to this?
Now let's get back to the dialogue.
Right, none of those.
Alright then.
So I'm going to choose two integers, and since we can't use basic math operators, we'll have to do this in binary and use bitwise operators.
So let me just write out those numbers in binary.
We can then XOR both numbers bit by bit, shift over the result for our carry bit and then iterate through from right to left.
Kevin doesn't just stand at the whiteboard and write out his solution.
Interviewers want to know how you think, and the only way they can find out is if you explain your solution step by step.
Not only should you state your choices, but you should explain your rationale or thinking.
So when Kevin says he's going to use binary, which is a number system of zeros and ones, he explains that this is because he can't use math operators.
I won't go into the technical meaning of Kevin's solution, but you should notice expressions like I'm going to and let me and we can then
These are expressions that tell the interviewer what you're doing step by step.
That will allow them to see how you are coming up with a solution.
Let's practice some more ways of explaining your solution during a technical interview.
All right, let me just write down the input at the top here.
Now what we need next is a way to sort those numbers.
Once that process is finished, then I'll need to create another list.
But now I see this doesn't work in all cases, so I'm just going to back up.
Kevin has done a great job throughout this technical interview.
He's used questions as opportunities to show his experience and attitude, and he's demonstrated clear thinking in his approach to the technical question.
Now let's practice some of the language we learned in today's lesson.
Imagine you are interviewing for a job as a software developer.
You'll hear a cue from the interviewer.
Then, I'll give you a suggestion for what you can say in response.
We'll guide you through each step in the practice and provide an example answer for each response.
Ready?
Let's give it a go.
So, tell me, what did you enjoy most about the project?
Start by saying that you were excited to find a new solution to an old problem.
Well, I found it very rewarding to find a new solution to an old problem.
Okay, and do you think you were recognized for your work?
Now say that you were recognized, but that you couldn't have done it without your team.
Yes, I was recognized but I really couldn't have done it without my team.
I see.
And on the subject of teams, what do you think makes a good team player?
Next, say that a good team player is someone who listens and learns from others.
I think a good team player is a person who listens and learns from others.
A little later in the interview, you are asked to solve a problem at the whiteboard.
Now I'd like you to write a function that returns all permutations of a given list.
Now clarify whether the given list is a list of numbers.
So, can I just clarify whether the given list is a list of numbers?
Yes, that's right.
This is a list of integers.
Start your solution by saying that you will begin by writing a list of five numbers.
Okay, i'm going to begin here by writing a list of five numbers.
Now let's practice some of the vocabulary we've covered in this lesson.
In a moment, you'll hear a series of sentences with a word replaced with a beep.
Repeat each sentence, including the missing word.
For example, if you hear Now let's talk about an experience at the other end of the, You can say Now, let's talk about an experience at the other end of the spectrum.
After each response, we'll provide the correct answer.
Let's begin.
It was frustrating to have to change... In the middle of the project...
Answer.
It was frustrating to have to change course in the middle of the project.
Could you write down this list on the... Answer.
Could you write down this list on the whiteboard?
It sounds like you did a lot of cutting work at Spotify.
Answer.
It sounds like you did a lot of cutting-edge work at Spotify.
Last month, I took it upon to organize the office.
Last month, I took it upon myself to organize the office.
We've reached the end of this lesson, the first in our series on second-round interviews.
We've learned how to demonstrate innovative experience, concern for a team, and a learning attitude.
We've also looked at how to ask clarifying questions about a problem and how to explain a solution clearly.
Thanks for listening, and see you again soon.
