Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

291–300 of 570 posts

Re: How to Pass a Programming Interview

#291
post #139

Earlier quoted context omitted.

> including (time/space) complexity analysis. I think this is one of the most inane things to be asked during an interview. personally, I've never found myself in a situation where I truly needed to choose between a vector/map/list/hashmap. Or had to find the O(x^n) and replace it with O(x^2) Obviously it depends on the application, but many jobs are simply maintenance coding: find bug, fix bug, test fix. Often times…

"Or had to find the O(x^n) and replace it with O(x^2)" The other thing that really seals the deal for me as an inferior interview question is that you don't need to have a clue what O(x^n) is to wrap some code in a simple time call, see that the code you think ought to run in microseconds is running in seconds, by visual inspection notice stupid nested loops, and fix it. Self-taught programmers may not be able to say…

Are you going to profile everything for the entire nearly infinite range of possible input values, including all the pathological cases?

Re: How to Pass a Programming Interview

#292
post #126

"Whiteboard hazing" is the most apt description I've heard it called. Pass the wringer, you can join the club.

Its good to see how people handle stress. You can weed out a lot of crybabies by analyzing their performance under pressure, regardless of whether they produce the "right answer".

you sound like a terrible boss

Re: How to Pass a Programming Interview

#293
post #127

If you have an unbounded abundance of good candidates, it is a different story then when you are a new startup fighting for talent. At highly targeted companies such as Google, Facebook et al, I'm sure that if they have a dryspell of good candidates in a given month (can't think of a reason why), then they revert to things like: "We don't care if you don't get the 'trick' immediately, we'll give you hints" and "we ju…

In Java this prints -4 int [] nums = { 2, -2, 0, 0 }; int dup = findDupe(nums); System.out.println("dup="+dup);

The problem was formulated as to find the only non-duplicate number.

Re: How to Pass a Programming Interview

#294

Earlier quoted context omitted.

Gotta say, this is incredibly discouraging for someone like me.

It should be encouraging because you're being told the truth and being spoken to like an adult for once in your life.

You know, fair point. Far too many people spread the meme that school doesn't matter.

Re: How to Pass a Programming Interview

#295

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."

I've actually been through two interviews where I wasn't expected to finish the project, and I ended up getting the jobs. I think the difference there was it wasn't set up that it's "OK if you don't finish", but that "these requirements were crafted such that we don't expect you to finish".

"These requirements were crafted such that we don't expect you to finish" is exactly how we explain our coding tests to candidates, and it seems to work really well. We actually find that many candidates will spend their own time finishing the project _after_ the interview. Programmers do like a challenge, after all, and nothing says "challenge" like "we don't expect you to finish this".

Re: How to Pass a Programming Interview

#296

Earlier quoted context omitted.

Gotta say, this is incredibly discouraging for someone like me.

On the positive side, no one can stop you from making lots of money using the internet. And if you have something that really takes off, those same investors will line up at your door.

Right, but it's still discouraging to be forever branded a "2nd tier engineer/human/etc" because of where I went to school (unless I get into a good grad school).

Re: How to Pass a Programming Interview

#297
post #15

Earlier quoted context omitted.

If you apply to Triplebyte you don't go through the full interview process at the companies we introduce you to. You skip the technical phone screens (most companies do 1 or 2 hour long phone screens before bringing candidates onsite) and go straight to on-sites. Where we can really save time is focusing on the matching process of candidates to companies. Interviewing is tiring and we find candidates often stop talki…

I don't really see how you are relevant if I still have to go through a technical interview - it still means the interview process takes way too much time and I am better of finding a way around it.

Usually the only way to circumvent the technical phone screens at a company are if you're coming in through a strong referral. That's great if you already have a strong network, not so much if you either don't have personal connections or a resume with the credentials recruiters are trained to look for.

Just focusing on interviewing time, if you're talking to 3 or more companies that's approximately 3 hours of technical phone screens (usually repeating similar problems). With Triplebyte, you interview for 2.5 hours and save 3 (or more as you talk with more companies).

Re: How to Pass a Programming Interview

#298

> This situation is not ideal. Preparing for interviews is work, and forcing programmers to learn skills other than building great software wastes everyone’s time. Companies should improve their interview processes to be less biased by academic CS, memorized facts, and rehearsed interview processes. This is what we’re doing at Triplebyte. Thank you! This is a good write up and just like it concludes it's far from ide…

I totally agree with this. Companies should give (constructive) feedback when they say no. They do not partially out of a fear of being sued, but also because they often don't know really why the reject people. The default state at most companies is rejection. If no one really liked you during the interviews, at most companies this will result in a rejection.

We're doing this differently at Triplebyte. We give everyone we don't work with (who does our final interview) a several hundred word personal email, with an explanation and advice on how we think they can improve.

Re: How to Pass a Programming Interview

#299
post #213

Earlier quoted context omitted.

So, you may be right. Perhaps you're great at telling good programmers from bad. But almost no one does the analysis to really know if this is true (false negatives are the huge unknown). And most interviewers are not as good as you. The consistency between interviewers at the same company is low (we measure this). The consistency between different companies is low. We (interviewers) can do better than this!

I make no claims about false negative results. But I know that people that I've recommended hiring have basic analytical skills, can correctly code a Boolean predicate with a few connectives in it, and aren't confused by linked data structures. It's not a high bar that I set, and that's kind of my point: ask at least some low-bar questions! You can debate all day about how well candidates have done with the hard ques…

I misunderstood you. I think we actually agree about this!

Re: How to Pass a Programming Interview

#300

Interesting article. For a while, we had a non-typical interview strategy: A take-home project. We would give the candidate a week or so to work on a smallish project, the requirements of which we would specify. After they completed the project, we would do a group walkthrough with them. We've hired five engineers over the last three years. For the first two, we did the take-home project. But, then I started to wonde…

I instituted take home tests within my group. We're up front that the interviewee should not spend more than 4 hours on the project and that we don't care if it works.

I am more interested in whether or not I can read the person's code, follow their logic, and if they think about logging, unit testing, etc.

Coding skill, while important, is a very small part of whether or not I am interested in a candidate. Soft skills are a much stronger part of the equation IMO. I could care less if a person can write a recursive function or if they don't know the performance difference between different ways of doing things.

Post reply on HN