I\'m a Java developer, mostly doing Spring stuff. I understand the patterns, OOP

Question

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?

Edit: It's been a while now and I've noticed certain types of interviews and tests. 1) Some companies expect you to write some sorting algorithm from the back of your head, this is the case where you already take a certain prejudice towards the company, of course it's individual. But in my case, I'll try my best and if I fail, I won't cry about it, I'll try the next offer.

2) In other cases there's a task, it has multiple obstacles, but they're doable, it just takes some time. This sets a certain goal for the developer, in my case this is much more motivating. I think getting work done is the primary goal and all the optimizations should come later, because you are doing it in a limited timeframe. Of course this is also individual.

The second option might sound like a codemonkey's attitude, but I've noticed on myself that I really care about solutions, not the specifics. I actually received a lead position now, and I'm not really afraid of management. Perhaps I'm moving in that direction and that's a different topic. I don't feel so insecure anymore, since I've received many offers now and I've gotten a lot more relaxed and better at my job. I guess it's about finding out what you really want to do and how good you're at it.

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.