Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

481–490 of 570 posts

Re: How to Pass a Programming Interview

#481
Given that none of the most popular dynamic languages know how a good hash table should be implemented with dozens of half-way experienced programmers over many years, and most of them would not be able to write a proper binary search, these questions are certainly too hard for a jobseeker. Those languages still survived with improper implementations for decades. So will TripleByte.

A good programmer must be able to survive mediocre colleagues and terrible managers. How to check for that in an interview?

Re: How to Pass a Programming Interview

#482

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…

Coding interviews are very stressful, and churn through a lot of really awesome potential hires. I imagine there are tons of false negatives, but it's nearly impossible for a terrible programmer to get through a gauntlet of programming interviews. However, I agree. They don't give a full picture of a developer's abilities. As a developer, I prefer take-home projects. As an interviewer, I prefer a few coding interview…

As an interviewer I only look at the resume and published open source projects the candidate did. Everything else just a random impression, nothing serious to bother. The questions are for something else.

Re: How to Pass a Programming Interview

#483
post #442

Earlier quoted context omitted.

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…

> [...] 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 companies are trying to answer this issue by signing a potential employee on for a 2 week "trial," where they hopefully get paid. The trouble there is figuring out how long a trial really needs to be to get a good idea of how that person works and fits in with the team -- too little and it's still a crap shoot, too much and you've already essentially hired them.

In the meantime, test trial runs only work for developers currently out of a job; how do I skip my current gig for 2 weeks to go sit at a potential new employer's office? I certainly have no safety in quitting to go do it since I may get dropped after that two weeks, and there's only so much vacation you can take before you run out of personal time.

Re: How to Pass a Programming Interview

#484

Earlier quoted context omitted.

I personally also prefer take-home projects over being grilled on my ability to solve obscure algorithms problems under pressure. However, this second route also comes with a number of issues. The most annoying of which in my experience is the amount of time investment each interview requires from the candidate. At least in the traditional technical interview, interviewers and candidates tend to be roughly equally in…

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…

As somebody who regularly employs developers, and being a developer myself, may I suggest you put your Saturdays' effort into an open source github repo or something similar? Sure, this takes time too, but afterwards you can just point your prospective employer to your superbly styled and documented code on github. Both parties win: you don't have to spend time on stupid exercises anymore, they can get a very decent impression of your coding skills.

[Edit: corrected typo]

Re: How to Pass a Programming Interview

#485

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…

This is a general problem:

  > Being a good president has a surprisingly small role in
  > being elected president.

Re: How to Pass a Programming Interview

#486

Earlier quoted context omitted.

It is widely believed that if you are able to do deep engineering you should also be able to get the basics right. It takes a lot of time evaluate a real world project and most of applicants would not agree to do one anyway, so basic CS is the easy approximation.

Yet it is certainly false that if you are able to get CS basics right, you will be any good at deep engineering.

I hope you mean that:

It is certainly false that if you are able to get CS basics right, you will NECESSARILY be any good at deep engineering.

There are people who get the basics right and are good at deep engineering. The question is whether one predicts the other.

Re: How to Pass a Programming Interview

#487
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.

Nice! Worth doing these things even if to personally experience the boundaries of good/bad interview practice.

Re: How to Pass a Programming Interview

#488

Earlier quoted context omitted.

Ah. I just provide all my answers in an obscure language they won't know, but has lots of "nerd-cred", so they feel uncomfortable questioning it. Like OCaml, Erlang, or Haskell. Then in the rare case they question it, which usually goes something like, "Can you do it in Java? We don't use whatever language it is you're using there." I respond with, "Oh, will I be spending a lot of time at this job coming up on-the-fl…

> Which finally ends the conversation with me saying, "Well then you asked me to solve an irrelevant problem, so I'm happily providing you an irrelevant answer." So how many of those companies made an offer?

3 out of 5 where it's come down to that kind of bizarro pissing contest.

Re: How to Pass a Programming Interview

#489
post #391
post #74

Earlier quoted context omitted.

You can always preempt the whiteboard issue by bringing a laptop along. "Hey, I'm a lot more comfortable writing code on a keyboard and with an IDE. Lets program this together in a text editor instead of a whiteboard".

That's a double edged sword. Now, your code has to compile...

Ok, but being effective at getting it to do that is an actual thing that every programmer has to do all the time.

Re: How to Pass a Programming Interview

#490
post #462

Earlier quoted context omitted.

Yes, I got one recently: Pull down this data from Instagram API and create a tagcloud. Should only take a couple of hours. Except working out how to register and authenticate Instagram's API took me over two hours, than after faffing about with it I realized I only had some sandboxed version that returned metadata and not the actual data I was looking for. The task would probably only take a couple of hours if the wh…

I have never used the Instagram API and had to look up what a tagcloud is just now. I can immediately say this will take more than 'a couple of hours', whenever I work with a new API it takes time to setup the environment, digest how it works and research the appropriate APIs I need to use. I am not surprised by your experience. Actually makes me angry that someone thinks a reasonable person could do that in two hour…

This seems to happen on around 50% of the take home tests that I have been given. Funnily enough I only take the time to do 50% of them.

Hackerrank is even worse. They have strange ways of wording the questions. I have to Google around to work out how to use their input and output (I work with databases all day long, not reading and writing to STDIN/ STDOUT). No step through debugger (which makes a lot of sense for the algorithmic type questions they ask). Cut and paste only works in some browsers.

No one expects you to set up a database and connect to it in that sort of timeframe - yet I would probably manage it better as I do it regularly.

Post reply on HN