hey,
In monday i'm going for a interview to a technology job, any advice on how to pass it and how to prepare?
In monday i'm going for a interview to a technology job, any advice on how to pass it and how to prepare?
Best of luck on that interview. If you could say what the technology job is, people might give you better suggestions.
Edited by Abner Coimbre
on
it's for the software team at intel, specifically for the x64 llvm backend, but maybe for other teams too.
I don't think I have any advice (I've never interviewed at Intel), but just wanted to wish you good luck!!
- Casey
- Casey
Thanks, it means a lot to me.
I interviewed at Intel in Portland this year. There were two phone screens and one day at a campus in Portland which consisted of 7 interviews with lunch in between.
I don't know if I was lucky or if Intel has does thing differently from most companies that I have interviewed at, but there was no whiteboard coding or puzzles of any kind.
EDIT: I did write some code in the whiteboard. Someone asked me how I would know the size of a struct without sizeof. I don't consider that a puzzle, more like checking my knowledge of C
The phone screens were all about talking about my interests and previous projects. I wish I remembered more of it. I had two phone calls, each with a different person that worked on Xeon Phi firmware at Intel. I think they were just checking for obvious red flags and "culture fit". The onsite interviews were mostly behavioral questions and questions about my projects. They digged down to see why I ended up solving things the way I did
They asked me a lot of behavioral questions. You should definitely come up with some stories that you can use. Write them down and stick to a structure.
1- Set up - Describe the setting and the problem. I find that if I don't prepare a story I will spend most of the time on this. It should not be too long.
Something like "I was working on backend stuff at a previous company. I changed one line of a 2000-line front-end javascript file full of horrible hacks. The problem came during code review. The reviewer decided that I needed to fix the whole thing, and I had almost zero knowledge of javascript."
2- Describe how you solved the problem. "After about 5 days of code review, I decided to email the guy. I spoke with a coworker and we asked the reviewer to give us a couple of 1-hour lessons in javascript."
3- Describe the results. "It was clear that the guy *really* liked javascript, which was generally looked down upon at that company. He appreciated that we wanted to learn from him and ended up refactoring the file himself."
Something like that... You can get by with 2 or 3 stories, but they must cover the basic topics they might ask you
Most people, myself included, downplay their role in step 2. Don't say "we fixed the problem", say "I fixed the problem". They want to hear what *you* did.
I think you will be surprised how easy it is to spend too much time describing the problem and too little time describing the solution. This is why it's good to write these stories down. Memorize them. Remember the scene from reservoir dogs when the undercover cop is practicing his story? It's kind of like that.
I'm not saying that you should lie though, it's important to be honest, but interviewing is very unnatural. It is super helpful to have something simple and easy to follow when you are in the middle of it. Like following bubbles to know which way is up after a big wave tumbles you
Some broad categories:
- Conflict resolution / team player. Tell them why you're great to work with
- Problem solving - Convince them that you are smart and focused. Tell them about your software rasterizer or your debugger ;)
- Leadership (i hate that word, but this does come up). Tell them about a time when you assumed a position in which other people had to follow your lead.
A good story hits more than one category
You are probably going to interview people who would work with you. Hiring is scary for them too. It's OK if you are nervous, but it is important to leave them feeling that you're good to work with.
Finally, the biggest thing is to convince yourself before you convince them. I have messed up interviews because I psyched myself out. You can be your own worst enemy in these situations. Spend the 48 hours before the interview telling yourself how great you are. Be mindful of the little voice that tries to tell you "you suck." Don't be afraid to make yourself look good!
Good luck!!!
I don't know if I was lucky or if Intel has does thing differently from most companies that I have interviewed at, but there was no whiteboard coding or puzzles of any kind.
EDIT: I did write some code in the whiteboard. Someone asked me how I would know the size of a struct without sizeof. I don't consider that a puzzle, more like checking my knowledge of C
The phone screens were all about talking about my interests and previous projects. I wish I remembered more of it. I had two phone calls, each with a different person that worked on Xeon Phi firmware at Intel. I think they were just checking for obvious red flags and "culture fit". The onsite interviews were mostly behavioral questions and questions about my projects. They digged down to see why I ended up solving things the way I did
They asked me a lot of behavioral questions. You should definitely come up with some stories that you can use. Write them down and stick to a structure.
1- Set up - Describe the setting and the problem. I find that if I don't prepare a story I will spend most of the time on this. It should not be too long.
Something like "I was working on backend stuff at a previous company. I changed one line of a 2000-line front-end javascript file full of horrible hacks. The problem came during code review. The reviewer decided that I needed to fix the whole thing, and I had almost zero knowledge of javascript."
2- Describe how you solved the problem. "After about 5 days of code review, I decided to email the guy. I spoke with a coworker and we asked the reviewer to give us a couple of 1-hour lessons in javascript."
3- Describe the results. "It was clear that the guy *really* liked javascript, which was generally looked down upon at that company. He appreciated that we wanted to learn from him and ended up refactoring the file himself."
Something like that... You can get by with 2 or 3 stories, but they must cover the basic topics they might ask you
Most people, myself included, downplay their role in step 2. Don't say "we fixed the problem", say "I fixed the problem". They want to hear what *you* did.
I think you will be surprised how easy it is to spend too much time describing the problem and too little time describing the solution. This is why it's good to write these stories down. Memorize them. Remember the scene from reservoir dogs when the undercover cop is practicing his story? It's kind of like that.
I'm not saying that you should lie though, it's important to be honest, but interviewing is very unnatural. It is super helpful to have something simple and easy to follow when you are in the middle of it. Like following bubbles to know which way is up after a big wave tumbles you
Some broad categories:
- Conflict resolution / team player. Tell them why you're great to work with
- Problem solving - Convince them that you are smart and focused. Tell them about your software rasterizer or your debugger ;)
- Leadership (i hate that word, but this does come up). Tell them about a time when you assumed a position in which other people had to follow your lead.
A good story hits more than one category
You are probably going to interview people who would work with you. Hiring is scary for them too. It's OK if you are nervous, but it is important to leave them feeling that you're good to work with.
Finally, the biggest thing is to convince yourself before you convince them. I have messed up interviews because I psyched myself out. You can be your own worst enemy in these situations. Spend the 48 hours before the interview telling yourself how great you are. Be mindful of the little voice that tries to tell you "you suck." Don't be afraid to make yourself look good!
Good luck!!!
Edited by Sergio González
on
hey, i wanted to let you all know that i got the job. and although Serge's recollections were very thorough and i believe really did reflect on what he encountered, mine had 2 whiteboard questions which were riddley, and i did very bad on those.
regardless, they called me two weeks later to tell me i got the job, and i went there today(it's a work day in israel) to hear the job details, which were close to what i wanted.
regardless, they called me two weeks later to tell me i got the job, and i went there today(it's a work day in israel) to hear the job details, which were close to what i wanted.
Congratulations! That's really good news.
e1211
hey, i wanted to let you all know that i got the job. and although Serge's recollections were very thorough and i believe really did reflect on what he encountered, mine had 2 whiteboard questions which were riddley, and i did very bad on those.
regardless, they called me two weeks later to tell me i got the job, and i went there today(it's a work day in israel) to hear the job details, which were close to what i wanted.
Congrats, now go make SIMD autovectorization happen more and better =)
MandleBro
Excuse the interruption, but how DO you know the size of a struct without sizeof?
You can get the size creating an array of the struct, and subtracting the pointer positions of two adjacent elements.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | #include <stdio.h> typedef struct foo { int x; int y; void *handle; } foo; main() { int From, To, SizeOfFoo; foo Foo[2] = {0}; From = (intptr_t)(&Foo[1].x); To = (intptr_t)(&Foo[0].x); SizeOfFoo = From - To; printf("Size of Foo: %d\n", SizeOfFoo); } /* sizeof(x) = 4 sizeof(y) = 4 sizeof(handle) = 8 Calc Size = 16 Actual Size = 16 */ |
The reason this works is due to specification of C, where it states that an array is a contiguously allocated set of objects. I would link you to the standard...but apparently it's not free? And the ones I did find online I'm not quite sure if any modifications were done. Plus, you would need to know the version of C or C++ that you are using.
The thing is, if it was not guaranteed, then a lot of pointer arithmetic would not be possible...
The other reason it works is that the first element of a struct is positioned at the location of the struct. In C at least, there is no extra metadata that a struct contains.
1 2 3 4 5 6 | | Name | Value | |-----------|--------------------| | &Foo[0] | 0x00000000002dfe80 | |-----------|--------------------| | &Foo[0].x | 0x00000000002dfe80 | |-----------|--------------------| |
However, it should be noted that if the compiler puts in padding due to align the members better, it will also include that size (pointer alignment is mentioned in Casey's intro to C stream, I believe).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | #include <stdio.h> typedef struct bar { int x; int y; void *handle; char filler[12]; } bar; main() { int From, To, SizeOfBar; bar Bar[2] = {0}; From = (intptr_t)(&Bar[1].x); To = (intptr_t)(&Bar[0].x); SizeOfBar = From - To; printf("Size of Bar: %d\n", SizeOfBar); } /* sizeof(x) = 4 sizeof(y) = 4 sizeof(handle) = 8 sizeof(filler) = 12 Calc Size = 28 Actual Size = 32 */ |
Edited by Brian
on
Reason: Though msdev is fine casting to int, gcc throws a warning
Or you don't create any struct variables/arrays at all:
1 | size_t sizeOfFoo = ((char*)((foo*)0 + 1) - (char*)(foo*)0); |
Edited by Mārtiņš Možeiko
on