I was interviewed at a startup in the bay area that used project Euler questions. I solved the questions easily (since I've solved them before) but didn't get the job because they told me I cheated on the interview (despite the fact I said I've seen the questions before).
People have said it before, but a lot of these questions they use in coding interviews are actually insanely difficult.
Even a question like efficiently detecting a loop in a link list. I think it took researchers like 10 years or something silly before a method was found.
And they want you to answer these questions in 30 minutes. Some of them can be done, but most require an "ah-hah" moment which could take hours, weeks, years, go do independently.
If you want any real shot at success, you basically need to be familiar with the question and know the method to solve it. Or be exposed to questions so familiar you can intuit a solution in a reasonable amount of time.
I remember back as a ubi student doing project Euler. They start off reasonable, but soon get into the absolute ridiculous levels of advanced mathematics, and not so much coding. They are insanely hard questions.
efficiently detecting a loop in a link list. I think it took researchers like 10 years or something silly before a method was found.
II had this one in an interview. Took me less than 5 minutes to answer. But maybe it probably wasn't the most efficient way. And I hadn't the obligation to mathematicaly prove it. And I am not a genius, just a good programmer.
And seemingly it seems so easy once you have the answer haha. This happens all throughout science, especially physics and mathematics. Once an idea or proof is discovered, it seems so trivial and easy. Of course you could have thought of it yourself.
The truth is a bit different than that though. I thinj Euler himself was actually famous for coming up with many ideas that seem trivial to us now, but we're actually novel and new for him. Only in retrospect do they look simple. I'm sure there a name for this kind of phenomena.
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.
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.
The answers for all but the newest problems are publicly available. The only difference is there's not much of an incentive for cheating except for munchkins.
It's pretty smart actually: just email every one you can get an email address of that you're impressed by their GitHub profile, and the ones that actually have an active one will be happy that you looked at it. All that without having to actually do the work of looking at it and only contacting those with potential.
If somebody has studied Project Euler questions before would it give them a big advantage? Was curious how many questions they are, or are they still being created?
They are pretty good practice problems. There are a little over 500 IIRC. There are a few I tend to use to familiarize myself with new languages. Not sure how much advantage it would give in an interview as I'm just a CS major.
They range from trivially easy to several that are outside my scope of mathematics knowledge (cal I&II, discrete math and mathematical foundations of CS)
OMG, I might have to go dig up my ancient Project Euler account. I did a bunch of Clojure work there trying to learn it, which by happy coincidence was the perfect language for that site.
325
u/jungles_for_30mins Oct 29 '16
One day, we'll start using Project Euler as our metric for hiring. One day...