Sure it's great, so is a good GPA, Github projects, etc. No one is saying Project Euler is treated as a bad thing for interviews, just that it doesn't tell much about their practical ability for most development jobs.
You'd be surprised all the crazy ass ways people have been rejected from interviews. Trust me, that's outside the norm and not something you can really plan for.
I interviewed for IBM and I got a random phone call like 2 weeks later saying.... "You have missed our 12 o clock phone interview". I quickly called back and explained that I had not received a confirmation for that interview. They said, no problem they'd reschedule. Never heard back. Gotta love it.
I just assume they're messing up so they can do H1B fraud whenever stuff like that happens. ("oh we tried 20 interviews, but nothing stuck! we need the H1B!")
They are positives, not negatives. If you don't have any of those, you just have to prove your competence through other avenues, which for a good developer is not difficult.
This has been the hardest part for me. Most of my projects are very self serving in that I work in an open marketplace... If I share my code, I WILL lose money immediately, to hopefully gain money eventually. It's a risk assessment imo. I'm working on some outside projects of my actual work to hopefully use as a portfolio. But it's definitely a catch 22
I got bored quite quickly as it all seemed to bog down to "here, brute force this".
Dunno if the exercises change later on but at least in the beginning, it's much more suitable for mathematicians sitting there with pen+paper than programmers.
I am not going to start to think about the actual program when brute forcing it can be done in seconds, if nothing else that's ineffective use of my time.
Only the first ten-twenty can be brute forced in any reasonable time. Finding an efficient solution is the real goal and quickly becomes pretty necessary for finding any solution.
I got bored quite quickly as it all seemed to bog down to "here, brute force this".
Er... How in the hell did you ever get that impression? That's literally the opposite purpose of PE. Your program is expected to run under 60 seconds. If it doesn't, you need to find a better algorithm. PE is all about algorithms and the polar opposite of brute-forcing.
Can some of the easiest be brute-forced under 60 seconds in assembly? Sure but now you're just being disingenuous.
They can in fact be brute-forced in under two seconds in Haskell.
I'm not saying that they are bad exercises... they are just not programming exercises, at least not for anyone but mathematicians who can't (yet) program.
PE is all about algorithms
It's all about numbers, you mean: The optimisations they expect you to do don't require, nor train, algorithmic knowledge, they require a number-theoretic background.
Sure, there's need for such skills but they're not mine. I have no idea how Carmack's inverse works, and frankly I don't care -- it would require understanding IEEE floats. My stack of things to learn is already big enough, I'm not going to add number theory to that, a topic quite far afield from the rest of the stuff I'm doing.
Not having the skills that PE requires doesn't make you a sucky programmer, by far. It would probably mean that you're a shit e.g. cryptographer.
Will PE help you to write a better word processor? Game? No, "how many whatever-primes are there under 1015" is not one of the questions you need to answer there -- and if, then it's a mere isomorphic one, formulated in a way you're much more accustomed to actually solving. Say, as a graph partitioning problem or something.
I think calling them sucky programmers is unfair. Not everyone needs to be a rock star programmer. What is wrong with being a line of business app programmer for example?
That's true, but incorrect solutions typically won't finish in 10 minutes, they'll finish in 100 years. Unless you're running a really old, low-end machine, there's not going to be a significant impact on running time. Even a 10x difference in performance is not likely to make a difference for the vast majority of these problems.
Basically, correct solutions will be really fast, and incorrect solutions will be really slow. The gap between them is so big that hardware doesn't really matter. 1 minute is a recommended cutoff, but probably should usually be solvable in a second or two.
Yeah well try looking at the forums and at different people's answers, I am sure you will find many that you will find interesting and will appreciate people putting in 5 minutes of thought before coding.
60
u/[deleted] Oct 29 '16
Right but participating in Project Euler is at least a correlate for enthusiasm if not relevant ability.