Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm a Java developer, mostly doing Spring stuff. I understand the patterns, OOP, bean injection, multithreading and everything that goes with it. I don't feel like I'm a bad developer, I get my stuff done.

So let's say I go to some developer interview. It shouldn't be a problem to get a job, right. No. I go on an interview, and usually I pass the interview where they ask about my dreams, salary and all that personality stuff. Then they give me a technical assignment, something to program, some tricky question, a codility test in limited time. I fail. I get below average results. I don't understand why? Am I that bad? It even pisses me off, that I have to prove myself and fail. In general I've been programming for four years. It's not like I'm writing some crap, that barely somehow works; it's structured. I got the current job by showing something I had done in my spare time, and it impressed. It's impossible for me to get a developer job by passing all those tricky hoops.

Also, the actual work is not that hard, all the sorting algorithms, cryptography and somewhat difficult problems are usually encapsulated. Why are the interviewers asking you to do something you did once back in university many years ago?

Is this normal? Is there something I can do to improve myself? How do I get the job?

share|improve this question

closed as primarily opinion-based by gnat, MichaelT, jmo21, Bart van Ingen Schenau, Dan Pichelman Sep 27 '13 at 19:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

6  
Check out this video: channel9.msdn.com/Events/ALM-Summit/ALM-Summit-3/… What you're describing is what they call the "Knuth Fanatic" interviewing anti-pattern, and they use almost exactly your verbiage about it being something you would have been better qualified to answer as a student. –  Erik Dietrich Sep 26 '13 at 14:18
5  
Just because you have a job means you know how to code, how processes work or how to solve algorithmic problems. Just because you could do it 5-10-20 years ago doesn't mean I believe you can do it today. Any company that DOESN'T test my coding ability during an interview is telling me that I'm no different from the countless hacks out there who have "Senior Software Engineer" titles but still can't code their way out of a wet paper bag. That is enough usually to tell me that I don't want the job in the first place. –  Joel Etherton Sep 26 '13 at 17:16
3  
@test - the grass is always greener. Change profession, and you'll get similar stupid questions to answer in other interviews. The only true answer is to beat this problem before moving on. (or, might I suggest, changing technology - if you have to learn C for example then you will have to learn the basics first, and those basics will serve you in very good stead for all future interviews.) –  gbjbaanb Sep 26 '13 at 18:56
4  
@test Changing careers seems a little drastic. I've been in the field professionally for well over 20 years, and I've never once been handed a test to do during an interview. Never been asked to sit down and write code, either (other than some white boarding). The key is to not apply to places that have HR departments. Look for small companies and startups where you are dealing directly with the owners or primary decision makers. Also, develop your own projects that you can show off. –  GrandmasterB Sep 26 '13 at 20:16
13  
Listen, interviewers have to do this. You don't see the other side of it. Try interviewing and you will know. You get all kinds of people who look good on paper but are impostors. I'm talking about candidates who can't answer straightforward questions about a linked list, using box-and-arrow diagrams on a whiteboard. Resumes can lie. References can be faked: they can be your friends who lie and say they were your managers. It would take time-consuming detective work to unravel lies in a resume; it is much more efficient to throw some programming questions at the candidate. –  Kaz Sep 26 '13 at 21:38

6 Answers 6

I think you said it "somewhat difficult problems are usually encapsulated" - but these are not the questions you're asked at interview.

Interview questions are there to test your knowledge of the basic stuff, but real work tends to be about reusing libraries and other done-for-you pieces. No-one will really ask you about any particular library unless they use it heavily, simply because it is too narrow - you either know it because you've read it or used it, or you don't know it. It says nothing about whether you'll be able to do more than that, or pick up other libraries. So interview questions focus on all the surrounding bits, "trivialities" like array reversion or string manipulation. They're there to test your knowledge of the language itself, not any of the tools you use to work with it.

I would keep track of all the questions you've been asked and seek out the answers not only to the questions but all the areas that they've asked you. If you are asked to reverse an array (yep, boring) then work out all the technical "low-level" details of how arrays work, how they use memory, how you can optimise them, when they are suitable, etc. There are good reasons to know this stuff and not focus only on gluing together stuff someone else wrote for you.

I've been coding for .. over 3 decades now, and I still have to prove myself with stupid interview questions. Lose the attitude that you're too good to have to do them. (we're all too good to do them, but we still have to).

I think such questions are of limited value in interview except to filter out those who are really unsuited for the role. I greatly prefer interview questions where you're asked to code review some code - less pressure to write something that works yet you get to demonstrate your knowledge of design and structure, as well as show your knowledge of a few common coding errors.

share|improve this answer
11  
I couldn't agree more. In the author's case if he is failing these programming interview questions, then he should be looking into learning those concepts before the interview, so he knows those concepts even if its only for a short amount of time. –  Ramhound Sep 26 '13 at 13:08
5  
I bet his attitude of being "better than" interview questions is coming out during the interview. I would equate that attitude to someone who doesn't believe their code can be improved; I think that's even more telling than whether he actually solved the problems. –  BlueRaja - Danny Pflughoeft Sep 26 '13 at 16:36
10  
+1: If only for this line: Lose the attitude that you're too good to have to do them. –  Joel Etherton Sep 26 '13 at 17:14
    
@JoelEtherton I hate hate hate those damn questions with a passion. But they're not that difficult to study for. It's almost always trivial stuff, and if you come up with a couple of quirky implementations beforehand, you can often slap something up on the board that'll make their jaw hit the floor. It's an opportunity –  Satanicpuppy Sep 26 '13 at 19:53

I understand your frustration. I have also been programming for over 3 decades, professionally for over 2, and if I haven't interviewed for a few years, I do badly. It is not because I am stupid. Rather, the problems I face at work are mostly of the type that take weeks or months to solve. They tend to involve understanding user needs, coming up with multiple designs and choosing the best one, prototyping, performance tuning, learning new technologies, and communicating technical issues to management, or brainstorming with a team. My day to day work is so far removed from memorizing Euclid's method for calculating the greatest common divisor that I'd almost certainly fail an interview question about it.

For better or worse, my career is most of my life. When I have a job interview that I care about deeply, I get nervous. A problem that is simple at home is easily compounded by "stage fright" and I can freeze in an interview in a way that I tend not to ever do on an actual job. I have watched this happen to most of the candidates I have given quiz questions to. See: How to avoid jumping to a solution when under pressure?

I have used "simple problems" to interview candidates and watched person after person fail them. I am not the only one who has concluded that brainteaser interview questions are overrated: On GPAs and Brainteasers: New Insights From Google On Recruiting and Hiring.

The best interview question for a technical candidate is, "Explain the most recent project you were excited about." I get more information about their problem solving, level of knowledge, technical ability, ability to work with others, general bitterness, willingness to take direction, and everything else related to doing a good job with that one question than I've ever gotten with all my quiz questions combined. If the interviewee likes the work, you can usually see them light up. Their anxiety will melt away with their enthusiasm, the way you hope it will on the job. This kind of interview is actually fun, and I usually learn about something in the process that I'll research later.

Sadly, quiz questions make the interviewer feel smart and powerful and give the illusion that they weed out unqualified candidates. They will probably remain popular forever. For anyone who hasn't just finished their CS degree, you need to spend several months practicing solving little problems on a whiteboard and coding them up to prove that they work. 4Clojure is so much fun that it's addictive, and contains many simple problems with 10-20 minute solutions. Project Euler has more challenging problems, but the easier ones are still within interview range, and not language specific. Also, it's very important to review linear equations and using simple geometric shapes on a 2D coordinate system. Algebra questions make very popular coding problems in interviews as well.

You have to practice for an interview the same as you'd practice for any performance. Start months ahead of time if possible. If you're lucky, you'll get good questions. Sometimes, you just personally have a bad day. This is life. Finally, you may need to go on many interviews in order to both get yourself in shape, and to find a place where you fit well.

For my first programming position, I contacted over 100 recruiters and went on dozens of interviews before I found a place where I fit. Ironically, I was hired at the one place that administered a written programming aptitude test. I set a record for the highest score and the least time taken to complete it. So some tests can play to your strengths. The written test let me think alone in a room without anyone watching me, frowning, and glancing at their watch.

Like any numbers game, you may have to play a lot in order to win.

Good luck. Try not to take rejection personally.

share|improve this answer
2  
+1 million. Especially for "the problems I face at work are mostly of the type that take weeks or months to solve", which illustrates how busy work tests dont necessarily apply to how someone will do on the job. –  GrandmasterB Sep 26 '13 at 18:05
1  
A good chunk of this answer just echoes the OP's frustrations and doesn't really answer the question. But there's still a lot of good advice, so +1 –  Kevin Sep 26 '13 at 20:02
    
After the first sentence I couldn't help reading your answer in Hamid's voice. –  Thomas Sep 26 '13 at 23:45
1  
"Good luck. Try not to take rejection personally." Reminds me of one of my favorite quotes. "Don't ever let success get to your head. But also don't ever let failure get to your heart." –  cYn Sep 27 '13 at 3:33

why are the interviewers asking you to do something you did once back in university many years ago?

Because that's the only thing they can expect all reasonably competent programmers to know. Unless, of course, you count FizzBuzz.

I'll tell you a little story. I once did an interview for a cruise line. They wanted someone who knew how to program in Visual Basic. As a programming test, they gave me a simple task to perform; I think it was some sort of customer lookup. They said I could use any language I wanted. Well, it was the middle of an interview, and the tool I had been using for years to do in-house application development was Microsoft Access, so I took two pieces of paper and made a mockup of a simple system with a couple of tables, a couple of forms, and even a report, IIRC. It took me about five minutes.

They were fairly impressed, although they did ask why I didn't just do it in Visual Basic, or even pseudocode (which they apparently considered part of the set "any programming language"). I told them I could have done that, but it would have taken an hour to do it right, and I didn't want to waste their time. In the end, I didn't get the job; I got the impression that they thought I was overqualified (it was a junior programmer position).

My point is that programmers' backgrounds are highly diverse; the only thing you can reasonably expect every competent programmer to have is a thorough grounding in the fundamentals. You should have that anyway. If you don't have it. strive to obtain it.

share|improve this answer
1  
"I told them I could have done that, but it would have taken an hour to do it right, and I didn't want to waste their time." Could they have not hired you because you preferred the quick solution over the right solution? –  Brandon Sep 26 '13 at 19:36
3  
@Brandon: One of the interviewers specifically remarked to me: "You have a Masters degree. You're going to want my job a year from now." –  Robert Harvey Sep 26 '13 at 19:44
    
Ah, that's messed up. –  Brandon Sep 26 '13 at 19:55
2  
lol, they wanted someone with no ambition, bullet dodged! –  jmo21 Sep 27 '13 at 10:00

Sometimes the solution to the problem is secondary to how you handle the problem. For example, does your code do bounds checking or check for NPE's?

I have candidates write sample code with every phone screen and of those who give me code which meets the requirements (there are many who don't), I have to convince them that their code will throw an error.

Examples of things I look for in sample code:

  1. Do you ask questions for clarifications? If I mention an array of integers, some developers will ask if it is sorted, or has restrictions like only non-negative numbers. Other developers just assume.
  2. Do you consider different types of input? What if the input isn't what you expected?
  3. Will you accept feedback / criticism if your code is imperfect? One candidate insisted that you cannot have a null array reference in Java, rather, Java treats null arrays as empty / zero-length. Others have refused to accept logic flaws I point out and even show them which conditions / inputs will fail. They want to argue instead of improve their work.
  4. How do you handle error or boundary conditions? Throw exception, return error code? Can you defend your approach or do it "just because"?
  5. Do you accept the problem I present to you and strive to solve it or whine that it's beneath you? It sounds obvious, but I have had developers tell me that they just don't write code. They have people write code for them. I'm not sure why they applied for a developer role.
  6. Did you unit test your code? I never thought about this for interviews before and I don't really expect it, but one candidate actually sent me a unit test with his code. Extra points.
  7. Did you test your code? Similar to the first, but more fundamental. I received a code solution that actually did the opposite of what it was supposed to do.

I doubt the latter two were your issue since you seem confident that you solved it correctly.

share|improve this answer

How do I get the job?

There are two types of businesses you can apply to: those that make their money primarily through coding, and those that have a tech department to augment their primary (usually sales) business.

Development studios

Their primary resource is programmers. They will have a lot of experience screening and interviewing coders. They get a ton of applicants, and have to weed out all the duds (see Kaz's comment). Because they get so many applicants, it is much better to reject a possibly good candidate than to accept a possibly bad candidate - or even waste time bringing them in for an interview. They will have a fairly strict battery to screen out most people before they can even get to the point where they can shine.

When you do finally get a job, you come in at the bottom level of a rigid, established hierarchy. There will be a process where strategic decisions filter down through levels of management and finally end up as assignments handed down from on-high. You get to work your way up through the ranks of Dev I, II, etc.

Regular Business

Their primary resource is people that are not programmers (usually sales). Everything I said above applies, but it applies to the sales staff. The tech department will be small compared to the rest of the business. Because programmers aren't the core workforce, the business won't be as experienced at interviewing or managing them, so their tests will tend to be less thorough (I got my first position after a 20 minute interview with no written code - they got lucky it was me ;)

When you get a job, you will most likely be in a position of autonomy. Instead of fitting in as a cog in the bottom level of the machine, you will be one of only a few in a department that likely communicates directly with upper-level executives. You will inherently have more responsibilities and decisions, simply because there isn't a bureaucracy in-place to make those decisions for you. You will get to put really good looking design and leadership experience on your resume.

If these jobs are so awesome, why isn't everyone applying?

Several reasons:

Even though the absolute number of positions available is large, they are spread out over many companies. A medium size development studio might hire for a position every month. A regular business might hire for a position once a year.

Intuitively, it seems like surveying 10 development studios and finding 5 open positions is much more efficient than surveying 20 other businesses and finding 1 open position. It makes sense to look at fewer businesses that will have more positions, but when everyone is doing that, the competition for those positions is much tougher.

Money. Just like they don't know how to hire or manage programmers as well as a programmer-specific business, they also don't know their value. You pay for autonomy and rapid advancement by taking a smaller salary than you would at a development studio. As a young person with no family trying to break in, this should be an easy compromise.

My own experience

This advice comes from my own experience, first from breaking in by getting such a position, and then from trying to hire people.

I started working at a medium-sized company (about 100 people) with a tech department that was 2 people when I started. As I've said above, the "interview" was about 20 minutes of me talking excitedly about the coding I've done. Apparently, I still beat out 10 or so other candidates.

A little more than a year after starting my first real job, I was already in a lead position and responsible for hiring new people as the department expanded. This is where the money thing comes in. I started at a ridiculously low hourly rate (for a knowledge worker; as someone used to working in the service industry to pay for college it was still more than double what I was used to making).

After we started hiring and people who were to be hired below me were asking for a salary an order of magnitude greater than mine, my salary was raised several times to bring it closer to what I would be making at a development studio - they weren't trying to set a low salary as an attempt to be cheap, but rather because they didn't know what to expect. Once people started asking for much more, they wised up and started throwing money at me.

After we set a non-ridiculous (but still on the low end) salary, we were able to fill the positions after a few months. The lower visibility combined with lower salary of our positions meant that we didn't get a whole ton of applicants. Rather than being able to pick out the single glowing gem, we had to go with anyone that filled the most basic of requirements. If you happen to be a gem that doesn't do perfectly on tests (because doing just "very well" isn't enough when there are so many applicants), this is good news.

The total numbers looked something like this:

Applied: ~20

Interviewed: 4

Position offered: 3

So of the 4 people who made it past the resume phase, only one was disqualified, because he was completely unable to write any code. The other 3 passed by demonstrating just the basic level of proficiency - if you could write a simple function or two, and create a CRUD site, we would have made you an offer. Each of those offers was about 2 weeks apart, and the first 2 people rejected them. They wanted more money, but were at best average programmers. Of the people that didn't get past the resume, the reason was almost always because they had 10-20 years of experience with "senior" level titles, so interviewing them for a low-paying entry level position wasn't worth it.

share|improve this answer

I can't answer your question in particular, but I do want to describe what we have been doing where I work. This is something we have just started doing, and I haven't been involved in it, but I've heard some things from the people looking at them. These have been assignments that are given to people and they can complete them over a day or two. So yes, people could get their friend to do it for them.

What we have been looking for isn't a 100% correct answer, but more of the intangible qualities. Of course, a completely wrong and screwed up answer won't help you much, but if the assignment has errors or isn't structured enough, it isn't the biggest problem.

What is going to help you is:

  • Code is structured or you can say that it isn't that structured and you would have improved that by doing X.
  • You've understood the principles and used them correctly and can talk about them.
  • You may have made errors or not gotten everything to work, but know where you were wrong and maybe explain how you would solve it.
  • You can talk about your work, saying why you solved something the way you did.

So it's not always about solving the assignment and getting the right answer, but more to see how you work, think and handle problems.

This might not be the case in all issues, some places that require great mathematics skills might require more.

share|improve this answer

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