
Coding Interview Tips - gameguy43
http://www.interviewcake.com/tips-and-tricks
======
RogerL
I think the programming/algorithms questions are probamatic. They by and large
depend on seeing some trick. Take the array 1..n one. It's an 'aha' type
question. You either see the trick, or not. I saw it after a minute, but
rolled my eyes. How does that in any way predict whether I can solve hard
problems in production. I give myself pretty high probability of not having
that 'aha' moment in an interview; whether I did or did not tells you nothing
useful.

Not to mention that this is not exactly an obscure trick. If you've seen it a
few times it is trivial to remember the trick and apply it. It's been awhile
since I've looked at the 'interview questions exposed' type books or websites,
so it didn't leap immediately to mind. Would you really select against me
because I haven't read such things?

edit: my phrasing was way to strong and unfriendly. I reworded the first
sentence.

~~~
typpo
I agree that the summation solution is an "aha" moment. But I don't think a
reasonable interviewer would _require_ someone to get that answer, and I can
see how this problem could showcase a candidate's thought process and ability
to reach incremental solutions.

For example, a naive approach is to sort and find the element where _arr[n] ==
arr[n+1]_. From here, the interviewer can see if the candidate is aware that
most sorts are O(nlogn). A better candidate knows that with a fixed range, you
can sort in O(n). Maybe the candidate will go with a hash table or set and
check for the duplicate that way. I've interviewed people who look good on
paper but don't intuitively grasp how to use hash tables, so this is a useful
screening exercise.

My point is not that this question isn't simple, it's just that there are a
number of ways to approach it besides the "aha" moment that give you insight
into how a candidate works.

~~~
RogerL
I see what you are saying. I was initially thinking about using dynamic
programming, and surely I could illustrate my chops (or not) in that regard.
But what if I do have that 'aha' moment, or I just remember that trick? Now
you are not measuring my ability to think about these things on my feet, but
either get no info (if I just regurgitate the answer), or get to evaluate my
acting skills if I decide to pretend to 'figure it out'. And still, none of
those, whichever way it goes, really answer how I do in production. I have
come across plenty of really 'puzzle' clever people that cannot really pull
together working code for a complex problem, and those (like me) who are just
terrible at them, but really deliver (ignore that I'm patting myself on the
back here, that's not the point, it's just a data point I know well). For
example, I am terrible at chess. I'll move a piece into a lane where they can
be attacked with impunity. The same goes with computers. Plenty of times I'll
miss something obvious, for a short time (like the length of an interview).
But I compensate for that with things like unit tests, thinking in the shower
and then coding at work, and so on. Take it on faith that it works and I
produce.

For example, let's say I need to hire somebody to do a lot of low level
optimizations. I can ask them some specific problem, and keep saying 'make it
faster'. Or, I could start talking to them about cache misses, and see if we
can just talk about it. Anyone that can actually do the work will be bringing
up the pipelines, out of order instruction executions, the costs of going off
chip, how to organize data and programs to minimize cache misses, well, the
whole ball of wax. In that context I can start feeling out if they are
original thinkers, or just plodding followers of some rules they read on HN or
somewhere. If they don't have experience in this, but I think they might be
good at it, I can talk about their debugging skills, or some other
engineering/optimization problem that they have solved. I'll admit that this
all presupposes an existing career - I do find it harder to interview and
evaluate recent grads because it is all speculation at that point. Heck, if
all you have done is CRUD apps I can see if you have thought about the
good/clean code vs put it together to get it out the door to get market share
issues. There is no one, clear, obvious answer, and a good mind will see that,
and be able to free associate about it. A mediocre mind will repeat whatever
HN quote resonated with them when they read it. If you can think about that
clearly, you can learn the micro-architecture and then use the same style of
thinking to optimize code.

So, all of that is why I don't like 'aha' questions, or even reverse the
string questions. I don't think it has any predictive value. Certainly,
Google, which asks tough algorithmic questions, admits that with all their
collected data they see no correlation between interviews and performance,
except for the situational type interview stuff I write about (and that the OP
wrote about).

~~~
gameguy43
Asking this question in a real interview, if the candidate missed the
summation approach and used an array to keep counts, I'd simply say "That
sounds good. What if we were really worried about memory use? Could we do it
with less memory?"

This is what it's supposed to feel like when Interview Cake offers the
"gotcha" that we can solve the problem with O(1) additional memory _after_ you
say you have an answer, _before_ showing you the final solution. In real life
I wouldn't fault the candidate for needing the nudge.

Another flow I've considered is to make the question multi-part, with the
second part (the "follow-up" question) adding the O(1) time constraint. I'm
worried that with this flow, in the case where you _do_ jump right to the
summation approach, the app will feel naive because it will pose a whole new
question that you've already answered.

So far I think the best approach is to keep the current flow but use a less
harsh word than "gotcha." What do you think? Do you still think the question
is just fundamentally too much of an "aha"?

(I agree that if the candidate jumped right to the summation answer on this
one it's a weak signal. I wouldn't ask this question in an interview--it's not
my favorite either, and it's unfortunate that it's a common one. My favorites
aren't on the site yet because they're hard to explain without pictures.
Adding those pictures is the next project!)

~~~
bcoates
Nitpicking because this tripped me up: You can do this in-place and in O(n)
time by repeatedly partitioning the array in half (by value) and discarding
the smaller half. I'd have needed a hint that you can do it in one pass to
have noticed the summation approach.

------
beat
As an interviewer, I'm far more interested in soft skills than hard skills. I
just want to know that they can actually program, which I can usually tell by
how they talk about accomplishments in the face of some probing detail
questions. Good programmers want to take a difficult problem, shoot it, mount
its head on the wall like a set of antlers, and brag about it to anyone who
will tolerate that. So competence shines through without a lot of tech
question grilling.

Soft skills, on the other hand... is this person an asshole? Inflexible and
dogmatic? Timid? Boring? That stuff drags down a whole team.

~~~
FLUX-YOU
>Timid? Boring? That stuff drags down a whole team.

The previous 3 I get, but these two? Maybe we should be interviewing for the
ability to get work done without being affected by other people?

~~~
beat
Timid people get overrun by dominant people, and the kind of aspie
cluelessness that runs through so many programmers (and I have no problem with
that). So timid programmers often wind up unhappy and unwilling to talk about
being unhappy, and the value of their ideas and opinions is lost. That's a
loss to the team.

Boring people? Hell, I just don't want to work with them. If I have a say in
hiring someone I'm going to spend hours a day around, I'm going to do my best
to make sure it's someone I find entertaining.

~~~
philwelch
> Boring people? Hell, I just don't want to work with them. If I have a say in
> hiring someone I'm going to spend hours a day around, I'm going to do my
> best to make sure it's someone I find entertaining.

What the fuck, man? Are you trying to hire professionals to do a job or are
you treating hiring as some sort of fucked up way of making friends?

~~~
kilburn
I don't know about you, but I spend approximately one third of my awake time
at work. One third of my conscious life. I'm going to make sure that I enjoy
that time, and having enticing colleagues has _a lot_ to do with that in my
experience.

There are tons of interesting, very professional people around. There's no
need to stick with the boring ones you find along the way, so yes, I would
also avoid them.

~~~
philwelch
If there's a glut of otherwise equally qualified people, sure. Is that the
case with programmers?

An otherwise boring guy who goes home to his family and spends his weekends
working on his house and watching football might get you one week closer to
shipping product than the guy who goes out for drinks after work and will play
video games with you and go rock climbing. So if you don't hire him, your
competitors will and then your competition will leave you behind while you're
out drinking and playing video games and rock climbing.

~~~
kilburn
Why do you link "enticing colleague" with "doing whatever with that guy after
(instead of) work(ing)"?

So your competitors hire the boring guy and get that feature one week earlier.
You hire interesting people and they form a cohesive team, carry each other
through tough times and work more passionately overall. At the end, you get N
extra, unique features as a byproduct of your more involved workers, shooting
months ahead of your competitor.

I know I presented an ideal case, but it makes my point. Working around boring
(as in non-interesting) people is boring, and you won't be as productive in
that environment. Thus, it makes sense to avoid these people unless you very
much need their specific skills and you can't find those anywhere else.

~~~
philwelch
I guess you'll just have to define what you mean by "boring" then. People who
can meaningfully contribute to solving problems are good programmers and good
professionals, but they could still be "boring" in the sense that they're not
interesting as people.

Let's say you had a coworker who was knowledgable about the problem domain you
worked on, produced lots of good code, made great positive contributions to
any design meeting or code review he was invited to, always had a free moment
to answer questions, but he always brought leftovers from home for lunch and
ate by himself and never really made a joke or hung around with the team in a
social context and you never got a sense for what his personality was outside
of work because he only ever seemed to get engaged when the discussion was
about work. I'd say that's a great coworker, someone I would love to work
with, but also a very boring person. So why wouldn't you want to work with
this guy?

~~~
kilburn
Obviously, I would prefer to work with this guy than with someone more
interesting but clueless. However, this doesn't mean that I would be happy
doing it.

On the one hand, you present a very idealized case: how can she engage in
(tangentially) work-related discussions if she's never around when discussions
happen outside of meetings? After 8 years in industry and 4 as a PhD student,
I have worked with and around many excellent people. However, I still have to
meet someone that fits your example. They probably exist, but it is way easier
to find either excellent interesting people or excellent boring people who
simply won't get as engaged in your team/company.

On the other hand, at least for a small company, hiring the wrong person is
much more costly than passing on a good candidate. Thus, when you interview
(hopefully excellent) boring persons, probabilities are hugely stacked against
them.

~~~
philwelch
The point of my example was to isolate "boring" as a trait to demonstrate
that, all other things being equal, "boring" doesn't matter. If someone's
boring and also an asshole, the problem is that they're an asshole. If
someone's boring and also doesn't contribute ideas, then the problem is that
they don't contribute ideas. And so forth. The actual problem is never that
someone is boring.

------
obituary_latte
-1 for forcing sign in. What if I don't care about saving my progress? What if I'm not a member of any of those services? Answer: 10 second pageview guaranteed to not become a return visiter.

~~~
HeyItsJames
They have a list of all the questions you can go through, no sign in required.
Not sure what you're talking about.

[http://www.interviewcake.com/all-questions](http://www.interviewcake.com/all-
questions)

~~~
bpicolo
Worst part is their max-stack isn't optimal. You can do it with O(1)
additional space.

~~~
BHSPitMonkey
Please explain. Without maintaining that ordering, you're going to have to
iterate over the entire stack after every pop, no? One of their requirements
was to keep pop() at O(1) rather than O(n).

------
dkhenry
Quick someone show this to college students. Most of his advice is exactly
what I am looking for when I give interviews.

~~~
hermannj314
So then give it to the people you are interviewing before you interview them.
You don't need a middle man.

------
Jemaclus
Here's where I think I diverge from most people on this topic. My personal
view is that I think by the time you bring someone in for an interview, you
should already know that they can code, whether that's through code samples
they provide or through Github accounts or whatever.

 __TL;DR; Don 't waste your applicants time or your own __

## The Interview Interviewing should have two parts, imo:

* Confirming that I actually wrote the code I sent you and know what it means

* Confirming that you want to sit next to me for the next six months

I can tell you right now that if I take time off my current job to go sit in
your office for an interview and you ask me basic questions like "What is
MVC?" or "What's the difference between a POST and a GET request?", I'm going
to thank you for your time and walk right out.

Why? Because my Github profile, which is featured prominently on my resume,
contains examples of both. Half my projects are MVC projects, and many of them
use 3rd party APIs (or are even APIs themselves!). The fact that you're asking
me basic definitions means you didn't even pay attention to the stuff I sent
you, so you're wasting my time and yours. You could have already figured this
out ahead of time. Instead, you asked me to take time out of my day (probably
during work hours) to ask questions whose answers I've already provided.

(Please note that this only really goes for non-entry-level positions. For
entry-level applicants, such as kids fresh out of college, you may not have
very many code samples to work with. That's fine. In that case, send some
problems for them to work on at home. Hopefully, these are dumbed-down but
real-world problems your company has faced in the past.)

## Phone Screen (aka verifying authenticity)

The first thing you should do is take a gander at my Github profile or my code
samples. Then you call me up at a prearranged time and ask me questions about
that code. Make me prove that I wrote what I said I wrote.

* I noticed you made this combat simulator (www.bitfalls.com/2013/08/autofight-php-job-interview-task-part-1.html). Walk me through your thought process.

* Your code appears to be a custom MVC. Why did you choose to go with a custom one versus say, CodeIgniter or Symfony?

* This project is an API for Nerd Nite scheduling. First of all, what's Nerd Nite and why did you make an API for it? Second, explain how you scraped the data, organized it, and output the results.

The above three questions will give you way more insight into my programming
style and thought process than "What is an MVC?". Please. Don't waste my time.
As a senior engineer with 7+ years in the field, I shouldn't need to prove the
equivalent of my ABCs to you. It should be understood.

I personally would also skip the whole "live coding" thing via Stypi or
whatever. Waste of time, imo. You've already got code samples and you can ask
me as many questions as you want about it. I shouldn't need to write code in
front of you to establish my credentials.

## What about people who lie?

There are people who lie about their resume and their qualifications, but
that's exactly why you should tailor your questions to fit the code samples
provided. If I don't get excited about that code and I can't eloquently
explain why I did what I did or how it works, then maybe I didn't write it
after all. It also gives you an insight as to my personality: I clearly took
time out of my day to write this code. Why? What prompted me to write an API
for Nerd Nite schedules?

The answers to those questions should give you an idea of whether I can
actually program or not. Questions like "What is MVC?" can be looked up in a
dictionary. Explaining code samples is much more difficult.

## What next?

Once you've established that I wrote the code I said I wrote, then Step 1 of
The Interviewing process is mostly done. Now you bring me into the office to
determine Step 2 -- am I someone you want sitting next to you for 8+ hours a
day for the next six months? Do I fit in with company culture?

You could give me a problem to solve on the spot, but hopefully it's more of a
higher level thing rather than a "write code on a whiteboard" thing. The
reason I say this is because at this point you should already have seen my
code. You should know by now that I can build a class. The question you need
to answer now is: given an arbitrary problem, can I solve it or at least come
up with a reasonable thought process?

Bonus points if it's relevant to the job. (i.e., if your job never requires
you to write binary trees from scratch, don't ask the applicant to do so.)

## Finally

Between the phone screen (technical) and in-person interview (personal), you
should have a good idea of whether you want me on your team or not.

Occasionally for small teams, you may decide that you need to know something
about time, creativity, independence, and other similar qualities that you
can't really get from code samples. If this is the case, then I suggest doing
the contract thing, where you give them an assignment on contract. Once the
assignment is finished, you hire them or pay them for the work completed (or
hopefully both).

I really, really, really despise whiteboard coding. I don't think it's
indicative of anything, and I think you will find a lot of false negatives
(i.e., rule out good candidates) using the whiteboard method.

A few other thoughts:

* I should meet my potential future boss at the in-person interview

* I should meet at least one of my potential future coworkers

* Be respectful of my time. Most interviews take place during work hours, so I've taken time off work -- and probably lied to my boss about where I'm going! -- to meet with you. The least you can do is not waste my time.

* Be familiar with my resume and code samples. I took the time to write them, you should take the time to read them. It will answer way more questions about my abilities than a 20 minute quiz on technical terms will.

The more informal the in-person interview is, the better. The technical
qualifications should already be accepted by the time I walk in the door. At
this point, it's a two way street as we figure out whether we want to work
together. I'm interviewing you just as much as you are interviewing me.

(Note: These are just my opinions about how I interview others. It hasn't
failed me yet. On the other hand, almost every job I've ever interviewed for
has completely wasted my time on that front.)

~~~
lquist
_As a senior engineer with 7+ years in the field, I shouldn 't need to prove
the equivalent of my ABCs to you. It should be understood._

You'd be surprised how many 'senior' engineers can't code their way out of a
cardboard box.

Background: I've interviewed hundreds (if not thousands) of engineers.

~~~
pedalpete
I'm always curious about the senior engineers who "can't code their way out of
a cardboard box". I often wonder if I'm one of those, or come across as one of
those.

Can you give an example of something you've seen. I just keep hearing about
people who can't do fizzbuzz, but how bad are people really? Or what is it
that makes these engineers so bad? How have they lasted in the industry?

~~~
rjzzleep
they're really bad. i interviewed people that couldn't fill in a simple
fizzbuzz after defining a function body and return type for them. they last
because they can last, a lot of these jobs really just require codemonkeys. I
have seen if states literally hundreds of words long made by these kinds of
people.

that said i feel you. tbh, i have managed to impress anyone i worked with.
most were people i met at hackathons, people that wanted to bootstrap their
startups or general referals. on the other hand I failed most interviews i
took(with a few noteworthy exceptions)

It once took me until after the interview to figure out that the guy just
wanted to find out whether i understand how variable scopes work.

A lot of interview questions are questionable at best, and most code
challenges are even worse. they're exactly how universities teach programming.
The only problem is that universities suck at teaching programming. I know a
lot of really awesome people that went to university because they thought
knowing the topic they study was a good idea, but it turned out to be the
opposite.

But one lady once asked me is there a special command to find out where
traffic goes? I said route. Is there any special flag you would use she
continued. But what she wanted was to hear route -n.

I'm pretty sure in those kinds of interviews they think i'm an idiot

------
sgustard
As the last round of a 3-hour interview I met the engineering manager whose
first question was, "Do you know Perl?" and I said no and he said "Sorry, we
need someone who knows Perl" and sent me home. After 3 hours of wasting my
time! Not naming names, but Screw you and burn in hell for eternity SAP!

------
yeukhon
Please allow googling in an interview. How many people today actually write
code without a Google search? I bet 90% of the Google engineers do that and
still able to write really brilliant code.

~~~
billnguyen
Love this! Was in a coding interview once where they just gave you a problem
and you were given laptop and time to code out a solution using whatever you
would normally use ie stack overflow. First interview I've had where I felt
like it was a fair test of my programming capabilities.

Of course this requires that you design the question in a way that is not
completely google-able, but real world programming is not just about solving a
trick question but being able to be resourceful enough to find a real working
solution.

~~~
yeukhon
I guess I should say restricted gooling. I like take home interviews. It's
harder because you are given more time and more personal space and psychology
tells us we will try to design the best algorithm, the most scalable, yet
complex solution. If I were to conduct such interview, such solution can be a
red flag.

But you know, interview is hard. I also think interview questions don't have
to change a lot. I heard Box always asks people to design an evaluator. I
thought that wasn't so hard but when I started thinking about an evaluator, I
started getting distracted by all the cases, even when I wanted to just
implement a state diagram.

------
kabdib
I had an interesting question once: They gave me a whiteboard problem that I'd
studied about a week ago.

So I told them. "Look, I did this problem on my own a little while ago." They
chuckled and made it harder, which was fine. :-)

~~~
bcjordan
That's definitely the way to go. If you try to "remember" an answer you read
or even previously completed while in an interview there's a good chance you
won't instantly recall the answer and often the problem is slightly adjusted
from your first encounter. It makes it difficult to see the problem with new
eyes
[http://lesswrong.com/lw/k7/original_seeing/](http://lesswrong.com/lw/k7/original_seeing/)

There are some serious benefits to bringing up your prior exposure to a
question in a positive light. When sending out problems interviewees are
likely to encounter again I include the group's "déjà vu guide"
[http://codingforinterviews.com/seen-question-
before](http://codingforinterviews.com/seen-question-before)

------
bastiaanus
I am at the "write a function that reverses a string without creating a new
string" question and this is the answer on the site:

    
    
      def reverse(str):
        left_ptr = 0
        right_ptr = len(str) - 1
        middle = len(str) / 2
        while left_ptr <= middle:
            # swap
            temp = str[left_ptr]
            str[left_ptr] = str[right_ptr]
            str[right_ptr]= temp
    

wouldn't this create an infinite loop? You're never incrementing /
decrementing left_ptr or right_ptr.

~~~
beat
I see that and want to do it by appending backwards off the end of the string,
then move the pointer to the new beginning. Is that "creating a new string"?
Or just making a poopy on the floor for the garbage collector?

"Double the length of the old string and then cut it in half" isn't against
the rules, right?

~~~
bastiaanus
I don't know if it is against the rules, my approach was a recursive function.

------
buildit
Nice site, could not do the practise questions though since I am not member of
any of the social sites needed. Suggeting the option to proceed without the
saving feature.

------
ChikkaChiChi
Any time I've been a part of hiring new talent, I'm looking at three things:

1\. How you process information. I'm not going to be impressed if someone at
the table says 'Microsoft' and you cringe. 2\. Can you admit to not knowing
everything? You'd be shocked how big of an issue this is. 3\. Are you willing
to adapt? In a smaller team, you have to bend and be willing to take on new
challenges.

------
bcjordan
This is a really comprehensive list of tips, thanks Parker!

Definitely including this in next week's Coding for Interviews newsletter.

------
Fede_V
That was very useful, thanks. All pragmatic, useful advice and no generic bs.

Edit: Annoying that you cannot try practice questions without logging in
though.

------
umsm
The key point from the article: Communicate well.

This is really very true in the corporate world. The better you know how to
communicate, the more likely it is that you will succeed in your chosen
profession.

------
Pirate-of-SV
For [http://www.interviewcake.com/question/largest-
stack](http://www.interviewcake.com/question/largest-stack)

There's a simple solution that requires no additional space.

Disclaimer: Code is not tested or given the love it deserves.

    
    
        Class Item():
            def __init__(value):
                self.value = value
                self.next = None
                self.next_largest = None
    
    
        Class maxStack():
            def __init__():
                self.top = None
                self.largest = None
        
            def push(value):
                i = Item(value)
                i.next = self.top
                self.top = i
                if value >= self.largest:
                    i.next_largest = self.largest
                    self.largest = i
        
            def pop():
                v = self.top.value
                if self.largest == self.top:
                    self.largest = self.largest.next_largest
                self.top = self.top.next
                return v
        
            def getLargest():
                return self.largest

~~~
anonymoushn
This solution takes O(n) additional space...

------
dhammack
Just as a heads up, after I finish an interview question neither button works
(I'm an expert or review later). Clicking on each doesn't seem to do anything.
The only way for me to see additional questions is to head back to the
homepage and re-click 'run some practice questions.'

~~~
gameguy43
Thanks for the report! Having trouble reproducing on my end ... are you logged
in?

~~~
dhammack
Yes, I am. Here's what shows up in the dev console when I click "I'm an
expert"

PUT
[http://www.interviewcake.com/api/v1/viewings/](http://www.interviewcake.com/api/v1/viewings/)
403

(FORBIDDEN) angular.min.js:99

(anonymous function) angular.min.js:99

n angular.min.js:95

l angular.min.js:94

DjangoRESTResource.(anonymous function) angular-django-rest-

resource.js:12

DjangoRESTResource.(anonymous function) angular-django-rest-

resource.js:18

$scope.updateViewing base.js:31

$scope.markAsComfortable base.js:13

$scope.feelExpertPress base.js:15

(anonymous function) angular.min.js:72

(anonymous function) angular.min.js:144

e.$eval angular.min.js:88

e.$apply angular.min.js:88

(anonymous function) angular.min.js:144

x.event.dispatch jquery.js:5095

v.handle

~~~
gameguy43
Got it. Digging into this now. Meantime, you might try another auth method?
There's also this secret page to walk through the questions by hand:
[http://www.interviewcake.com/all-questions](http://www.interviewcake.com/all-
questions)

Sorry about that!

------
yixizhang
Nice article, but not that good site design. Not to mention the solutions for
most of its problem are either flawed or fundamentally not correct.

Author of the site wrote solutions in Python, but obviously he/she doesn't
understand Python. Isn't that against what the article suggested?

------
kevinpet
Doesn't look like there's a whole lot of coding in that coding interview.
Apparently the article assumes that "coding interview" involves a whiteboard,
rather than a keyboard.

We segment our interviewing into different sections. One person will do a
specific functional competency evaluation which consists of writing code in an
IDE to see whether you can write code. This portion of the interview is not
about analytical thinking skills, people skills, or "tell me about a problem
you've solved". It's about writing code. The interviewer is looking to see how
many hints you need to get at working code, how well your solution is
structured, and getting an overall feel for how you program.

------
bcbrown
> Leave yourself plenty of room. You may need to add code or notes in between
> lines later. Start at the top of the board and leave a blank line between
> each line.

That's a good idea I'll adopt. It looks messy when you start trying to
shoehorn in a missed line somewhere.

~~~
smtddr
This is why I wish all programming interviews would just put me in-front of an
Ubuntu machine and let me start up vim.

Also, someone should develop a vim & emacs clone with super big font so it'd
be good on a big-screen for coding-interviews.

~~~
johncoltrane
You can change the font size.

------
triplesec
This reads even better as a "how to be a more insightful and incisive thinker
and presenter", and anyone who just wants to use this excellent advice for
interviews is missing the point!

------
loblawslawblog
Also found this book helpful for more practice questions & solutions:
[http://interviewsolutionsmanual.com/](http://interviewsolutionsmanual.com/)

------
dancecodes
I think if you offer to code in interview its not right and dont resume good
Man and company lost cool thinking programmer. In root its going from escape
from peoples - such company not need with anybody. They must offer not coding,
the must offer work and good things. Programming solve not coding it solve to
make effective and easy. Coding in interview is monkey fun.

------
aidos
I'm just glad I work in python mostly and no longer have to deal with off by
one errors...

------
known
quiz != interview

------
zachmokahn
This is aweasome

------
shawiz
Congrats!

