Hacker News Reader

Comment by eshvk | Hacker News Reader

So I have gathered that these are some of the populations of developers:

1. There is a class of people who will not do algorithmic interviews, who think they are puzzles and not exactly what a programmer does on a day to day basis.

2. There is a class of people who think doing homework assignments makes no sense, especially if you have a full time job and this eats into your evenings.

3. There is another class of programmers who won't work on coding projects because you may potentially be exploited.

For a group of people with highly specialized skills (who get underpaid when compared to lawyers and doctors), we do tend to complain a lot.

View on HN

Well, those of us who don't complain about this stuff don't get heard much.

I think people ought to stop artificially limiting themselves and trying to pick overly-precise categories for themselves. You think algorithmic interviews are puzzles? What exactly is wrong with sitting down and doing some puzzles? Puzzles are fun! Homework assignments are fun! Coding projects are fun! If an interviewer sat me down with a truck and some tools and handed me the maintenance manual and said to me, install a new fuel injector using these materials and we'll see how you do, I'd say, hell yes! Sounds like fun! Tests my ability to think and try something new, too.

Ah, but here's the thing. You can be part of all 3 of those groups (and yummyfajitas' 4th group with no github profile), and still have an easy time picking up work. You just need to have something you can point to.

So we can skip all the above and the developer in question can show you several medium to large web applications running in production, all written entirely by him, some combining to pay his rent, one having won its category (technical achievement) at SXSW.

"There. That's what I can do", he says. "And here's my hourly rate."

No complaining necessary. Get yourself provably good, and all this interview silliness goes away forever.

Individual projects don't show how you work on a team though, nor do they show quality of code unless you submit code samples and those can be and are sometimes faked (taken from an open source project or just not written by them).

Pair programming on the other hand is an excellent way to evaluate how an employee deals with other developers and to get a feel for their quality of code.

Of course as many have suggested in other places in this thread you don't need to do new work. When interviewing candidates myself I like to find a feature/problem from the last 6 months that uses the core job skills I'm looking for and have them work through that. Using current development can feel like free work for them and often doesn't demonstrate the full range of skills you are looking for.

I think it is more than just being underpaid. Doctors, dentists and lawyers do not have to go through such stupid recruiting processes. I've known people to get hired in 15-20 minutes. The assumption is that your education and previous work experience is worth something.

In tech, it feels that one's education and work experience is what gets you the interview. Then, it doesn't matter. I'm tired of hearing the old "developer with 10 years of work experience who can't do fizbuzz". Rather than a lack of competence, the issues are:

1) Most humans can only hold so much information in their head at a given time

2) Tech/dev tool updates move ridiculously fast. It seems they are moving faster as time goes on.

Here's an idea: hire smart people. Even if they don't know your particular stack. Here's another idea that will never happen: lets all agree to be tested for interviews in one tech platform (that'll happen when pigs fly). We dismiss these issues now because we are young and hip. Eventually, many of us will have kids who we want to spend with. That's when we'll be on the other side of the table and have our oh-shit moment. I guess I shouldn't complain about the inevitable.

> I think it is more than just being underpaid. Doctors, dentists and lawyers do not have to go through such stupid recruiting processes. I've known people to get hired in 15-20 minutes. The assumption is that your education and previous work experience is worth something.

This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason.

> Here's an idea: hire smart people. Even if they don't know your particular stack.

What the fuck does smart even mean anyway? How do you find out in the space of 5 one hour interviews if a person is smart or not?

1. If smart means problem solving ability, the way we test it now is a huge crock of shit because it is hard to abstract out domain specific elements from pure problem solving. I mean if you take any Math olympiad book, there are no pure problems beyond the puzzle level, most of them have a few tools of the trade that you can use. I remember someone posting here that IQ tests are illegal and probably not very good.

2. If smart means suave, sophisticated or looks like me (the accepted buzzword is "cultural fit"), it is going to not scale very well.

I've always thought that (in regard with most tasks) being smart would be another way to putting "gets sh*t done." I'm by no means a great programmer (I'm a mathematician and could only stand a CS degree for around a year before deciding most of it was boring and I'd rather get into the interesting stuff on my own) but I can get things done. Sometimes the code is ugly, I forget to add test coverage (or god forbid, error checking!) or it is unnecessarily convoluted. But on the end of the day, it's doing its job. It can be refined later on, and each error check/test coverage problem/non-idiomatic language feature I forget is a lesson for the next project in the same language/stack. I'm smart? Yeah, think so, at least with this narrow-minded definition. In other aspects, I'm not (like when confronted with these interview-like puzzles: I've always hated them, even as math gimmicks.)

See this is where it gets into the realm of being subjective. I used to think that getting shit done was the only prime directive that matter. Until, one fine day I found myself given legacy code written in PHP by some dude who hadn't been in the company for years and years. Suppose you had come by my table during that dark and painful period and asked me if I would hire the dude, I would probably have said no, god no. On the flip side, there is a tradeoff. You can't realistically expect to ship if you expect every module to be pretty as fuck. Again, this is also something you realize with more experience? Are you then smarter? This is kind of getting into theory of the mind territory here.

As with all things, it's a trade-off, and there is a balance somewhere in the middle. i.e. Don't do really dumb things like copy-pasting code everywhere, but also don't feel that every line of code must be a masterpiece. There isn't one rule or paradigm for all situations; you just have to use your best judgment.

As redblackthree says below, there's some leeway in there. I guess it comes down to knowing what tradeoffs are you doing to get it done sooner. In my case I usually know where I've done some cheapish job and mark the code area with a "FIX: explanation of what should be done" for when I have time for that. I also eventually come back and clean up whatever code mess I got, or at least comment the mess so it doesn't come biting back at me in the future.

> This is also true for PhD students and research labs. Like if you are a C.S. PhD student interviewing at Microsoft Research or in an academic position, no one is going to ask you code up insertion sort. They look at your papers and evaluate you. I sometimes regret not doing a PhD for this very reason.

this has not been my experience, lab / academic jobs are a day of interviews which probably will not have any programming questions because you're hiring a scientist, not a staff programmer, but you will talk about research, ideas, and be expected to think and produce insights on the spot, and you as a candidate will give an hourlong talk. the decision is not made before you show up and the desires of the hiring body are very fickle.

>I'm tired of hearing the old "developer with 10 years of work experience who can't do fizbuzz"

Then we need to solve that problem, not bury our heads in the sand and pretend it doesn't exist. When you post a job ad for a software development position, you should receive absolutely no applications from people incapable of fizzbuzz. Yet we the majority of applications we receive are from such people. That problem won't go away if we just say "well, you had a job before, so that's good enough for me!" and hire them.

I know two CS PhDs who would fit into the "can't code FizBuzz" without help. Both are machine learning/stats experts. Both also "code" in MatLab/R all the time.

However, it would take a developer 5 minutes to realize they can't code shit. They are good at other stuff ... sure ... and they shouldn't be applying for programmer jobs.

I think startups are trying to emulate the Google way of hiring and that is to their detriment. There used to be a time where Microsoft hired an MD/PhD to become a coder ... because he had raw intellectual horse power and a desire to learn. I know quite a few PhDs who would love to work for a startup. Most of them have gotten dejected after the interview process. The common complaint I hear is "interview made me think I'm going to be a code monkey. F that. I'll keep my cushy research job with a door on my office".

Don't forget the 4'th group, the class of programmers who refuse to put code on github.

I've gathered there is a population of "developers" who refuse to demonstrate the ability to code at any stage of the interview process.

(The OP is definitely not part of that crowd, given his willingness to submit a pull req to some open source project.)

Really? I am required to have an account with Github, to prove something?

In the real world, some of us work on highly proprietary code bases, where putting any code up online could expose the risk of future lawsuits or prosecutions, certainly this has already happened to individuals in the industry.

Thankfully in the real world there are some sensible and mature interviewers who are able to look beyond the heinous crime of not having a Github presence.

People who can't easily demonstrate their skills are always at a disadvantage relative to people who can.

For every one person who is great but can't publicize any of the good code they write, there are a lot of people who simply suck. Differentiating between them is expensive (read: hours interviewing the good candidate, many more hours interviewing bad candidates) which is why the people with a good github/bitbucket/ftp server full of code are at the top of my list. If they all bomb the interview, maybe I'll move down the list to the people who's skills are unknown.

This simple reality is why one should demand more money from employers who impose restrictions on what one does outside of work.

On the flip side, I have very rarely found an interviewer who has actually read through my github code. It is more like they are scanning through an imaginary checklist of 'has github account, has repositories in it' etc. The other day I got asked by an interviewer if I knew python. This was rather strange to me because we had just talked about one of my github projects ...which was an ml library for python.

My point is that if having a github account becomes a silly barrier like having an education from top school, it kind of defeats the point of being fair whilst also acquiring good people.

tl;dr; If you take a good practice and cargo cult it, you'll get bad results.

When I was the interviewer, the most useful lines to determining competency tended to be find github code, ask pointed questions.

As someone who is now interviewing for a new job. I've had three interviews this week ask pointed questions on github contributions including requests for me to change things on the spot ( or talk through a change that might occur).

Exactly. A lot of work is proprietary and confidential. Should you have a side project to show, sure, if you can do that without getting fired, or worse sued. As a salaried employee, In the past, I have signed employment contracts that basically state they own anything I write. I sure I'm not alone.

Well, I'm in the 4th group, then.

My current job, and every previous development job has clauses about outside development, and what internal hoops have to be jumped through. I'm compensated for that restriction, so I don't mind.

Even lacking those restrictions, contributing to open source projects just isn't really my thing, and my personal projects are just that -- personal, and are usually ugly, hacked together in a hurry and never revisited solutions to specific problems, not resume filler.

If you can't find some way to determine if I'm a good fit without looking at github, having me do unpaid work, or playing trivia games, you need to revise your hiring policies.

Why have we, as a group, allowed the creation of this requirement, official or otherwise, that we have a public portfolio of work we've done on our own time?

Don't be so hard on yourself. Any code that solved a problem is very impressive to an interviewer, showing independent iniative and get-things-done. Even silly seeming things like an AppleScript to copy birthdays from your address book to a text file.

Just because you don't have a Github account, doesn't mean there aren't a plethora of other ways to demonstrate the ability to code with samples etc. Don't conflate no Github account with no ability to demonstrate code.

If you want to be pedantic, I should have a said "a github, bitbucket, gitorious, darcs.net or ftp server full of fortran".

> For a group of people with highly specialized skills (who get underpaid when compared to lawyers and doctors)...

Too broad a brush stroke there. The vast majority of software development does not require highly specialized skills and is more comparable to nurses and paralegals than doctors or lawyers. (Not trying to be disparaging here, either to nurses/paralegals or developers, just running with your analogy.)

You don't think software development itself is a highly specialized skill? It's true that what we type might not be PhD research, but just learning a programming language is a rare thing.

It certainly takes less schooling than doctor or lawyer. Admittedly part of that might be that there are things we can work on of less consequence as we figure things out, so we need a little less prep for a exercising comparably specialized skill. Of course, part of the pay discrepancy is also going to be covering the difference in schooling costs = who spends longer paying off student loans, on average?

Part of that schooling involves intense preparation for tests put forth by the state before you are even legally allowed to perform the work you've been studying for.

That, too.

In my industry (copywriting), candidates demonstrate their abilities to employers with a portfolio of their best work. Would this work for programmers?

You will never see my best work because it's owned by other people.

This is easy because typically your best work is put out in public. This is rather difficult with most company source code. Also copywriting is probably not a team effort.

Reply on news.ycombinator.com