Ask HN: Poor Codility performance, am I a bad programmer? | Hacker News Reader

Ask HN: Poor Codility performance, am I a bad programmer?

Hi HNers,

I've worked in life science research for several years. I have no formal computer science education.

I've programmed some pretty complex systems for analyzing biological data -- image analysis, advanced statistics, distributed computing clusters etc. I always manage to get the job done.

I applied for a tech job on a whim. They directed me to a Codility interview with some puzzle questions. I didn't do as well as I had hoped. I don't often deal with those sorts of problems at work, and I don't need to think about things like O notation to do my job well.

Am I a bad programmer? Have I just been dealing with easy problems and deluding myself? Has this happened to anyone else?

View on HN

Two things:

a. No, you're probably not a bad programmer. Companies who recruit solely based on codility type questions are... How do I put it?... Not smart.

b. Learning things like analysis of algorithms, data structures and other computer science fundamentals is useful, even if you might not use them directly, they will influence the way you think.

It is never too late to start and given an open mindset, willingness to apply oneself and consistent practice, it won't take long to understand the basics of computer science. I usually recommend this is a starting point :

http://interactivepython.org/runestone/static/pythonds/index...

Thanks for the link, I've not seen a book that deals in algorithms that didn't assume calculus knowledge.

My CS education wasn't exactly MIT or Stanford, so this should help plug the holes left by my university and shameful lack of curiosity years ago.

Thanks again!

Sorry to hear about your experience with brainteaser coding interviews. They really are not a true test of your abilities or value as a developer. From personal experience the people who tend to do well on those questions have just practiced that discrete skill a lot and may or may not actually excel on the job, and lots of people who bomb these interviews turn out to be amazing developers. Take the example of the guy who wrote homebrew but didn't get hired at Google because he flunked a question about trees.

That's why at Lytmus we've created a way to interview with real world coding projects. We spin up VMs with full development environments where companies can ask you to do the kinds of things you actually do on the job instead of inverting binary trees and what not.

Would love to get your thoughts as a candidate who's frustrated with current interview processes, we have a demo available on our home page (www.lytmus.com).

There are somethings you may have not known about the codility test - they have an FAQ: https://codility.com/candidate-faq/. You can lookup stuff on the web. You can also use an IDE.

For the codility test you need preparation. The problems are not easy and the problem setters underestimate how long it takes to solve a problem. Unless you're regularly participating in coding contests etc, you will not make it. The way we program day to day, and in a timed test env are different. You should not feel bad.

passing or failing on codility means nothing. it just means the company trying to interview you through codility has no idea how to interview you. I also had an interview stage on codility. solved 3 puzzles in 60 minutes. in next round of interview i was again given another puzzle via screensharing. i took 40 minutes to solve it. did't make it. point being it is probably not a good company to work at. Don't feel bad. Try somewhere else with a proper resume/portfolio showing your achievements.

codility for code challenges once in a while, yes. if its used just to see how you approach a problem and try to solve it, its good as it have nice code replays for the interviewer. But some companies want you to solve some random hard codility puzzle in 30 minutes or else you are no good

> passing or failing on codility means nothing. it just means the company trying to interview you through codility has no idea how to interview you.

It's a decent enough way to filter out obviously bad candidates without eating up your time (which is a big deal for small teams). I've used Codility for interviewing and being interviewed before and thought it was fine.

I would only reject a candidate if they got say less than 50% and the problems chosen weren't too difficult. If a company is going to be expecting 90% pass rates for super hard problems the rest of their interview process is probably faulty as well; that's not the fault of Codility.

> passing or failing on codility means nothing. it just means the company trying to interview you through codility has no idea how to interview you.

I didn't say it was a fault with codility. Some companies, like your's, use it in a sensible way. But I think there are many companies which use this tool the wrong way. Anything except the easy level takes more time for someone who doesn't practice these kind of challenges every day. Moreover correct algorithm only scores 50%. 100% score can only be achieved upon perfect optimizing, which is very hard to do within 30 minutes. And your can't know which edge cases tests are failing until the solution is submitted after which its not possible to edit/correct it.

Yeah, I'd always take the points you mentioned into account when reviewing a solution. Along with saving time I did find reviewing Codility submissions quite revealing. I've seen cases where the candidate couldn't get code to even compile, another where they didn't know Java includes map data structures existed (asked them in the follow up interview) and another where the implementation for an easy task was super slow when the nearly fastest approach should have been obvious (again, asked about in interview).

I'd say it's better for identifying really unsuitable candidates than it is for identifying who are the best ones.

Experiment is hiring smart life scientists-turned coders, and we don't use abstract coding puzzles for interviews.

http://experiment.com/jobs

Nope, not doing well with Codility doesn't mean you're a bad programmer.

Every time I interview for a position, I spend a few weeks reviewing data structures and algorithms. Otherwise, I wouldn't do well at them either.

It's just another hoop us programmers have to jump through to get a job :/

Doing the job and getting the job are two very different things.

To get a lot of job, you often have to jump hoops like simple or more complex algorithmical problems. Like it or not, that's just how it is.

If you don't prepare then you will do poor, regardless on how well you do on your job. So just spend a couple of weeks preparing. Complete puzzles in Cracking the Coding Interview, solve easy TopCoder challenges, start working on Project Euler as a few ideas - there are much more resources to help you out there.

You want that job? Be prepared for that interview.

What's a good programmer?

Relatively speaking, anyone who is good enough. On an absolute scale, maybe someone who makes reasonable attempts at exercises marked [43] in The Art of Computer Programming?

As Scott Hanselman says, "we are all amateurs." Becoming better at Codility challenges is mostly a matter of improving in the areas it tests...and I don't think that knowledge of Big(0) ever hurt anyone [inappropriate optimization for it is another matter].

Stepping out of the comfort zone on a whim and finding an area of weakness certainly has given me perspective on my knowledge, skills and abilities. Sure rejection and failure kind of suck, but for me self delusion is worse over the long term because that's how I came to be surprised by my weaknesses. Anyway, it's just a job and there's almost certainly better jobs out there.

Good luck.

I agree with others that performance on programming puzzles is not representative of your skill as a developer. However, I'd also like to add that knowing how to analyze worst case runtime or space with Big O notation is very useful and can make a huge impact on the performance of your application.

While reviewing programming puzzles may not be a great use of your time, I would suggest refreshing your knowledge on the Big O complexity of common data structures and algorithms.

Reply on news.ycombinator.com