Show HN: Coding Interview Practice
interviewcake.com
interviewcake.com
These types of tests do little more than reinforce stale ideas and turn away unconventional well-rounded candidates. Used to play the game, now I win because I don't play.
As an employer, do you really want to find out AFTER hiring that the candidate is incapable of understanding a problem based on an oral or written description; incapable of capturing requirements, asking the right questions, and forming an attack plan without thinking about it overnight?
Testing someone's ability to follow along and contribute in real-time is part of the test, IMO. It does penalize "deep thinkers" and still waters, though.
I've had candidates email me a supremely perfect solution the next day, and that's a positive data point too.
Interview questions should hinge on, like, the experience and competence that I already have from having worked a substantial period of time as a professional computer programmer. Not on how cleverly I do on BS.
And I actually generally do very well on this crap but I still hate being impelled to take part in this kind of circus. In fact, it's annoying that I jump to being a top candidate based on this stuff and only then does an employer come up with some mundane requirement that should have been the initial qualifier/disqualifier.
Take 20 developers. If you give them a test with 200 difficult problems they would all score about the same. Instead, give them 4 difficult problems in a limited time frame. Now some of them will look much smarter than others. Only hire these candidates. Now you can believe you are part of a very selective group.
That being said, I think these whiteboard problems can be useful when you think of them as "trying out what it feels like to brainstorm with the candidate about how to solve a problem." That's how I think of them. There are plenty of people I just can't get on the same page with when trying to whiteboard together (different communication styles/speeds/whatever), and it's helpful to know that ahead of time.
When no one knows the answer and the object of the meeting is to find it, it might really be a brainstorm. When the interviewer knows the answer and expects the candidate to get it, where a real discussion isn't possible because suggesting things that aren't The Answer (or asking stupid questions) could significantly hurt your chances, it's a test.
Other questions have layers, like an onion. Those are the good questions. They should divide the candidates into STRATA. I think the stock question is one of those.
Strata 1: Everyone should be able to produce a brute-force, inefficient solution, and avoid the obvious+wrong solution. If not, they should have been weeded earlier by your phone screening.
Strata 2: Better candidates should be able to produce a more efficient and readable solution, sometimes with prodding. Some candidates never get here, even with prodding ("Have you considered x,y,z?")
Strata 3: Candidate skips straight to the correct solution, sometimes provides more than was required ("You shouldn't store data as keys; you probably want to return the time and buy/sell prices, not just the profit".) Interviewer needs to prod and ask questions here ("what's wrong with solution x? why did you do y? What if I want a list of possible trades?") to make sure it's not a memorized answer.
You shouldn't expect that, in ten minutes, your candidate can come up with the optimal solution that took you three hours. But they should be able to understand and recognize that solution if you lead them to it.
Anyone using these questions as pass/fail is doing it wrong, but that's not the question's fault.
But I agree an array would be a more efficient data structure for this :)
I'll never forget my former Bell Labs-theoretical statistican advisor (American. Stat Association decorated!) telling me about accidentally helping his high school-age daughter fail on a take-home probability problem for school.
I think I'd fit in with a company far enough along to have built its MVP (so they're not always in that perpetual crunch mode), but which has fewer than 10 engineers. I really value work-life balance, so I don't want to work insane amounts of overtime all the time, but I could totally live on a below market salary if the other aspects of the job were right.
I'm considering working with a recruiter. Anyone know any technical recruiters in the Bay Area who are worth working with?
Oh, and as always, my email is in my profile if anyone wants to take this discussion offline.
That said, I've been working as a web developer for 11 years now, bulding CRM's, CMS', Crawlers, automation tools, and all kind of web based stuff companies needed.
Also, I never went to college, and have been working before finishing high school (15 years old).
So, while I lack a lot of computer science education, I consider myself competent at developing solutions, and have progressed with coding practices.
But because of the US interviewing style, which I had never gone throug before, I am not employable there. Interview Cake may be just what I need : )
Im in LA right now and will check other places.
In the meantime, as candidates we do what we can.
Assuming the code comes back ok we then use it as the basis for one of the interviews on site. I usually discuss design decisions and then make some changes to the requirements to see how they react.
It's a sad state of affairs when the most intellectually challenging part of your job is the coding test you had to pass to get it.
The current process results in hiring people that are awesome at interview quiz questions, but can't sit down and do the actual day-to-day work.
1) Give me a take home problem.
Granted, a couple of the companies that gave me these problems clearly didn't know how to interpret what I gave back to them. One of the comments I got back actually offered as a criticism that my code looked "too sparse." But if you actually have the ability to make sound judgments, this seems to me to be the ideal way to judge a candidate.
No one is coding over the phone (ever) or with someone watching over their shoulder even most of the time, so if you reject someone just because they can't perform under such pressure, you're going to have a lot of false negatives.
2) Ask a breadth of questions.
One of the other interviews which I excelled at was a series of 20 questions that asked me about things ranging from what happens when a browser makes a request to a server, to what a CDN was, to what the difference between UDP and TCP was. This was only a small part of the range of what was asked, but the fact that I was able to speak with confidence on most of the issues showed that I had a strong foundation of knowledge. They also asked my confidence in each area before asking me the questions, which I imagine helped them gauge whether I was down to earth enough to even recognize the things I didn't know.
3) Ask a depth question.
Drill down deep into a specific problem that the interviewee seems comfortable enough in. For this one, it could be entirely theoretical, such as how one might build a particular system to solve a problem. The key is that you want to dig into why they make any particular choice along the way.
You should look for someone willing to say "I don't know about X, I'd probably look for the reference to learn if there's a data structure to solve Y" if you end up getting too deep. That being said, not all personalities will understand that this is okay during an interview, as by the same token, a selection of interviewers won't understand that this is a sign of strength, not weakness.
I'm not sure that shows up in hours of interviews either...especially when most (all?) of that time is spent on "technical assessment"
And people who are getting better offers at better companies.
You'll never know.
I expect this to bite me as ageism in ten years, when a 23 y/o Stanford grad will be aghast that I don't spend my evenings playing with MeteorRails.js.
Relying on a "hint" to figure out that you can only sell after you buy seems more like an additional constraint rather than a true hint.
In the case that you mention, if someone asked me "Can I short sell?" I'd be happy that they considered the order of events there and were trying to explore the problem. I'd certainly remember it in my interview feedback. My response as an interviewer would be more or less "That's an interesting thought. To simplify the problem, let's say we're risk averse and prefer a finite loss potential. Go ahead and just consider purchase before sale."
One of the biggest criteria I looked for from junior engineering candidates was that they didn't just jump into implementation and asked clarifying questions. That's hard to do with the sort of site this is so maybe in this case more complete specification is useful, but any way that a bit of ambiguity can be introduced means that you can have a meaningful conversation with an engineer about representation, the shape of the problem, the inputs, what the criteria for success are, what is truly necessary to solve a problem. I want working code in the end, but hearing the things a person does or does not consider about a problem is interesting and valuable to understand a potential teammate and how they think.
However the way the question was phrased just makes it seem like the person who phrased it doesn't understand how trading works in real markets.
It's not an excuse to leave things like that vague so that a candidate would have to bring it up to you. If you want to ask open-ended questions, ask obviously open-ended questions; don't make an attempt to turn simple technical questions into open-ended ones.
I also found it curious that the example listed the stock price at 1 AM. It would be far more of a real world example to only consider times during the normal trading hours.
A question phrased about a particular real-world domain that doesn't makes sense within that domain just doesn't seem fair to ask.
But again, total nitpick on my part. The actual format in which the questions were presented was generally done well, and a nice refresh from the typical "interview prep" sites.
I don't know what you're considering "talented", but Google seems to believe that your school/GPA has almost nothing to do with how well you'll perform on the job.
NOTE: Let's not confuse this with how likely you are to become another Zuckerberg. Starting a company is completely different from working at one. I don't think Zuckerberg could work at Google. He'd be bored out of his mind and/or argue with everyone, then quit in less than a year.
https://www.linkedin.com/today/post/article/20130620142512-3...
"GPAs don’t predict anything about who is going to be a successful employee. “One of the things we’ve seen from all our data crunching is that G.P.A.’s are worthless as a criteria for hiring, and test scores are worthless — no correlation at all except for brand-new college grads, where there’s a slight correlation,” Bock said. “Google famously used to ask everyone for a transcript and G.P.A.’s and test scores, but we don’t anymore, unless you’re just a few years out of school. We found that they don’t predict anything. What’s interesting is the proportion of people without any college education at Google has increased over time as well. So we have teams where you have 14 percent of the team made up of people who’ve never gone to college.”
Doesn't seem quite as appropriate when the context is changed, does it?
My reaction was provoked when I was considering paying for the rest of the questions, saw the comments and saw the link to all of them. I was too hasty in my response.
Just because I can pirate something doesn't make me feel ripped off for not doing so. I feel better for having paid someone for their time and effort.
Instead of scheduling an interview, you have prospective companies posting their interview schedules. For instance, "Hi, I'm from Google. I'll be hosting a technical interview at 330 PST. If you'd like to potentially work for Google, go to this link and answer my question in the time allotted. I'll be in the room to answer any questions." Of course, there's no whiteboarding involved but it might act as a pretty decent vetting process.
Went ahead and signed up as some of what's there is probably bit over my head. Looking forward to seeing it grow.
I'd love to see even more discussion on each solution. Ideally something like an interactive "The Practice of Programming" [0].
I guess I was a bit off-base, I was thinking about using a database.
Well cool, this trie thing it suggests is pretty much what I was thinking, and something I'd thought about before without knowing what it was called.
One suggestion (based on the one question I saw) is to also mention at least in passing, concerns with edge cases in the inputs. Python often lets you ignore these things but interviewers tend to be charmed by at least an attention to the possibility that your input is empty.
Also, it might be worthwhile to have some "homework" problems that don't have solutions that are variations of the main problem.
For example, the stock price problem is sometimes presented as changes in price rather than absolute price. This adds some subtle differences that might throw people off unless they've tried it.
I imagine similar variations exist for all the problems available.
For example, the stock price problem (https://www.interviewcake.com/question/stock-price ), if you insist the solution has no mutables, I really don't know how a Java/Python/C guy would approach it. In Scala, you'd do
import math._
val s = List.fill[Int](100)((random*1000).toInt)
s./:((s.head,0)){(a,b)=>(min(b,a._1),max(a._2,b-min(b,a._1)))}._2 def max_profit(stocks):
def r(stocks, profit, lowest):
return r(stocks[1:],
max([profit, stocks[0] - lowest]),
min([lowest, stocks[0]]))
return r(stocks[1:], 0, stocks[0])Though, admittedly, I wouldn't pay for this at the moment because I'm happily employed. I did spend about $100 on books to brush up when I was interviewing in late 2011. I found actually the best practice for interviewing was going on interviews (I ended up interviewing at around dozen companies over the span of a month after I was laid off).
Currently, you're selling each question for about 35 cents. Although that's super cheap per question, $5 for 11 questions somehow doesn't seem like a great deal. However, I think people will be willing to pay the same for a larger database of questions e.g. I would be happy to pay $25 for 80 questions).
edit: back when I used this in Feb, I constantly got logged out and had to log back (was using G+ logins). Did this get fixed?
One can do addition mod n. As long as 2n doesn't overflow, you are good.
You can further improve it by not using any number larger than n. Say we want to sum a+b mod n, wlog assume a<b. If a+b<=n, we are good. If not, then b>n-a. Note a+b mod n = a+(n-a)+(b-(n-a)) mod n = (b-(n-a)) mod n. Now the calculation doesn't overflow.
Here is something to show avoid overflow can be quite difficult... http://cstheory.stackexchange.com/questions/19591/avoiding-o...
I wonder if the result will still be correct. It's possible to have multiple answers. e.g. (7 + 10) % 6 = 5. But both 5, 11, 17 % 5 == 5. Can you find which one is the actual sum though?
---btw, the xor solution--- (defn find-dup [dup_set test_set] (reduce #(. clojure.lang.Numbers xor %1 %2) (into dup_set test_set)))
If we did mod n addition the whole way, we have the result a+x mod n, and let that number be b.
Claim: if a + x = b mod n, then there is a unique solution x in between 0 and n-1. In fact x = (b - a) % n.
Now, if x = 0 from the above computation, you would know it is n instead of 0.
Duplicate array: [1,2,2,3,4]. If you do mod 2 sum, then you have 1+0+0+1+0 = 2 mod 0 = 0. But another possible duplicate set can be: [1,2,3,4,4].
10 + x = 0 mod 2 (see 4%2 = 0 and 2%2 = 0? So x can be either 2 or 4.) If you let modulus number N be larger than n (e.g. n = 5 in my example, just let N = 6. Then 10 + x = 0 mod 6 will yield only one possible solution that is 2) then I think your solution will definitely work.
But I think the big problem is: you said x = (b - a) % n. That is true, but how do we get "a" (the sum of all unique numbers from 1 to n) without overflowing? The reason we do modulus summation is for avoiding overflow, granted that can get "b" easily, yet now we have to find "a" still, I find we are still stuck. Any suggestion?
Even if assuming everything will work out and my previous question can be responded, still the modulus function is WAY MORE expensive to compute than xor operation.
That was entirely what I was suggesting, but we don't need N>n. N=n would work. (btw, I defined n to be the size of the list -1, therefore in your example, the number is 4)
> But I think the big problem is: you said x = (b - a) % n. That is true, but how do we get "a" (the sum of all unique numbers from 1 to n) without overflowing? The reason we do modulus summation is for avoiding overflow, granted that can get "b" easily, yet now we have to find "a" still, I find we are still stuck. Any suggestion?
We can compute a using the same function that computes b. just sum all numbers from 1 to n mod n. Here is a quick demonstration in Haskell.
> Even if assuming everything will work out and my previous question can be responded, still the modulus function is WAY MORE expensive to compute than xor operation.
True. I just want to show how to modify another solution so there is no overflow.
www.InterTechTion.com
Edit: Link to archive of all questions I sent out: http://www.intertechtion.com/answers/
Will you be adding more questions in the future?
I do like the concept of the site!
The problems are definitely a bit more advanced. I do try to make sure that any "vocab words" (data structures, algorithm types) can be clicked on for a deeper explanation. But if you haven't seen big-o before, for example, you'll be in the dark on a few things right now. I have some more "bottom-up" curriculum that I've developed from teaching at boot camps around San Francisco, and I'm still working on figuring out the best way to present it on the site.
For Big-o specifically (the thing that looks like "O(n)"), I really like these resources: http://stackoverflow.com/questions/487258/plain-english-expl... http://www.perlmonks.org/?node_id=227909 http://www.daveperrett.com/articles/2010/12/07/comp-sci-101-...
Best of luck!
I think I prefer the learning by doing approach like talentbuddy[1] personally.
Deleted comment