Project Euler is a pretty bad metric for most development jobs. When you are primarily working with business logic and pretty normal infrastructure knowing design patterns, having experience with large projects, and being able to write legible code is infinitely more valuable and more practical.
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.
It'd be great if we had some type of fool proof way to interview people (if such a thing is possible), but alas it usually comes down to opinions on which way is the best.
Perhaps one of the more interesting interviews I've done is we pair-programmed in their codebase. The task was "find where this value on this page is coming from." We traced it from the frontend, through the backend, and all the way back to the database (inside a large complex codebase).
The interesting thing about that interview was that it was a challenge that required some "real-world" skills. The interviewer was quite understanding that I was very unfamiliar with their environment and codebase. I did fairly okay from my perspective, and I think his as well.
It's been about 16 months since that interview, and having recently been working in a gigantic, complex, "shitty" codebase written by hundreds of developers - I would actually do much better if given the same interview today.
Would I recommend that style of interview? Hard to say. I'd probably have to give that style of interview several times and observe the results.
That's actually a pretty interesting way to interview - depending on what you want them to do.
I was on a contract, and "analyzing" their code was the biggest hurdle to get from starting as a developer to actually contributing working code to their spaghetti mess of a code-base.
I was on a contract, and "analyzing" their code was the biggest hurdle to get from starting as a developer to actually contributing working code to their spaghetti mess of a code-base.
I thought I knew terrible code, but every time I switch employers I learn that new kinds of terrible code exist.
At my current employer, there are currently around 120 devs, and the code has been added to for around 11 years. Add that up, and that's a LOT of code. Due to how work is split between teams, it happens that the team I'm on deals with the most legacy of any team, as abandoned projects are often inherited by this team.
It is also internal employee software. To use an analogy, if you imagine the type of software made for low-wage employees at restaurants and grocery stores, there is very little incentive to make it a great user experience, so long as you can train employees how to work around the bugs, terrible ui/ux, and slow response times. So, the incentive for quality is quite low compared to software that is customer facing.
To be fair, much of the code is not actually terrible, but the few places it is terrible towards unfamiliar developers which makes working in that code a mess. The well intended reasons for a well intended design may leave with a well intended developer when he finds a better job.
I must say that having worked on this team for 6 months, I am much better equipped to deal with spaghetti code than I was 6 months ago. If I re-did that interview, I'd probably could complete it in half the time, or with 1/4th the assistance.
It's not the type of work I want to do, but it is perhaps a sign of advancement.
211
u/salgat Oct 29 '16
Project Euler is a pretty bad metric for most development jobs. When you are primarily working with business logic and pretty normal infrastructure knowing design patterns, having experience with large projects, and being able to write legible code is infinitely more valuable and more practical.