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

  • 5
    Keep this in mind. No one is an expert in their programming language, except maybe the people who created them. I'd be suspicious of anyone who walked into our organization claiming to be an expert ;) Practice the interview, and you'll do fine! Good luck.
    – jmort253
    Jul 29, 2012 at 8:59
  • 2
    Show enthusiasm. Demonstrate to the interviewer that you're interested in the job, that you really want to do it (and not just for the money). Ask questions about the project you're going to be working on. Jul 30, 2012 at 5:15
  • Can you expand a bit more on exactly what sorts of questions you're having trouble with? Are the problems related to terminology? To areas of the language you haven't needed in your day-to-day life? Algorithms? Something else? Jul 30, 2012 at 6:40
  • I can't really point out on specific questions - it could be of any subject, and every time I fail to answer a question I get the feeling I've failed in the interview
    – Shai
    Jul 30, 2012 at 7:23
  • @Shai: Team lead is such a broad concept. Will you be doing a lot of architecting, coding or managing? Some team leaders usually delegate and go to meetings, while some take care of difficult coding tasks. Do you know what kind of team leader are they looking for?
    – Spoike
    Jul 30, 2012 at 11:23

4 Answers 4


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.


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!

  • Thanks for the answer! The thing is that I think I have an approach problem with job interviews. I know I might not be able to answer some basic questions, but I do know that if I will be given (any) real-life assignment/project, I`m 100% positive I'd be able to complete it in a short time, regardless whether I master the target programming language or not. How do I convey this to the interviewers so they actually "believe" me?
    – Shai
    Jul 29, 2012 at 8:39
  • Telling is different than showing. With all due respect, you're going to need to jump through their hoops, and practicing and showing that you can pick up something you say you're not 100% familiar with in a short time, like C#, will go a long way towards making your case that you're their new employee. :) Remember, they get tons of applicants, and you'll need to work hard to get the position. Good luck! :)
    – jmort253
    Jul 29, 2012 at 8:49
  • 1
    @Shai: A lot of people tend to claim stuff in interviews. Every claim you do, make sure you have something to back it up with (by answering the HOW). Do you have any previous project/situation that you can talk about that supports a claim then do tell about it? There is a difference between saying "I know C#" and "I know C# because I worked in all these C# projects". Even more general ones such as "I'm a quick learner" can be improved with examples: "I'm a quick learner, I once took on a project and got up to speed with the team within a couple of days. How? Well I..."
    – Spoike
    Jul 30, 2012 at 9:25
  • @Shai: I tend to draw a mindmap to remind myself before the interview what I've done the past 10 years. There are a lot of small projects that you might've forgotten but will be key in backing up your answers. This practice actually helps me answer questions on things I'm currently weak at with examples where it the weakness is passable. "It is true that I don't have much experience in tech X, but I've done similar things with tech Y and Z. I'm sure there are differences between them all but I've found they're generally the same in principle."
    – Spoike
    Jul 30, 2012 at 9:33
  • edit: i put my comment in an answer
    – acolyte
    Jul 30, 2012 at 18:00

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.


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.


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:.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .