How to Prove Your Skills During an Interview


Nowadays, employers are being more careful to make sure they know exactly what they’re getting – and getting exactly what they want. A lot of times, that happens when you’re in the home stretch. So let’s get into a few of the hurdles you may face late in the interview process, and look at how to handle them.

Dice TV

7 Responses to “How to Prove Your Skills During an Interview”

  1. Not only do companies want candidates who deeply understand the technology, they are seeking folks who will not need training in the business model itself. Hence, for example, the “healthcare industry” wants folks with healthcare experience, and so forth and so on. Lottsa luck.

  2. Here we have a classical HR person, Cat Miller, talking about technical issues without knowing how to make a program saying “Hello World”. Programming is not a standard as every programmer program his/her own way to reach the end results. By the way, Cat Miller says: “So let’s get into a few of the hurdles you may face late in the interview process, and look at how to handle them.” And says nothing about it…typical HR person!

  3. Let me add this as well; unless “you” write the very first program for the company, or you decide to re-write a program in an language the company does not use, you will NOT be writing from scratch. You will be modify an existing program with all the necessary that makes it function. Therefore, it’s better to show a working (more or less) program to the candidate and ask “what is this doing?’ and perhaps “what is wrong with it?” but that also assumes the candidate knows the business and such. For example I was once asked to debug a program. I looked at the code and said “It’s a card game but I don’t play cards, and there is no documentation, so I have no idea which game or the desired outcome.” The intent was explained and I immediately isolated and corrected the problem.

  4. Actually Cicuta, what she DID say is that “they want to verify that you really do have the credentials you have listed on your resume and they’re going to make you jump through some hoops to prove it during the interview. I want you to be prepared for that, so today, we’re discussing a few of those hurdles you might encounter in the later stages of the interview process.”

    She says she’s going to “discuss” some hurdles you’ll encounter, so that you’re PREPARED, and then she does. She never said that she was going to “look at how to handle them.” The hurdles she lists are having to prove yourself by taking written tests, undergoing thorough technical screenings, and being asked to demonstrate your skills on a whiteboard in the interview. She tells you what info she’s going to give you and then gives it to you. If you don’t have the skills to demonstrate than that’s your problem. hat do you have against Cat Miller? Maybe if you spent a little less time commenting on her videos and a little more time working on your reading comprehension skills, you might not be trolling job boards and actually have a job. They do videos cause they’re more fun and they give you advice on things you can do to help your job search. What’s so bad about that? Seriously, dude, if you don’t want her advice, don’t take it. But it helps me and it has helped my husband, who also looks for work on Dice, so why don’t you just lighten up some?

  5. (OK, got the video fixed, thanks to my son! 🙂 )
    the advice is good. Where I have a problem with the interviewers is that many of them seem to simply make you go to the whiteboard without really understanding what they’re asking.

    For example, they ask you to do a whole design on the fly, get all the pieces right, including the syntax and other things. However, that’s never how I worked as a developer. I’d build a piece, test it, build another piece, test it, add on some parts to connect the pieces, etc. Whiteboard writing does not lend itself to that, although it’s great for design work–but that’s that what they’re looking for.

    Even worse, these places that don’t really know what they want are also all too willing to offer lower pay for the privilege of showing that you’re an expert at doing things on a whiteboard that don’t reflect what you do on the conmputer.

  6. Cat’s advice is good, though not really a recent development. Every software company I’ve interviewed with, over the last 20 years, put me through an all day interview consisting of five or six 50 minute sessions. If you’re prepared it can be energizing to hit the next session knowing you just did well in the last one. If you didn’t do well, it can make for a very long, bad day for everyone. You may not think it, but (most) interviewers aren’t out to trip you up and don’t really want to coach a candidate through questions. [[ I did have one interview which was very odd. The interviewer would ask an open ended question and then stare blankly at me as I answered. I assume it was to either make me uncomfortable and/or to provide no feedback as to if my answers were what he wanted. Either way, this, or the confrontational interview (where the interviewer attacks your answers to see how you react) are pretty rare. I wouldn’t want to work at a company that used these tactics. ]]

    From a technical interviewing perspective, when I am on the employer side of the interview, anything on your resume is fair game to drill down on. You say you know C or Python? Be sure to qualify what skill level correctly because I, and most technical interviewers, will expect that level to be demonstrable on the white board. If you over state your skill level, you’re setting your self up for a poor impression.

    Regarding ROBS comment on being asked to go to the white board to solve something before the question is fully defined. To me the correct response is restate the requirements to see if it will help you understand it better and, if not ask more questions. As an interviewer, I could give incomplete specifications for something to see what you would do… just dive in without asking for more details or stop and ask. Where you go with this can reveal quite a bit about how you work.

    As far as designing a whole system (specs, api, etc) in an interview. As he asserts, it seems like an impractical question given the time constraints, but if I were asked, I’d just go with it (for me, starting might be a lot of questions about the requirements…). The interviewer has something he is looking for in my answer and while it may not be obvious to me, I need to proceed and see if what’s being looked for becomes evident. Not trying or explaining why you shouldn’t is very likely not what he is looking for.

    Often interviewers will look for a competency (stated or implied) and then follow up with questions that confirm the competency is there.