Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

Post reply on HN
Print view View original

411–420 of 570 posts

Re: How to Pass a Programming Interview

#411

Post by ionforce »

econnors wrote: post #80
LoSboccacc wrote: post #45

Earlier quoted context omitted.

I wouldn't pass then since I live in post 2000 and am used to let the IDE handle the nitty gritty details while I focus on the actual meat of creating software

I've had this problem as well. I go back and forth between Obj-c, python, javascript, matlab etc. so much without spending a significant amount of time on any one language that I often feel intellectually deficient because I don't know the nitty-gritty details of any of them. Curious to see what others think - is this something I should stop and focus on? Or in today's development environment is it considered accepta…

The bad/goodness of your strategy I would measure by your market success or happiness. Do whatever makes you happy and employable.

Personally, I love the idea of being a generalist. But at the end of the day, you gotta code and code good, specialist or not.

Re: How to Pass a Programming Interview

#412

Post by kevan »

mech4bg wrote: post #153
digler999 wrote: post #128

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…

I've seen this plenty of times. I've worked both on a trading platform and a large website, and both times encountered many performance issues that were solved with a more appropriate algorithm or data structure. I've even seen this with a list as small as 10 items - a O(n^3) algorithm was making multiple network calls each time; changing it to O(N) alone made a huge improvement in speed.

Most of my work on an ecommerce platform doesn't need much attention to algorithmic complexity, but everyone on my team still curses the guy who wrote an O(n^4) algorithm in our checkout pipeline (discounts, promos, shipping, tax, etc). More than a couple items in your cart and you couldn't checkout because the thread would spin forever. I want to work with a team of people who can recognize these things immediately, even if it's not an absolute requirement for the job.

Re: How to Pass a Programming Interview

#413

Post by dang »

gedy wrote: post #303
dang wrote: post #287

Earlier quoted context omitted.

We detached this subthread from https://news.ycombinator.com/item?id=11247773 and marked it off-topic.

Okay sure, though how is it off topic?

The subthread turned into a flamewar.

The root comment wasn't off-topic, but it wasn't helpful either, because of the snarky second sentence. It's typical for such a comment to nudge the thread in the wrong direction.

Re: How to Pass a Programming Interview

#414

Post by shawn-butler »

kafkaesq wrote: post #48
jameshart wrote: post #7

Programming interviews aren't pass/fail, they're match/no match. Imagine how it would read if this said "how to pass a first date".

But they're conducted as if they're pass/fail -- quite often before any real (two-way) discussion can take place. Imagine if prospective dates gave you a 4-hour take-home test before making eye contact. That's actually the way many employers like to start of the conversation process with candidates, these days.

That is sort of the premise behind a whole slew of very successful dating apps isnt it?

Spend several hours perfecting a profile to increase your odds?

Re: How to Pass a Programming Interview

#415

Post by eranation »

krackers wrote: post #381
cyphar wrote: post #368

Earlier quoted context omitted.

> >But the hashmap guy might accidentally say it's O(N) memory (common mistake for frequency maps) > Wait why is it O(1) memory for the frequency map? As you keep adding elements doesn't the hashmap have to resize to prevent too many hash collisions? Presumably because you'll have a constant number of keys (I'm not sure what the exact problem he's referring to is).

The problem was to find the only non duplicate number in a list. I'm not sure how you would have a constant number of keys. I mean I guess if you consider a worst-case hash table with bucket for each integer you would have 2^32 keys (which is technically O(1) space since the size remains fixed regardless of list length). But using Big-O in this case is clearly disingenuous since the space allocated is far, far more t…

My bad, I meant for a variant of the question that uses chars and not numbers. With numbers the hashmap will be still constant memory just like you said, but it's a big constant (2^32) - but still O(1) memory. This is because the input is of ints, and it can only be one of ~2^32 numbers for either values or keys. And since we only count the number, we don't need a map, we can just use a set (a map with boolean value true if the element is in the set) we add to the set and remove when we see the element again, the only element left is our non duplicate item. But the max we can have is sizeof(int)/2-1 duplicate numbers + 1 non duplicate, so memory can't be more than a constant.

In the char variant, the worst case number of keys in your hashmap is the total number of chars in Unicode. You can't have more than that no matter how big is the input.

So both cases are a very, very big constant, but still a constant.

Time complexity however is theoretically unbounded as you can have any size of input, but again, this is limited to the max size of an array, so TECHNICALLY the time complexity is an integer in Java at most 2^32 as well.

But I would not risk saying that in an interview, O(1) memory will pass, saying O(1) time because the size will never be longer the the max array length sounds more risky.

if it's an int though, it's an O(1) and O(1) memory if you really want to be technical. So are all interview questions involving an array of integers I guess :)

Re: How to Pass a Programming Interview

#416

Post by dpark »

autarch wrote: post #376
kafkaesq wrote: post #273

Earlier quoted context omitted.

Send out the assignment at a predetermined, convenient time and require it be returned an hour or two later. Except that these places very frequently tend to either (1) misstate the problem in some major or minor way, or (2) wildly underestimate the time required to produce a professional quality, bug-free, bulletproof-tested solution. Which can be easily countered by having one of their own team members sit down and…

> 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…

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.

Re: How to Pass a Programming Interview

#417

Post by greenleafjacob »

jerf wrote: post #151
bshlgrs wrote: post #34

Earlier quoted context omitted.

I also think that it's not obvious that the interviewer is doing the wrong thing here. The claim "good programmers should always think to guard against invalid input" isn't ridiculous on the face of it: maybe checking for valid input is a sign that they're careful and methodical, and of course you want to hire careful and methodical people! Or the other way around: I can imagine someone thinking "this person spent ag…

If you think my code's checking carefully for the validity of the input makes it bloated and ugly, you just failed my interview.

There's a correct place for every class of input validation. The point is that you don't want multiple levels of input validation for the same thing. Most of what passes for "defensive coding" is superfluous. For example, if you are passing a pointer into a function, you don't need to reflexively null check. However, null checks are important.

Re: How to Pass a Programming Interview

#418

Post by huherto »

troels wrote: post #170
alistairSH wrote: post #82

Earlier quoted context omitted.

Ack. I'm not sure how I'd react to that. I interviewed quite a bit last year (on the hiring side). I was really surprised by the variation in pseudocode written by the candidates. Most wrote something JavaScript-like, a few stuck to mostly proper Java or C. But then one dumped a giant web of crazy on the board (but still made his point) and one wrote something that looked suspiciously like COBOL - still not sure if h…

"and one wrote something that looked suspiciously like COBOL - still not sure if he was trolling me." That's brilliant. Now I have to learn myself some COBOL just for that.

You will need to write a lot before you even start solving the problem.

Re: How to Pass a Programming Interview

#419

Post by kylequest »

lewisl9029 wrote: post #144
quanticle wrote: post #72

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…

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…

> 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 :-)

Re: How to Pass a Programming Interview

#420

Post by kylequest »

lewisl9029 wrote: post #144
quanticle wrote: post #72

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…

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…

> 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 :-)

Post reply on HN