So I have a couple of software/site in my portfolio. They make money but not a whole lot.

So I decided to get some job experience, mainly applying to Java/PHP junior development positions.

The problem is that I answer all the technical questions correctly and we schedule to do a coding "test", the final phase of the interview. I can never relax and over think things and end up doing the test very slowly. OR sometimes I just hit a block and find it very difficult to think on my feet.

I don't understand this because other stuff I had written were solving far more complex problems while the "Test" is actually brutally simple such as writing and testing palindrome.

Other times, they will give me a logic test with flows to math operations and again I won't be able to do it in the time they assign.

I know I can write sellable software/websites that can generate small revenues and find ways to solve problems but I have great difficulty with simple coding tests in interviews.

Any suggestions?

  • 3
  • Apparently at least you think the interview tests might be simple, but it seems you are not alone in having trouble with thos tests: infoworld.com/d/application-development/… Nov 4, 2011 at 8:17
  • 2
    I have to disagree with this link. Given the differenc ebetween a good dev and a bad one, you really want to risk looding some good candidates than getting bads ones.
    – deadalnix
    Nov 4, 2011 at 10:27
  • 7
    @deadalnix I disagree with your disagreement. :-) I've seen enough good programmers flunk tests and bad programmers pass tests that I think testing is not useful and often counterproductive. IMO, all they do is make the interviewer/HR feel good. Nov 4, 2011 at 12:35
  • 2
    @BJoachim and all: if you read past the first paragraphs in that link, it's actually good advice on keeping the tests relevant and useful: it does not say tests are useless.
    – MarkJ
    Nov 4, 2011 at 17:10

12 Answers 12


Keep attending interviews. You'll eventually find a place that will ask questions more amenable to your strengths. You'll also get better and more comfortable with interviewing, which can only help. Look at it as a game, because that's really what it is. Keep playing, and eventually you'll win.

  • 2
    I don't think it's the matter of merit/content of the questions, just conditions of answers. I messed badly writing bool isPalindrome(string) because I was to write it on paper, in a time limit (of 15 minutes?). Given a text editor and no time limit I believe I could do it perfectly under a minute.
    – SF.
    Nov 4, 2011 at 9:38
  • 9
    @SF: did you try it after the interview? How long did it take you? Nov 4, 2011 at 13:22
  • 2
    Also keep practicing working on your weaknesses. In this case, find small, similar problems and time yourself working through them on paper. Practice getting something working first (even if it is wrong) then iterate through getting it right. That way you can show your thinking process as part of the interview. It seems this is the biggest skill you lack (right now) get a minimal deliverable out now, then improve it over time. Many businesses like this :-)
    – Al Biglan
    Nov 4, 2011 at 15:23
  • Just saw this linked from slashdot; somewhat related: infoworld.com/d/application-development/…
    – Kevin Hsu
    Nov 4, 2011 at 15:29
  • If the problem is that you can't program on paper, then that is a real problem in my opinion. "isPalindrome" should not need any obscure API calls or language features; you should be able to make a compilable program like that with no intellisense or IDE benefits. Nov 4, 2011 at 17:17

This is very common. Most programmers are able to program effectively when they are in their comfort zone. For example I can only on work on Ubuntu, with vim, if I don't have that workspace I won't feel like programming. I also require, to some extent Google for research.

I am sure you have develop some comfort zone for programming. I would recommend, getting used to the environment where some one is behind you waiting for their code to be completed. Best way to get used to it is to continue going to interview.

You might think it does not have much impact, and it might not. But for some of us out there, programming with music or without, using an IDE or a simple text editor, using a wood chair or sitting on a sofa, a dark room or a bright room... make a huge difference in our development speed.

Note, once you get the job, you can usually create your own comfort zone in the office space they give you.

EDIT: This question reminds me to a sales person, asking how to get comfortable and better at cold calling. The best answer is to keep doing cold calling, and reflect on each call. After a while sales man improve their skills and their comfort. I think programmer are no different when attending interviews, after all the main point is to sell yourself to the interviewer

  • Who is Sopha? Sophie's beautiful twin?
    – uɐɪ
    Nov 4, 2011 at 8:23
  • @Rick: unfortunately, as an interviewer, I can't just take someone's word that they are an effective programmer. I need to see that they can actually program. Neither reported experience, or GPA, or certifications, or code samples can tell me that. I need to see candidates do some programming. Nov 4, 2011 at 13:27
  • @kevincline I agree, that is why I recommend him to keep going to interviews and getting comfortable with interviewers such as yourself. Nov 4, 2011 at 19:17

This is just my suggestion, why not try being an entrepreneur. There might be many people who face the similar problem. If you can write websites for small revenue then surely you can earn big from it.

  • 1
    +1, and an entrepreunarial spirit can be seen as a very positive quality.
    – maple_shaft
    Nov 4, 2011 at 10:50

You have already identified what is your problem - solving problems under pressure (e.i. when somebody is watching you). Is it because you lack confidence or you don't have enough experience or you crack under pressure?

Going to a lot of interviews to get some experience and practice can be a good idea but also can produce counter-effects. Constant failures in interviews can shake your confidence even more, so be careful.

I would suggest you to try peer programming so you can get comfortable to solve problems when somebody is watching you. Also, try to figure out what's stopping you from being effective under pressure (is it stress from the actual testing itself, stress from working under close supervision, stress from working under a specific time limit etc.).

  • 1
    You should also google up some of these types of test questions. Print them out the way you get them in an interview and solve them. Sit at a table not your computer. You need to try and recreate the pressure of the interview. Nov 4, 2011 at 16:45

It sounds like you choke under pressure. Since you have to do the timed examples as part of the interview process, you'll have to learn how to get past this. This is all about managing fear, not about programming skill.

One option would be to practice writing sample problems and time your self. Once you know that you can do them in under ten minutes, you may fear being timed less.

Another option would be to come up with a technique to calm your fear, and use it to un-choke yourself. Learning a meditation technique might help you. Or memorize the litany against fear (from Dune.) Learn some kind of trick to take down your fear response.


I'm quite surprised that nobody has asked this yet, but how are you approaching the programming tasks?

If you're simply jumping into code, then chances are you're going to get yourself lost and end up making simple mistakes and getting yourself flustered. Take it one step at a time:

  1. Gather requirements: What is it, exactly, that your interviewer is asking. Make sure that there are zero questions up in the air prior to coding. For example, if confronted with the age old "isPalindrome" question, ask things like "what if the string has special characters?" or "do odd length strings such as 'ada' count as palindromes?". You need to know how to clarify requirements before designing an algorithm.
  2. Design your algorithm: Break it up into logical sections if it makes sense to. Talk about it.. Maybe write some pseudocode if you're whiteboarding. Walk your interviewer through your steps. Try running through it with a few different inputs (both valid and invalid) to ensure you get the desired results.
  3. Now start coding: By this point, you should be very confident in what you're about to write. Essentially, you should just be going through the motions with whatever language you're familiar with. At this point, it doesn't really matter if there are syntactical errors as interviewers worth a dime will forgive those in a whiteboarding session (if you're given a PC/IDE to solve the problem on, that's a different story).

Really, when tackling coding problems, an interviewer isn't looking so much for great code.. It's more to see how you go about tackling a given problem. Diving straight into code is a bad thing, period.

You'll also find that as you're talking about the problem (requirements gathering and design), you'll get a little more comfortable and are less likely to make silly mistakes during the coding portion.


Project Euler

It seems to me that you're failing the fizzbuz test. Mind numbing simple algorithms that don't generally serve any practical purpose except to identify if you understand the core concepts of programming.

Brush up on your basics

What I would recommend is that you brush up on your basics.


Sign up and start practicing, you'll find that by going through those examples you'll get a deeper understanding of the core programming concepts. I think you'll find a palindrome question in there along with fibonacci sequences and other mathematical concepts (sound familiar).


Ask for feedback at or after the interview. What did they like? What did they not like? You might be surprised at the answers.

Different people look for different things, of course, but how you go about trying to solve a problem is usually more important than writing a 100% correct solution. You may be worrying about all the wrong things.

The best way to get better at anything is to practice. Try writing down a list of short problems. Then, for each item on the list, write a small program that solve the problem. Start with very easy problems, like FizzBuzz, and ratchet up the difficulty as you go. Can you solve the problems that you've seen in previous interviews? Find the largest substring that two strings have in common? Calculate the prime factorization of n!?

The idea isn't to learn the solution to every problem you might encounter, but to give yourself some practice writing small programs quickly, and also to figure out where your weak spots are so that you can improve. Many problems are easy to solve with the right data structure, but difficult otherwise, so make sure you've got a solid foundation in data structures.


Practice and find someone to help guide you through the basics of how to get through it. It may take a handful of tries but it could be surprising what gets uncovered if you can get some feedback and practice on this. I had a recruiter walk me through how to handle a whiteboard problem once which appears to be similar to your issue here.

I'm not suggesting memorizing answers as much as it is having a blueprint of what to do when given such a problem and how to talk it through. What does this look like? Have you seen similar problems? What could some simple approaches yield in terms of an algorithm? At least that is my suggestion to you.


It is quite common for software developers to flunk when asked to sit a coding test or to write a small piece of code on the interview. As someone has already mentioned, that is because most of us can only code when we are in our "comfort zone" and sitting in a small room, surrounded by 2-5 interviewers does not really add much of the comfort.

The answer is threefold:

  • practice, and practice more. try for a month do 30-40 minutes of programming with a paper and pen and you'll be surprised how easy it would become. While practising - try the sort of the programming tasks what you expect to be asked for on interview coding sessions - e.g. implement a singleton, reverse a string, etc. It is even easier with "read that piece of junk code and find what is wrong" - try printing and them analysing these printouts for a two weeks and you'll greatly improve that skill.

  • learn how to control your fear. if you think that the test is too hard and you can only complete 20% of it - do that 20%, don't worry about the rest. It could be that the test is unreasonably big for the time given to do it (e.g. guys on interview supposed to give you 20 minutes to finish it but they need to wrap up the interview in 5 minutes because of some production blow up, etc). It is also possible that other candidates have only managed to completed 10% test, so by having completed 20% you will still be ahead of other candidates.

  • When writing a code on interview - don't bother making it perfect in a first pass. just implement a "happy path aka most common scenario first" and bother with error handling later. if you are runnning out of time - just add a quick note on the bottom of the sheet outlining - what you would have done to improve the code if you had more time.

[gotta run, will edit/improve my answer later]


As many people have already said I practice is one of the most important things. If you have already done a similar problem you will be able to come up with the solution quickly.

If you are having a hard time coming up with problems to try and solve on your own try using Google search for programming interview questions for your language or choice.

Also you can pick up books that are designed for teaching lower level CS courses. Most of these books are filled with programming assignments that are small and can be done quickly at home. They can be used for practice.


I am also very bad at tests and always have been. I could not for the life of me figure out why a programming class was given me tests to take with pencil and paper. I never got good at it. However, what I did do was explain to interviewers that I had this problem and knew about it. I also managed to interview for companies that did not give me silly tests.

My suggestion is to tell the company before you go into the interview that you don't do will with those sorts of tests, however you are happy to X instead. (Figure out an alternative that makes sense and you feel comfortable doing.) For myself, I offered to send them code, and one time I suggested that they give me a simple program to write, and I'll bring it with me to the interview in 3 days time.

Depending on where you are looking to get jobs this may or may not work for you.

Not the answer you're looking for? Browse other questions tagged or ask your own question.