Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

521–530 of 570 posts

Re: How to Pass a Programming Interview

#521
post #182
post #29

Earlier quoted context omitted.

It sort of makes sense. If someone knows a language well, they shouldn't have much trouble writing it syntactically correctly on a whiteboard. Especially in languages which have simpler syntax, like Ruby vs eg Scala.

I wouldn't call Ruby's syntax simple. Elegant, yes, but not simple. I'd consider myself a pretty seasoned rubyist, but my IDE catches syntax errors for me all the time.

Agreed. I know Python well and Perl and Java before that. Ruby code still looks unusual to me.

Re: How to Pass a Programming Interview

#522
post #167

Earlier quoted context omitted.

What was their response to this? I think it's perfectly valid to state this, and may even throw the balance of the interviewer/interviewee dynamics but I can also see other people seeing this as obtuse. But pointing out a missing bracket (in a nonconstructive manner) on a whiteboard is pretty obtuse too...

It was the last interview of the day, and I was tired and had already decided I was almost certainly going to decline any offer, if given. So, honestly, I probably said it with a little bit of an edge and that was inappropriate on me. Nevertheless, the interviewer was gracious and replied, "Fair enough" and stopped nitpicking my brackets and semicolons.

I got asked to find the intersection of two squares for a Django cosing job. I pointed out that it had absolutely nothing to do with Django (after getting a solution).

I was told they thought I might be difficult to work with.

Re: How to Pass a Programming Interview

#523
post #416

Earlier quoted context omitted.

Did you do the test blind? i.e. Did someone give you the problem without you knowing/hearing it before? If you wrote the problem, or even heard it before you had to solve it, you had a big leg up on someone who's never heard it.

Fair points. FWIW, we've asked people how long the problem took and they all said it took a few hours, so I think it's the right scope. It really is a fairly easy piece of work.

Actually, I think this whole fear of candidates pervasively lying about time-to-completion is something of a red herring.

(1) It may seem counterintuitive to some, but my own general policy is, when it comes to little stuff ("how long did it take you to do X"), you just have to trust people, to a certain extent. Sure, some people may blatantly or grossly lie. But most likely these people will reveal their slipperiness in other ways, very very quickly.

Meanwhile -- and I think people are quick to overlook this -- playing the "policeman" role in every transaction with the candidate brings substantial negatives. By definition, it's adversarial. And generally there are (nearly always) non-adversarial ways to get the same information about the candidate ("Are they basically honest?") you're looking for. They take creativity (and an ability to read emotions and pick up on other signals), but they're there.

(2) Much bigger -- really, there's no need to sweat about the time to completion at all. Just look at the quality of the code.

It all just comes down to the fact that everything is interconnected: Good people generally turn out good stuff in reasonable amounts of time. When you're looking at good code, there is, I find, an intrinsic aura of ease and comfort which shines through it -- such that you just can't imagine it took them very long to produce it. Everything just flows -- just like it does when you talk to them.

Mediocre (and dishonest) people, on the other hand... never produce good stuff in virtually any amount of time. Sure, they can take the whole weekend to polish off their code... but it will still look bad, or at best, "Meh".

There might be some false positives (or outright frauds) by this approach), but I suspect very few. And those that do slip through, are easy to spot by other means (such as asking them to talk about their solution, for even a couple of seconds).

Re: How to Pass a Programming Interview

#524
post #406

> The good news is that interviewing is a skill that can be learned. When I hear folks complain about programming interviews, I point to that. The month I spend gearing up for coding interviews usually guarantees me a job, that offers at minimum a $10k raise. I consider that a very good use of my time.

There is a problem. (job interview are selecting incompetent people) Ho, but there is a solution to walk around the problem of job interviews being unable to select good developers: so let's avoid investing in being a good developer and fix the problem at hand and just be good at interviews. Problem solved. Brilliant! Are not interviews kind of de facto selecting scammers by giving them an unfair advantage, then? Is…

> There is a problem. (job interview are selecting incompetent people)

Of the developers you hired, how many nailed the interview process, then went on to being classified as a bad developer?

From my experience hiring candidates, the typical software interviews that I have been a part of, tends to produce very few false positives, and instead do produce false negatives.

Re: How to Pass a Programming Interview

#525
post #240

Earlier quoted context omitted.

I don't think that is really a problem. We hire people to do a good job and most of the times kick-ass programmer isn't the best person for the job. At least for a smaller company we need someone who can understand business needs, can communicate better and Add Value . This is a far complex job than implementing red-black trees. Consider this: We need to find the most shared URLs on Facebook in last 24 hours. I can p…

Would the Buzz-sumo programmer be expected to investigate their terms of service too? (Often scraping is prohibited.)

I am just giving an example. For a POC it does not matter much.

Re: How to Pass a Programming Interview

#526

Earlier quoted context omitted.

I've gotten a take home test that took all Saturday. I finally finished it happy with myself and with my work and emailed it in. The response was "thanks, are you ready for the next exercise?" i was like.. um.. I really need to get on with my weekend. This was deferred to the big boss who said "It's ok just do it whenever you have time next" .. ook so that was my next Saturday. Worst part is that after turning that i…

It's just that with the programming tasks that you bring home, the hiring manager isn't wasting the that time with you. With programming tasks that you do during the interview, they are at least wasting the time with you.

+this ... it's exactly why, when I do "favors" for people, my requirement is that they're in the chair next to me... even if they aren't doing anything and are bored as sin... so they understand the time/effort that it takes.

It's generally inappropriate for someone to ask you to do more than a day of work for a take-home hiring exercise.

Re: How to Pass a Programming Interview

#527

Being a good programmer has a surprisingly small role in passing programming interviews. And that just says it all, doesn't it? I agree that interviews should test candidates on certain basic skills, including (time/space) complexity analysis. But do you really learn anything by asking the candidate if they can recite the time complexity of a moving window average algorithm (as I was asked to do by an interviewer yes…

"Being a good programmer has a surprisingly small role in passing programming interviews." "And that just says it all, doesn't it?"

An interview is for both prospective employer and potential employee to meet and find out about each other. If you as a candidate notice something you don't like during the interview (including the interview itself), that already is a valuable information for you, as you already may assume things based on it (like, what kind of people you may find past the in-process interview as they all more or less were filtered in by it). So you can always stop and say "thank you" and walk away without wasting more time. You'll allow yourself to stay longer only when the interview's quality warrants it.

Re: How to Pass a Programming Interview

#528

Earlier quoted context omitted.

> Which can be easily countered by having one of their own team members sit down and take the test first. But of course, none of these places ever do that. At my employer we send out homework exercises, and I personally did the backend developer exercise before we sent it to anyone. I did this specifically to test how long it took. (For the frontend exercise, we didn't have anyone skilled enough on staff to do it, wh…

It took a few hours and "it really was an easy piece of work?" How considerate of you. Who was it an an easy piece of work for, someone with unlimited free time. An unemployed person. What a joke. Any problem is easy when you yourself contrive it. Here's an idea, how about you pay someone for the 3 hours or work you are giving them. Say a lot about you.

The last time I was in the hiring side of the process... I had what I considered a pretty easy assignment... it was for a full-stack JS developer (node). The assignment was to read in an XML file (preferably via an input stream) and write it out to a JSON file of a predetermined object structure.

There were no other limitations put.. "bonus points for stream based input" "bonus points for test cases" ... only a couple people actually delivered a "working" solution (one that ran and outputted anything), none of which had the correct output (one was close enough), and none had any tests.

It was truly something that should take a "skilled" developer a couple hours. And not something that should be entirely alien. To say the least, I was really disappointed with the results. I did the project myself in about 2 hrs, with test cases, 100% code coverage. (before I even gave it out, it was as trivial a challenge as I could come up with for a real world problem).

Why should I have to pay the couple dozen people for their 3 hours, when none delivered a correct solution?

In the end, the person with the closest to correct solution, was the one with the least experience... that person got the job.

Re: How to Pass a Programming Interview

#530

Earlier quoted context omitted.

Is there any reason an interviewer should care about syntax, etc? When I interview, I ask for psuedocode - I don't really care what language the interviewee uses, I do care that they can get their point across.

>> I do care that they can get their point across This is kind of the point, right? Most places I've interviewed are far more interested in your communication skills, logic and thought process than writing perfect code on a whiteboard. Many of my friends have failed to see this is actually the reason they have you write code on a whiteboard.

I hear that interviewers are really interested in seeing how you think and communicate constantly. Yet in my experience, if you solve the problem exactly the way the interviewer is looking for in a reasonable amount of time, you pass 9/10 times. If you don't, you fail.
Post reply on HN