I keep failing hands on part of the interview, suggestions? [closed]

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

http://projecteuler.net/

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

Answer 8

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.

Answer 9

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.

Answer 10

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]

Answer 11

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.

Answer 12

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.