Wow! There will be a fight. There will be a true knock down drag out fight. But where is your opponent? You can’t see THEM! Them more than one. It’s you against them. You are going to the dreaded interview where you have to show the skills needed for the job, be strong, show confidence, answer questions, ask the right questions, and leave a great impression. Not hard. Right?
I’m laughing this morning. That last paragraph has made my day. Yes, sometimes I write something so strange that I laugh at myself. Not hard! NOT HARD? It would be easier to jump out of a plane – with a parachute of course. So you are a consultant, and it isn’t hard for you. NOT FAIR. You are the interviewee a lot. You interview more than a lot. So I hope for some great comments from you. This part is about interviewing for a full time job as the customer. It is not a client interview for a consultant. I hope that makes sense.
OK – it’s been awhile since my last interview – I won’t tell you how long. But I started working back at Perrigo in 2000. You do the math. Prior to 2000, I spent 9 long, horrible months as a consultant. Prior to that – I worked for PERRIGO! It was a bad move for me to leave for so many different reasons Yes, Perrigo had an opening for a developer! Perrigo is a Great company to work. Currently they have a lot of open positions. I had to add that part. Sorry – a little advertisement.
I’ll start with the interviewee side. So I am an interviewee, how do I beat – yes beat, stop out, obliterate the competition. Well – preparation, of course. So what do I do?
First the resume – I know that isn’t the interview so just a quick tip:
Look at the job description. At this point, I’ll assume you want the job and it sounds like fun. You have to have fun at your job. Look at your resume. Does it hit all or most of the things that the job description is looking for? Maybe you can change it to work with the language of the job description. An example:
My resume may look something like this:
I lead a project team of 5 people to integrate a third party software with SAP. We were on time and on budget. (You also did the integration hands-on. But it is not in your resume. After all a project lead sounds so much better.)
A piece of the job description:
Must have experience with PI integration.
So switch your resume. Did I do PI integration? Yes. The company could easily skip by the “project lead” because they would think that I didn’t do any of the work.
So I change my resume. It now reads:
I worked to integrate a third part software using PI. I was a responsible as the project lead for the work of 5 people. I had to understand what they were doing and assist with the PI / ABAP development in order to drive the project on-time and on-budget.
Ah Ha! That’s what the company is looking for. Some of my hands-on experience. One of my gloves goes on.
PRIOR to the interview – Review, review, and then review again:
I review everything on my resume. If I haven’t done that project in awhile, it’s going to be very hard for me to answer questions about it, unless I think about it prior to the interview. I may even dig out some old documentation. How did I do it, I think? What technologies did I use? Can I answer questions about the technology?
So my resume says I’m strong with the PP functional area. Can I answer basic PP questions? Yes, I’m interviewing as a developer. However, I have basic SAP knowledge. I look up some of the tables. I remind myself of AFKO, AFPO, RESB, CAUFV, S022.. Basically I look up all those tables that I should know if I’ve been developing with for PP. Why? I will be nervous at my interview. The more knowledge I can look up – the less likely I will say the dreaded word – Uhm… or sit there looking blankly at my interviewer.
Now I did say I knew PP. Do I really? Yes. Would I say it on a resume if I didn’t know it? No way. If they didn’t ask me questions about PP, and then they hired me and needed me to work independently on a PP project. I would really struggle at best; at worst I wouldn’t be able to do the job.
Back to review. So now I have PP tables swimming in my mind. Is that good enough? Well most people could answer that question. And so I would go to SPRO, CO03, COR2, look at BOMs and how they relate back to orders. COOIS is another great transaction. In short I’d try to review as much as I knew about PP. Just in case there is that interviewer whose main focus is PP. I’m a developer so do I need to know these things? No I sure don’t. But if it’s on my resume, I better be prepared to talk about it.
And so review I review what I know. I review what I’ve forgotten that I know. I make darn sure I can answer questions about your resume. I want to know each point in depth. Even the things I may have done a long time ago. I never know for sure what the interviewer saw that interested them in me. Another of my gloves go on.
So – most places when I am not local will start with a phone interview. The fight for the position has started. I am in round one.
Prior to the phone call – I drink coffee. I know, bad habit. I think about all the things I love about SAP. I learn a little about the company that I’m about to interview for. Then I pick out some of the things in the job description that I know I could do. I pick out some of the things that I would love to do. I pick out some of the things I would hate to do. So I’m ready to ask questions, I don’t want to move to a position that I don’t like. I’m ready.
If I prepared, it will be a breeze. The questions that are asked range from the very technical: What are the three parts of a BDC? To general your resume says you have written a Web Dynpro could you please elaborate? What kinds of tables are there in the PP area? When can you start? At that point I’m trying to answer easily. I am trying to talk in a normal speed. Not too fast, and not too slow. I am trying to answer honestly. I try to keep my answers short and concise. When I don’t know an answer I will say I don’t know. I will not fake an answer, or give a long round about answer. I will simply say that I don’t know. Then truthfully say, I am more than willing to learn. Usually I follow up with asking what the answer was to the question. Surprise! They were asking about something I knew. Just in a different way. Now I have the time to elaborate on what they said. I can say something like – That wasn’t what I was thinking you were looking for. I have written many programs that call another transaction. When I’ve written them I look for a BAPI first, then try to find a function module that is released, and then I would work on a call transaction. That would show the interviewer that I really did understand the area / answer. Sometimes, I simply don’t know anything about what they asked. I leave it at I would be more than willing to learn.
I made it! The in-person Interview:
I am in the final round of the fight. I have to really have some good hits to beat my competition.
I AM READY. I will stomp the unknown competition into the ground! They will be less desirable as an employee than I am. I am saying all this to myself as I look in the mirror. I have to be confident in who I am, and what I can do. I have to want this job. It has to look like fun to me. I have to have my game face on, and be enthusiastic. Enthusiasm – I love SAP – so trust me the enthusiasm part isn’t hard for me. The hard part for me is knowing when to shut up. That can be a problem. So I say to myself, I will answer to the point. I will elborate with my experience, but I will not stay on one topic too long. One example is enough, unless they ask for more.
I try to get to the office early. I want to get inside about 15 minutes early. So if I’m too early. I drive around, and get to know the area.
Then I do all the other things that I’ve read an interviewee should do. I talk politely to the receptionist. Easy, I try to do that to everyone. I try not to look nervous. My hand is wet because I’m nervous. I AM NERVOUS. I see my first interviewer walking towards me. I do the quick slide my hand down my side to get rid of that pesky wetness.
The interrogation, I mean interview starts. It is critical that my personality comes through at that interview. I want the real me to be there. Not the public me – OK so the public me is the real me – but you know what I mean. I want to be there, in that moment.
The grilling, the grueling, the tough, the impossible to answer all questions interview starts.
And now – I switch – I am the interviewer:
How do I prepare for the interview? I look at the resume. I look for the things I can ask about that make sense for the technical development job that I am one of the many interviewers for. And then… this should fill you with dread. I know that you will be interviewed for approximately the entire day here at Perrigo. I do feel sorry for you about that.
At Perrigo, it is a team interview. We have a list of technical questions. We change this list out every once in awhile, and we have never asked all the questions on it. Everyone on our teams asks different technical questions. I still throw in one or two of other questions. I think we all do. So we compare your resume with our predefined technical questions. Then we split the questions up. I may ask questions in the Web Dynpro, Objects, ALV… I may ask questions in a different area. My coworker Claudia may ask performance, basic reports, BDC/BAPI, Interface questions. If you don’t know an area, we cross it out, and only question you on what you do know according to your resume. I may not be one of your interviewers, there are many of us here.
I ask the predefined questions from the last step. I write down your answers. I try to stay positive about everything. If your answer is close, I ask you to elaborate. I write down your response. If you try to not answer by giving a long boring explanation or you answer wrong, I write that down. If you answer completely correctly – SAP has many correct answers – I check off the question. One or more of my co-workers are there, and we tag team. He / she will ask a question then I will. We try to keep it so you aren’t too uncomfortable, but it’s hard.
Here’s where I differ from my co-workers. I will ask questions about the experience you have on your resume. I may even ask about things that have nothing to do with this job. Why? I want to see how honest you are. I may ask some off the wall questions like “have you heard of SCN?”. “Ever been to a Teched?” – “what did you think?”. Or something about a newer technology, “What do you think the benefits are of using XYZ, what are the drawbacks of using it?”. But that’s only if we have time. I tend to run out of time, quickly before the next interview starts.
I always try to be friendly, and tell you what I can about Perrigo and our work environment. I want to make sure that if you are offered the job you know everything that you want to know beforehand.
Then – poor you – you go from interview to interview. By the end of the day, you feel like you’ve been put through a marathon of interviews.
Now what do I do? I take that sheet of predefined questions and look at your answers. There is a rating we give 1 – 10. Based upon your answer I give a rating. All the check marks are usually a 10. When I am done there is a percentage. AND then one of the most important parts, we have an open comment space. We write in our impressions of you. Arrogant? Rude? Willing to learn? Enthusiastic? That’s where we comment. So I now have a percentage to share and my impressions.
We get together as a team, and compare percentages, and comments. Once you are here, you are probably one out of a few that make it. (3 or 4) So we can compare and contrast the interviewees. We may decide no one fits, and start over again. We may decide the person with the lowest score has the best attitude and that’s the one that our HR will offer the job. Some of our comments may drive the job level that the person is offered.
Then the fight is out of my hands. The fight for the resource begins in HR. And I have no idea what they are doing.
And last the interview for the consultant / contractor:
We are looking for specific skills. I really could care less how many implementations you have done. Or upgrades, or whatever… I care about the project at hand, and the skills needed. I am working on an integration project using PI / Enterprise services. I don’t care how many BDC / Call transactions you’ve written. Hopefully, I have done my prescreening via the resume. The interview for the consultant /contractor is almost always via the phone. We don’t pay for them to fly in.
If I am looking for someone who is strong in Web Dynpro, I’ll ask the Web Dynpro questions. I don’t expect anyone to answer all the questions. Nor do I expect the same answers that I have. I will follow up to see if your solution would have worked. It may be possible that it is a better solution than the one I was thinking about.
I do ask general questions about your resume. These questions are just meant to see how honest you are.
Your interview will be short, quick, and to the point. I would expect the same from you short, quick, to the point. You may not know an answer. See above. I’d much rather you say you didn’t know than try to come up with something that sort of sounds right. That I hate. And from my point of view I would immediately cross you off the list. Of course there will be more than me on the phone call with you, and it will be a group decision.
So there are a million different articles out there; how to write your resume, how to interview, and how to prepare . Keep in mind that this is the opinion of one person – ME. Everyone else will have a slightly different opinion. As in all of SAP, it depends!