
Getting a job in software development: A Reddit discussion round-up - nassosdim
http://www.reddit.com/r/cscareerquestions/comments/n5spv/getting_a_job_in_software_development_a_reddit/
======
akg
If you want a job in software development - do software development. There is
no substitute for coding. I interviewed with Google a little while ago and the
first thing they asked me was "How many hours do you code a day?". That set
the tone for the rest of the interview. CLRS has some very useful information
and by all means, every developer should know it, but using that theory in
practice is what makes the knowledge stick. You find out more idiosyncrasies
and sticking points when you actually build something. If you don't know where
to start, fork a project from github and contribute to it.

~~~
raganwald
Amen. If you want a job playing basketball, you ought to watch a lot of video
of great players. You ought to read a lot of books about training, techniques,
and strategy. You ought to hang out with other basketball players and exchange
tips. You ought to cross-train by lifting weights and running.

But all of that is secondary to _playing a lot of basketball_.

------
dpritchett
Most of the questions and answers seem aimed at college seniors planning for
Google-style Big O cross examination.

For experienced developers it's a bit simpler: build a portfolio, craft a
cashflow-oriented elevator pitch, build a network, and plan ahead for a bit of
buzzword compliance in your desired niche as needed.

~~~
throwaway122011
when you say portfolio do you mean having a github account or a blog or a live
website running? what kinds of projects should I have?

~~~
dpritchett
The goal is to regularly provide proof to both your professional network and
to selected potential employers that you are highly competent and will be a
decided advantage to their organization.

Some people don't know what github is and won't care, others really like live
sites even if they're modest, and still others really just want to see resume
bullet points about dollars saved / created. Eventually you can put all of
that together, but naturally it'll help when your prospective hiring manager
has the same ideals you're demonstrating with your portfolio.

Portfolios are secondary to name recognition and social proof. Let me
reemphasize that sharing your goodwill, your skills, and your successes with
your professional network is probably more valuable than anything else you can
do - develop a local or national reputation as a top gun and work will come to
you as long as you keep your connections warm.

~~~
ftwinnovations
As a small company owner I want to completely endorse this comment. These
"proofs" of a developers skills and technical interest are the hard
requirements I have before conducting any interview. Naturally the "social
proof" is also important but less common and more difficult to attain.

Even tiny personal projects demonstrating ones interest in keeping up with
newer hot technologies like node, redis, backbone, etc mean a lot.

tl;dr Having a set of quality personal projects (github, live, whatever) is
absolutely critical.

------
tycho77
This seems... really simple. Basic algorithms, data structures, and theory
that I learned in second-year comp sci.

Knowledge on these subjects is easy to pick up, taking you a few days of study
at the most. Knowing this stuff doesn't mean you can program for shit (see:
academic coding horror). Best to build a portfolio as dpritchett said, with a
few "lessons I learned from experience when working on this project" anecdotes
ready to go.

That's just personal experience though, and I competed in the ICPC during my
university career so I never worry about the problem solving questions.

~~~
microarchitect
_Knowledge on these subjects is easy to pick up, taking you a few days of
study at the most._

I doubt you can pick up a solid understanding of just the first 15 or so
chapters of CLRS in a few months, let alone days.

~~~
karamazov
Coming from a pure math background, I find CLRS to be very easy to read. YMMV
based on prior experience, but it's not at all unreasonable to learn the
basics in a week or two if you're studying it full-time.

~~~
microarchitect
I'm not talking about "picking up the basics". I doubt that level of knowledge
will get you a job offer from Google.

I'm extremely skeptical about your claim. Just reading through the chapters
will take the better part of a day. Working through the exercises and thinking
about what each of these algorithms will take much longer.

~~~
karamazov
For reference, MIT has two undergrad courses - 6.006 and 6.046 - which use
CLRS, covering about half the book each. An undergrad course at MIT is
expected to take up about 140 hours, including lectures, reading, and
assignments. So, working for 10 hours per day, one could theoretically
complete each course in two weeks.

There are a few other things to consider. One is that it's probably not
necessary to go through all of the material to be able to manage interview-
type questions. (It would obviously be best to undertand CLRS from cover to
cover for the purpose of becoming a better engineer, but that's not what's
under discussion.)

Second, it's really questionable whether someone can effectively work for 10
hours per day on this sort of material. My guess is that people fall into two
categories - those who are not used to algorithmic thinking, and those who
are. People from the first category would not be able to absorb that much new
information that quickly, so for them, what I said is inaccurate. However,
people in the second category would not only be able to process CLRS in large
batches, but would need much less than 140 hours to work through half the
book; someone familiar with the underlying concepts (basic programming,
probability, etc.) and with a background in proofwriting could very well get
through enough information to answer interview questions twice as fast or
faster, so in about a week or less.

~~~
microarchitect
This argument is ridiculous.

I don't doubt your claims about the amount of the work the two courses at MIT
require. However, you're forgetting that for some of those 140 hours you're
being lectured by the top professors in the area. You're unlikely to have a
question that they can't answer. Other parts of those 140 hours are spent
talking with some of the smartest students on the planet. Some more of those
140 hours are spent solving problems carefully designed to maximize
understanding. If you can't figure something out, you have fellow students,
TAs and professors to harass. Somebody studying alone at home doesn't have
this environment.

And then you need to take into account the fact that if you're undergrad at
MIT you're already smarter than 95% or so of the population. Basically, the
takeaway here is that your 70/140 hour number applies to something like 0.1%
of the population under the assumption that they're studying CLRS at home.

You need to see this in context. This is advice for CS undergrads looking for
jobs. This advice is being given out on reddit. Anybody who needs this advice
(and CS undergrads from MIT certainly don't) will not be able to work through
CLRS in a week.

------
steve8918
I recently interviewed a master's student for a job at our company. I asked
him a very traditional question, and then was going to follow up on it with
increasingly more difficult questions to see how deep his knowledge was. I
wasn't out to "get" him at all, I hate interviewers that ask super-hard
questions, I'm more interested in having a good conversation with the person
to try to get a feel for what they really know, not just what they've
memorized.

My question was easy: how would you iterate through a binary search tree.

He immediately asked me "should I do it recursively, or iteratively? Can I use
a stack if I do it iteratively?" It was obvious he had studied for this
question, and he banged out a solution in 2 mins. Iterating through a binary
tree is a bit tricky if you've never done it before, and I wasn't even going
to ask him this, but since he brought it up, I knew he knew the answer. The
fact he could come to an answer immediately only indicated to me that he had
memorized the answer and was essentially gaming the system.

So I asked him an even simpler question: Given a binary search tree, write
code to find a particular value. If you can't find the value, then return me
the next smallest value. For example, if the tree contains 1, 2, 3, and 5, and
I ask for 4, then return 3.

He couldn't answer this, even though it's easier than the previous question.
He had no clue how to solve it, and even worse, he couldn't recognize the
simple bugs in the code, and the fact that he was dereferencing NULL pointers,
etc. So I passed on him.

Personally, I think the best way to advertise for a job is to have a portfolio
of code, as dpritchett says. I'm tired of testing people on whiteboards, and
seeing if they can memorize solutions to every single program on
glassdoor.com. I'd rather just have them point to a github repository, so that
I can see their coding style, and see if they can produce quality code. Having
an indepth conversation about their project, and quizzing them on their code,
to me, is a more real-world determination of whether or not they're a good
programmer.

Then, the onsite interview would be limited to determining if their
personality is a good fit for the team, instead of trying to come up with 10
different variations on "iterate through a binary tree".

~~~
itmag
_So I asked him an even simpler question: Given a binary search tree, write
code to find a particular value. If you can't find the value, then return me
the next smallest value. For example, if the tree contains 1, 2, 3, and 5, and
I ask for 4, then return 3._

Out of curiosity, what is the solution?

I would imagine something like keeping a variable of the highest found value
under 4 and if you don't find 4 then you use this variable.

~~~
kd5bjo
Start at the root of the tree; at each node:

    
    
      - If the node value matches, return it
      - If the node value is too low:
        - If possible, step right and repeat
        - Otherwise, return this node value
      - If the node value is too high:
        - If possible, step left and repeat
        - Otherwise, return the value of this node's predecessor:
          - Walk up until you traverse a right link
          - Return the node's value
          - If you hit the root, the requested value is less than any value in the tree

------
pilgrim689
I love this comment:

" At the end of a whiteboarding interview whenever the interviewer asks "do
you have any questions for me?" I'm always tempted to hand them the marker and
say "Imagine you are given a binary tree with elements containing linked lists
..." "

Have any of you guys ever done this? How did it play out?

~~~
mahyarm
It depends if the interviewer has a sense of humor. Some people are so stuck
up about that kind of thing although.

------
itmag
Comments here seem to be about the importance of demonstrating competence.

While this is of course important, I feel that it's equally important to make
sure you actually _want_ to work in an organization. This means fitting in,
tolerating corp BS/insanity well, being expected to tone down the cowboy
ethos, and appearing productive at all times. In other words, being the oft-
mentioned "team player".

~~~
rhizome
Different sports have different levels of cohesion in their teams. Rugby vs.
American Football, for instance.

------
djb_hackernews
Be careful, some of those reddit threads have terrible information/ advice in
them voted to the top. For instance
[http://www.reddit.com/r/compsci/comments/g9ugs/just_bombed_a...](http://www.reddit.com/r/compsci/comments/g9ugs/just_bombed_an_interview_how_do_i_do_better_next/)

------
kondro
I'm surprised to see information missing on source control, automated testing
and automated deployment.

You'd be surprised how many blank stares you get back from candidates when you
ask questions about the very fundamentals of writing maintainable code in a
team.

------
known
interview != quiz

