Hacker News new | ask | show | jobs
by nbroyal 4772 days ago
To properly prepare for these interviews you have to invest quite a bit of time. At this point in my life (late 20s), my time is one of my most valuable resources. So, the last thing I want to do is spend that time effectively preparing for a data structures and algorithms exam. Each time I sit down to brush up on the details of Prim's algorithm or the exact implementation of quicksort, my eyes glaze over and I start thinking about how I'd much rather be building or tinkering with something. So that's what I end up doing. The interesting thing is that actually building stuff is good enough to get you an interview, and, even though you've proven that you can actually code, you get funneled through the same inane interview process.

And here's the kicker: none of this truly indicates if you have an exceptional software developer on your hands or not. I've seen (read: personally interviewed) people who've aced the current, en vogue style of questioning who turned out to be awful developers and co-workers. Meanwhile, I know several excellent engineers who were rejected. Everyone knows the process only kind of works.

SV loves to complain about a talent shortage. And maybe there are pipeline problems that need to be addressed. However, why not invest more time in finding a process that's more effective with the talent that's already out there? It always seemed like an obvious place to start, IMO.

6 comments

> Each time I sit down to brush up on the details of Prim's algorithm or the exact implementation of quicksort, my eyes glaze over and I start thinking about how I'd much rather be building or tinkering with something. So that's what I end up doing.

Nailed it.

Another interesting thing I noticed about myself in technical interviews is that I have a lot of trouble doing things that I would have no trouble with if I'm tutoring someone. Perhaps it's the anxiety, and practice will surely help, but see above, I'd rather spend my time tinkering with stuff than preparing for interviews.

>I'd rather spend my time tinkering with stuff than preparing for interviews

If we're talking about raw programming skill, I would say that actually learning these fancy algorithms will pay off more than (random) tinkering. It's the difference between directed and undirected practice. Undirected practice only takes you so far. To truly get good at something one must do deliberate, directed practice consistently.

I agree with you. However, learning the algorithms is different than preparing for technical interviews IMO.

I've learned many algorithms and implemented most of the ones I've learned, but if I haven't recently coded them repeatedly or studied them rigorously, I likely won't be able to code them up on the spot when asked to. But because I learned them in the past, I would be able to recognize which algorithm (from the ones I've learned) best suits the problem.

In rea world programming, those algorithms have very little practical use other than the "gee-whiz" factor.

If you understand algorithms in general, then I think thats enough. Its sort of like being able to play a single song on the guitar is great, but to have the skill to play any song is even better. On the same token, being able to write any algorithm is a much better skill than being able to write out a single algorithm.

Has anybody here ever actually been asked to exactly implement quicksort?
Yes, by Microsoft in 2001. (Strangely, by a non-technical recruiter who wouldn't have known if it were correct or not anyway; apparently he was trying to "gauge my confidence".)
More than once. Also, merge sort, heap sort, and some problem specific variations of these.
quicksort, shellsort, then implement it for parametric type.
I am not even sure what implementing it for a parametric type means... can someone point me to a link?
Parametric type means to take the type as a parameter; parent was probably asked to use Generics in C# or Java or C++ templates.
Ah, ok
I feel exactly the same. I can master any and all graph algorithms under the sun if I want to but why? Just for a job? I would rather be building things.
Adding to that its not ever worth that much trouble.

    1. Master algorithms.
    2. Get a job at <insert a big famous web company>.
    3. ???
    4. Get rich.
What exactly is 3) ???.

Really if you are joining a big company. Whatever that company is. Way to financial safety is not mastering algorithms and data structures. Its more like knowing how to do politics, being your manager yes men etc.

And very rarely are you ever going to get some work where its going to demand some algorithms mastery.

For CS graduates from some big name colleges that go to work on Wall Street or other "finance" it is:

   1. Master algorithms
   2. Get a job at <...X...> & Co.
   3. Use Excel all day everyday
   4. Get rich.
I interviewed at 7 investment banks on Wall Street after college. Never took any of the jobs, however, I had friends who worked on Excel spreadsheets that managed 100s millions in capital. This always amazed me.
They just want smart people in general. CS or not doesn't matter. It still baffles me that they ask algorithms and CS questions then sit in you front to Excel.
The idea is to get in the door. Unfortunately, the bouncer is extremely flawed and often gets it wrong. But once you're in, you should refocus on building things.
I just don't have that much drive to get a job. Maybe I underestimate getting a job at google or similar company.
The only problem with big companies is, no matter who they are on an average large set ups are almost the same. There are some minor variations here and there. But your net experience will converge or move around the same point.

I don't know much about Google. But from whatever I've heard. The awesome projects where all this nirvana level work happens are very difficult to get into and bulk of the work is really maintaining legacy system.

Or in other words, its your usual large company. There is a possibility that the experience is marginally better. But as I said will on a average converge to any large corporate experience.

But they pay way more right ? That has to count for something .
http://jacquesmattheij.com/Programmers+Salaries+at+google+25...

Claims 130 is about average engineer salary at the big G.

Do they? I've heard (I must confess it was years ago) that google paid less. People went there because it was cool and all that hype.
That is why you must contribute what they deserve and nothing extra.
For an entry level job fresh out of college, I'd be interested in seeing a person implement algorithms. For a more experienced job, I'd look for a person who knows that these algorithms exist and can quickly look up the details. For a top level person, I'd look for skills at organizing and dealing with large code bases using best practices.
Exactly! This is why we, at my job, only hire software engineers after a (paid) two-day test period in which they actually build some new feature on one of our products. Nothing too fancy but interesting enough for them to be a challenge and representative enough for us to see what they're capable of. At least as important: they will have lunch with us, talk with us, have fun with the rest of the team, ... This allows us to very rapidly see if a person really fits our team.
How do you cope with people who are presently employed but want to interview? Do you expect them to find two days of absence from their present employer to test themselves at your company?

I mean for me that's no problem, but I don't live in the US and therefore have pretty liberal employee leave arrangements. I know that many companies in the US are a lot harder on giving out leave. That said, it wouldn't surprise me if this issue is minimised in the tech sector with their progressive business approaches.

I've never been in the job market yet (still in school), but I have seen some of the hiring process for teachers at my high school.

For every position they are hiring, there would typically be 2 or 3 candidates who spend the day in the school (including teaching a class).

Is getting 2 days off of work really that difficulty (if you plan far enough in advance)?

Yes it's terrible.

If you work in the US and have kids for which you take any level of responsibility chances are you can barely keep up with a typical schedule and have very little leave to play with. Pulling two days out of your ass for a job interview is almost impossible.

For a sufficiently awesome job, sure.

Correct. I get 4 weeks leave a year plus have flexible working arrangements (1:1 time in lieu if my work schedule e.g.: meetings permits), but that's partly because I'm ex-government (we were privatised) and also because I work in Aus, where 4 weeks is the base standard. Then I get personal leave (illness, caring for ill family, etc.) on top of that.

I know that in the US, it's often less. I've heard friends mention only a handful of days per year for leave, with sometimes needing to take that for 'sick' leave because of such low limits. For them, 2 days off to do a single interview would be impossible.

Obviously they're at the low end of the leave spectrum in the US, but given that the culture there is on the whole more restrictive I wasn't sure how that would affect interviewing.

Yes, people who are currently employed will have to take a few days off for this. As we're in The Netherlands that is usually no problem. One of the reasons we pay people for these two days is to compensate them for the two days off they'll have to sacrifice.
How big is your company? I can't imaging this scaling. This sounds good in theory, but I think one could only hire 1) people currently unemployed or 2) new grads who haven't had jobs. Also, I imagine plenty of good engineers balking at this type of time commitment in building out a feature when the company should likely be proving why the engineer would want to work there?

Is your stack that simple that someone can get up to speed on it in a few minutes so that they can actually build out a feature in two days? Most places I've worked, requires significant onboarding to setup dev machines with all the environments and then understanding how the code flows.

We are a small startup, currently with 11 people. You are right about the scaling issue, I suppose our approach would be more difficult in a large organisation. But why would we only be able to hire unemployed people or new grads? I joined this company myself when coming from another job, as did a colleague that was hired later.

Proving why an engineer would want to work with us is exactly why we interview with this system of two try-out days. How can we possibly convey that we're doing cool stuff in a one hour talk around the table? Besides, we think the try-out is not only for us to "judge" the candidate, it's also the ideal time for the candidate to see if he fits our culture and way of working, and if he actually likes what we're doing. Hiring someone that decides to leave a month later is waste of time for all people involved :-).

Of course we also do the regular "around the table" interview before we invite someone to work with us for two days. We have a chat of about an hour, tell the candidate we will contact him and then have some internal discussion. If everyone agrees we invite the candidate for a two day try-out. If we feel the candidate fits our company and we like his work, we usually try to make him an offer on the second day.

Concerning our stack: it's all Ruby and Rails, and a lot of Amazon Web Services. Our engineers all have at least 3 years of experience with Ruby and Rails (or similar) and we are usually only looking for somewhat experienced people. We simply don't have the time nor the budget to train a new hire for a few months. To get going on a try-out feature a candidate usually only needs Ruby, git, an editor and a small introduction to our codebase from one of the engineers. Most of them are productive within two hours of entering our office on their first try-out day. Of course these try-out features are very isolated and require little to no background knowledge of the entire codebase. Once the candidate is hired we will take sufficient time to get him comfortable with the code.

I forget the exact details but my current employment agreement has a paragraph saying I won't do contract or consulting work while I am a full time employee here.

Ethically, I would never be able to interview for your company. Don't most companies like tech companies operate in a similar manner? If so, aren't you limiting your hiring pool to either programmers without those types of agreements or thise whom are ethically challenged.

Interesting. Many (if not most) of the engineers I met in my earliest jobs were moonlighting. How common is such an anti-moonlighting clause in employment contracts?
Quite common.

But in many cases, unenforceable. For example, every contract I signed (both in the UK and Portugal) have it, and while I don't know for the UK, here in Portugal you can't sign your rights away which this falls under. So people just sign it and know if worst comes, the courts will always side by you.

Legal in the UK I think every contract I have ever signed says no outside work with out clearance from your boss.

You can sign some rights away just not all of them.

It says on the contract, but is it really legal? I'm honestly asking as I mentioned, I know portuguese labour law quite well (my cousin is a lawyer specialising in labour law and as such, she looks over all my contracts and say what is valid or not.) Have you talked with a lawyer about it over there in the UK? I know the UK didn't sign some EU directives about overtime pay for IT workers so they don't fall on the common EU law, but when I was in England, noone I worked with actually knew if the 'outside work' clause was legal. I personally did freelance work (which my leads knew about) and never got any problem for it even though the contract specified I couldn't.
Most companies even try to own your "thoughts" while employed at them, even for your after hours stuff.
I'm not sure, but that sounds unenforceable in the state of California (where a lot of HNers are). If you work outside of California, sucks to be you, I guess.
Interesting point! As far as I know we've never run into this issue. We are in The Netherlands, so perhaps that makes it easier. However, were this ever to become an issue with a particular candidate, I'm sure we are flexible enough to work around that. The two day try-out isn't set in stone, it's just a way for us (and for the candidate) to see if we like each other. There are plenty of other ways to solve that if a try-out poses legal issues.
I totally agree. I happily turn down a company that requires me to do C/C++ exams in the application process. I know my strength, which is coming up with new algorithms, or implementing them straight from a scientific paper, and most often efficiently enough to run on resource-limited robots. I know a lot of languages and technologies, which necessarily means my knowledge of those languages cannot all be in-depth. If I have to implement quicksort for a job interview I am applying for the wrong position. IMHO it's like asking a poet for the number of words (s)he can rhyme with "cat". :-)
If the job your interviewing for requires dealing in algorithms, having your eyes glaze over while you look at quicksort means you're not a good fit. (Really. There are plenty of people who enjoy looking at algorithms and their implementation)

Obvious note: Many jobs _don't_ require those skills, they're simply cargo-culting their interview questions.

In both cases, you've learned something valuable about the potential employer.

Thinking from an employer's perspective, if you cant gather up enough motivation to prepare for the interview process and solve those non-interesting problems, how will you do all the shit work that will inevitably be assigned to you when you get the job?