How can I "sell" myself better during the job interview?

Question

I'm due to go on a job interview for a team leader (C#, Mobile applications) position in a few days

I learned pretty much everything I know by myself (at work, at home) - I do hold a B.Sc. in CS though.

So the thing is - I think I'm terrible in job interviews - they always get to ask me questions that I don't really know (like specific programming questions, sometimes even questions considered basic) the answers to.

I never went through a complete programming course in C#, so there are alot of subjects I'm probably not even familiar with, which (I assume) I will be asked on during the job interview.

I never considered myself as an expert in a specific programming language - for instance, in my current position (I've been working on the same company for almost 6 years), I mainly had projects in Delphi, C# and HTML5+JS and along that, I had to code a few things with PHP, PL/SQL, and Java.

Some of the projects I worked on were designed&mostly implemented by myself, and are now being sold to our clients (2 of them are large scale, in terms of endpoints), and I think they're a great success, management does too.

Is not having a specific programming language expertise a drawback? How do I sell myself better? How do I avoid presenting myself as a total newbie when sometimes 'not knowing' the answers to rather basic questions?

EDIT: Thank you all for your answers - they did help me alot during this interview as I had more confidence comparing to previous job interviews I had. Too bad the employer itself wasn't ready - the guy who was supposed to interview/test me wasn't even prepared (he didn't even hold a copy of my C.V.), I felt like they're not taking this too seriously, eventually I was told to go home and call them back to re-schedule for another day, so I told them to call me back when they're actually ready.

There're no "wrong" answers here - so +1 to everyone

Answer 1

Practice C# Interview Questions:

The key to getting through an interview successfully is preparation. First, do a quick Google search for common C# interview questions, and study them. Make sure you can remember and answer the questions. Keep practicing until you score well on practice tests and that you know your terminology.

Practice C# Coding Exercises:

Second, practice some C# interview coding exercises. While there's no guarantee that you'll be presented these same exact problems, what this will do is help get you into the mindset of breaking a problem down, coming up with a plan to solve it, and implementing the solution.

In the interview, the technical interviewers are judging you not just on what you know, but most importantly on how you approach problems. Even in cases where you cannot solve the problem completely, your attempt may still prove valuable. If you can't solve the problem with your first approach. Try again. Show them that you're not one to shy away from a challenging problem!

Remember the Soft Skills:

Third, don't forget about the soft interview questions. They'll also want to be sure that you're capable of working on a team and capable of playing nice with others. It's a good idea to study these types of interview questions as well, which will help give you confidence for the actual interview.

Summary:

In summary, keep in mind that employers also want to hire people who demonstrate maturity, and to admit you don't know something is a key indicator that you possess this humbling attribute.

If you say you're new to C# and are still learning, but then you ace the basic C# questions and solve most of their C# interviewing questions and blow them out of the water, you'll most likely leave a good impression on your interviewers. They'll feel better knowing that you won't waltz in their with big ideas and carelessly destroy the customer database tables or crash the live server. By admitting you aren't an expert, but then demonstrating competency, you'll show them that you're careful and attentive to details.

When I went through my interview, this was my experience, except instead of C# it was Java. I was no expert, but the preparation paid off. My test scores were great, I made it through all of the basic questions, and received an offer a few days after the interview. I hope your experience is the same. Good luck!

Answer 2

The higher the technical position you are going for, the better your answers to the technical questions should be. For a tech lead or team lead, I am expecting someone who can give guidance to junior programmers. That means I expect you to know basics and most of the advanced stuff as well. Know, not be able to look up. I would expect far better answers from a tech lead or senior devloper than from a someone going for an entry level or intermediate position. So if you don't think you can give those answers, you need to put the time in studying until you can.

That said, the technical questions are generally in two groups. Basic questions which are eliminators (You miss these and you are out of contention) and harder questions which are not. For the harder questions, we are often looking more for your thought process on how you would approach the problem rather than the exact syntax you would write.

Answer 3

You sound exactly like me. My advice, be confidant in your abilities and truthful in your flaws. I always say that I have trouble "talking tech" and remembering terms. Mention this early. Then talk about how that only affects you in interviews. Then laugh.

A big key, if they ask about a term you don't know, politely say "i'm not sure if I've done that, would you mind defining it?". Then the key is that once they've defined it, explain to them how you HAVE used that in your career.

Sometimes this won't work. Other times your confidence pushes through. Good employers know its not about what you know, its how well you learn and communicate.

Funny story, I did ASP classic for 3 years. In my first interview after that, I couldn't remember what the session was.

Answer 4

to specifically address programming type questions in interviews. Alot of people are able to talk their way through questions, field conversations, and generally keep things moving. What's much harder, tends to be the extremely simple practical exercises given to demonstrate competency. Here's my advice for you before you even get to an interview.

Make a program that solves fizz-buzz (or whatever they're calling it nowadays). Then keep refineing it. Play golf with it, while keeping it readable. Have a solution that uses recursion, and one that does not. But, don't memorize them. Memorizing them lets you solve fizz-buzz no problem, but won't help you with any other questions. It's more useful as a thinking tool, getting your mind to be able to code for stupid, arbitrary tasks. Once you have made your own solution, and have been working at it to improve it, you'll be able to approach any competency task given to you in a similar manner.

At an interview:

If you're given any type of 'write a program to do ..." questions, first ask for extra paper. Second, ask any clarifying questions you might need, and take notes. If you're not sure exactly what they expect you to deliver, or the format of the input/output, ask. It's more important that you ask questions and get all the information you need, rather than just charging ahead if you're unclear on something. It shows attention to detail, and a certain level of care that you put into your work. Unless under a massive time-crunch (say, less than 5 minutes for a language you're intimately familiar with, 10 minutes for one you know pretty well, or 20 minutes for a language where you only know basic syntax and form) take approximately half the time given to sketch out your program via pseudocode. Pseudocode is possibly the most useful programming tool in the world. Just like how you should make an outline/organized notes before writing a research paper, a good pseudocode skeleton organizes and focuses your task, and lets you visualize what you must do. After that's done and you've stepped through it in your head, start translating it into the language you're using. after that's done, you should still have some time to step through it with at least 2 sets of input (step through on paper with a step/state-chart). After you deliver the finished code, and they check it over, make sure to ask if you could have done better, and if you get an answer, take notes. Showing that you're trying to learn new things at all times, even during interviews, tends to be looked on very favorably.

after the interview:

Try to keep a copy of what you turned in, and look to revise it. Depending on how amicable the person interviewing you was, consider attaching an updated version, mentioning that you took some of their advice about how to improve it, and noticed a few other things that could have been done better, and that you're sending them the updated version. This shows that you paid attention to what they told you, (or at least, that you re-examine your work to constantly improve)

Wow. I can't believe that this all came out of a comment i was going to make to someone else's answer, :collapses:.