How to Pass a Programming Interview • Hacker News Board

Re: How to Pass a Programming Interview

#451

Post by quanticle » Wed, Mar 09, 2016, 7:30 AM UTC

shasta wrote: post #364

Cakez0r wrote: post #335

Earlier quoted context omitted.

It's not so much specifically about the moving average problem. I would want to see that a candidate can reason about the performance of some code / algorithm. I would not expect them to be able to recite the performance for specific algorithms from memory, however.

I agree, but I suspect "recite" was editorializing by the parent.

It wasn't. I was literally asked, "What is the time complexity of the moving window average algorithm over an array?" and when I asked for clarification, I could hear an edge of... I guess frustration in my interviewer's voice.

Granted, by this time, we'd been through a couple of other problems, and time was running short, but I still think it was pretty unprofessional of the interviewer to let frustration or any other sort of negative emotion show during the interview. That, more than anything else, contributed to my own frustration and perception of unfairness in the entire interview process.

Re: How to Pass a Programming Interview

#452

Post by pjmlp » Wed, Mar 09, 2016, 7:44 AM UTC

kamaal wrote: post #338

kafkaesq wrote: post #266

Earlier quoted context omitted.

Now they also tell you that it's OK if you don't finish the project. Yeah, they always say that -- but it's never really true. They should just be honest and say "If you don't finish the project in time -- then don't feel bad, but perhaps the test isn't right for you, at this time. Feel free to apply again in 6 months."

>>Feel free to apply again in 6 months. I don't understand this. No company is so special that I would be throwing away hundreds of hours in pointless meaningless work every few months just to join them! Unless I'm in need of a job again. And whats the big deal even if I join them after six months, I'd be working to maintain some code, fix bugs and may be occasionally do a big important project. Its not like they are…

Me neither, it is like some companies like to feel special.

After being invited twice for Google interviews, I mean really invited by their HR, not me applying for them. On both occasions I failed the process with their stupid questions.

I started replying to their HR, if I am so good to be invited but on their eyes unable to devise a inode search algorithm for unlimited hard disk sizes with a specific set of hardware and search time constraints, over the phone interview, then why couldn't they just please stop inviting me!?

That was the last time I heard from them and I don't care a bit about it.

Re: How to Pass a Programming Interview

#453

Post by democracy » Wed, Mar 09, 2016, 7:45 AM UTC

jerf wrote: post #384

tomjen3 wrote: post #197

Earlier quoted context omitted.

What if it isn't stupid code? What if it is straight forward and simple and looks correct but is just slow because it has to traverse a list instead of using a hash-table or some other data-structure. You can't get there by intermediate steps, you have to rip out the code that uses it and rewrite it with a hashmap. You can only do that if you know the space complexity and when a hash and a list is appropriate.

"You can only do that if you know the space complexity and when a hash and a list is appropriate." You seem to be confusing "knows how to say 'oh of enn squared'" with "the loop gets slow when I iterate over a lot of things". One is generally a product of education, the other, merely experience. The idea that a thing can only be learned in a classroom is perhaps in the top ten most pernicious ideas in the modern worl…

My thoughts exactly, a bit suprised seeing it on HN

Re: How to Pass a Programming Interview

#454

Post by tarpherder » Wed, Mar 09, 2016, 8:06 AM UTC

sgift wrote: post #442

rockshassa wrote: post #434

Earlier quoted context omitted.

Take-home projects can be a double edged sword... for a given project that is estimated to take 4 hrs, i will typically spend about 16 hours on it. working straight through the night, chugging coffee and/or beer. I work by banging out an ugly PoC, and then I refine it drastically over several iterations. My final versions are award-worthy, but the early ones are really bad and sloppy. I am the type that is great at s…

Ignoring the time investment for a moment: That is not a bad approach in my experience. Iterating allows you to learn from the versions before and guide your improvements. As long as the first version is at least good enough to do the job AND good enough to be improved upon (often the harder part) it is absolutely fine.

The only problem with her/his approach is that she/he said it took 16 hours where they would've liked to only spend 4 and be done (as 4 hours was what was expected). 4 hours may be unrealistic for what was delivered in the end but it would make me feel at least slightly awkward putting 16 hours into a 4 hour assignment as it indicates my performance is not where it should be (I'm off x4 which would be a lot to me) or my priorities are not at all aligned with the company's regarding this assignment.

Don't get me wrong everyone takes whatever time she/he needs and comparing results and time spent is hard unless you only look at "does it work" which in many cases does not do the work justice (and may not even be the most important metric in the long run). For that reason take-home assignments may be better than the almost comical interview often described on HN but they have their flaws that make them far from ideal as well!

I think it is hard to judge the true performance of a potential employee in a company team without actually having the candidate be part of the team (and even then it'll take a good amount time before someone settles in). Some folk may not be the best programmers but are good catalysts in a team, smoothing relations between other colleagues and increasing team output overall. Or they might have a habit of happily taking up tasks that are wildly unpopular and thereby, even if they are not the most performant, solving problems colleagues or perhaps a faster candidate wouldn't have solved. I could go on about this but I think it's clear what I mean.

There is a lot more to a role as programmer than just programming and that is often completely neglected in these discussions.

Re: How to Pass a Programming Interview

#455

Post by sarchila » Wed, Mar 09, 2016, 8:15 AM UTC

aprdm wrote: post #265

I've been interviewing in the past month as I need to find a new role and it is just crazy. It is SO random, a lot of useless questions, small startups having a long hiring process harder than the big 4. Just one example: I've received an offer from one of the big 4 after going through their process. I was lucky in the questions - things I had studied. I also applied for around 40 start ups / small companies. I made…

Perhaps the smaller/scrappier startups are trying to have more rigorous processes because small startups don't have as much resources to train new hires when compared to 'big 4' companies, so they really need engineers that can do it all themselves, quickly and under-pressure. They also may be more risk-averse when it comes to false-positives, because if your entire engineering team is 5-10 people, you're much less likely to be able to afford to get it wrong and hire someone that won't end up working out.

Re: How to Pass a Programming Interview

#456

Post by rattray » Wed, Mar 09, 2016, 8:19 AM UTC

staunch wrote: post #206

runT1ME wrote: post #158

Earlier quoted context omitted.

I don't know what other industry you have experience in, but this is fantastic compared to the rest of the world. In 'soft skill' jobs, I'd bet the house that credentials, prestige, and 'reputation' end up doing a lot more than a 30% higher acceptance rate. Should we improve it further? Absolutely, but to pretend that this isn't better than other industries is silly.

I've worked for LA and NY companies (among others) and never seen anything like the elitism that exists in Silicon Valley. Silicon Valley is mostly funded by a few elite institutions, so it shouldn't be a surprise that they fund elite VCs, which then fund elite founders (and hire elite employees). The funding sources in LA and NY are much larger and more diverse, so the elitism is far more diluted. It's a market oppo…

Are you talking about tech startups or other firms?

Re: How to Pass a Programming Interview

#457

Post by fibo » Wed, Mar 09, 2016, 8:19 AM UTC

Good article. Anyway, I am also disappointed with many interview processes. Sometimes I think there are courses or books about how to hire that spread a particular concept or practice that is common in some period.

Re: How to Pass a Programming Interview

#458

Post by kriro » Wed, Mar 09, 2016, 8:30 AM UTC

nevon wrote: post #440

kylequest wrote: post #419

Earlier quoted context omitted.

> At least in the traditional technical interview, interviewers and candidates tend to be roughly equally invested in the interview process in terms of time spent Not really true unless you go to your interviews completely unprepared :-)

As the interviewer, I'm not going to show up unprepared either. Typically, having an interview means learning about the candidate and what would be interesting to talk to them about, learning what team they might be a good fit for and what they need, and syncing with the other interviewers to make sure we're on the same page. And then afterwards, we'll meet up to discuss how the interviewee did and whether or not we…

Since the article seems to be about startup interviews an hour of prep time from the employer's side actually seems fairly low. I'd expect closer to a full day. Isn't hiring one of the most important strategic decisions for a startup?

Re: How to Pass a Programming Interview

#459

Post by m4tthumphrey » Wed, Mar 09, 2016, 8:31 AM UTC

When I interview candidates I sit with them for half an hour or so to get to know them. Then I give them purposely broken, poorly written piece of code which I tell them to pull apart. This proves incredibly effective as even if they miss some of the more obvious errors I can at least point them in that area and then see if they can see the problem on their own. There are about 100 different things to talk about so it really gives me an idea of the level they are at, and also the type of programmer they are; passionate, lazy, smart, meticulous, inexperienced, confident etc.

Then if I feel they are worth a second interview, I get them back to sit with me and my team for the day to see how they fit in with the team. Then all being well I offer the job.

Re: How to Pass a Programming Interview

#460

Post by spike021 » Wed, Mar 09, 2016, 8:33 AM UTC

soham wrote: post #261

staunch wrote: post #108

> candidates who have worked at a top company or studied at a top school go on to pass interviews at a 30% higher rate than programmers who don’t have these credentials (for a given level of performance on our credential-blind screen). Welcome to Silicon Valley meritocracy. And it's much worse for founders seeking investment, where there are no hard skills to test at all. It's almost purely about being the same class…

Problem is, that there just isn't enough time to evaluate everyone who applies. In my last job, I was a Director of Engineering at Box. Every job post we put up, had hundreds of applicants (thanks to job-boards which let candidates apply to jobs like putting in a shopping cart). What do you think we, as hiring managers, are going to do at that point? We'll have to start forming biases. And if we have to start forming…

By forming biases where applicants from "good" schools/companies, wouldn't you wind up losing out on plenty of potential hires that could actually be better?

I don't go to a top school, but I've spoken with students in similar degree programs who don't do nearly as much as me outside of class to learn. In some cases, my breadth (and depth in some cases) of skills and knowledge surpass what those students have and know.

It would seem unfair to give them a pass simply because they had the chance to go to a "better" school.

Not to judge, but just an honest opinion.