Live data from Hacker News

How to Pass a Programming Interview

blog.triplebyte.com

491–500 of 570 posts

Re: How to Pass a Programming Interview

#491
post #470
post #298

Earlier quoted context omitted.

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

I think another reason is a fear of starting an endless argument with the candidate, when candidate believes he was actually right and the company made the decision already so it's rather pointless. Not sure how likely is it happen though.

True I could EASILY see that happening. I think the important point is to provide the feedback then stop communication (unless it's like a simple thank you or maybe some clarification you could give them or something). Arguing back and forth with an employer who already made the hiring decision isn't going to help things but it's hard not to be defensive if you think someone is wrong.

Re: How to Pass a Programming Interview

#492
post #412

Earlier quoted context omitted.

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

That has a lot more to do with mechanical sympathy, and awareness of when you've exchanged cleverness for complexity disguised as cleverness, than it does with knowing the big-O of operations on a datastructure.

What you want the person to identify is that they've made your simple iterative checkout process into multiple unbounded tree traversals with no circuit breaker.

Knowing that searching the tree is O(log(n)) isn't very helpful when your problem is an inability to identify that you've made (n) an unnecessarily huge problem space.

Re: How to Pass a Programming Interview

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

You can't ask a candidate how long it took, they have no incentive for truth here. Either they say it took all night and you think poorly of them, or it really did take a few hours.

You have to ask someone with no skin in the game.

Re: How to Pass a Programming Interview

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

You are begging for people to lie to you.

Re: How to Pass a Programming Interview

#495

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…

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.

Re: How to Pass a Programming Interview

#496

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 have a theory: I think the coding skills of a programmer are function of the number of programs he's written - from scratch.

Re: How to Pass a Programming Interview

#497

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…

Add them to your portfolio and showcase them. Not a waste.

Re: How to Pass a Programming Interview

#498
I had an interview some years ago which demanded a difficult CS problem to be solved and besides coding the offer stated that you should happily accept being helpful with the IT needs of the marketing guys installing their Antivirus, email...

Re: How to Pass a Programming Interview

#499
post #139

Earlier quoted context omitted.

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

I would recommend going through some undergrad CS datastructures and algorithms lectures to any self taught programmer. My process of reading code improved dramatically. And the big O concept is, once you wrap your head around it, an intuitive way to think about speed. Also once you've timed your code and found the slow bits you need to know how to speed it up, not all speed ups are as simple as unnesting loops.

Same here. last week I was sent a Codility test, tried the demo and failed miserably.

Then I noticed the test was expressing constraints using time/space complexity, concepts I was completely unaware about for my previous 15+ years in the profession.

So now I am reading about algorithm theory face-palming at the realization I have reinvented the wheel many times during my career instead of just re-using a PhD. researched algorithm.

Re: How to Pass a Programming Interview

#500
post #364

Earlier quoted context omitted.

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

Right, but "recite" was editorializing. That implies that the interviewer expected you to produce the answer from memory, as opposed to thinking about it. It's an easy question if you're familiar with moving window averages and know what the interviewer intends. If it was asked apropos of nothing, a request for context seems reasonable, though. It sounds like you probably had a bad interviewer. There seems to be no shortage of software interviewers lacking in "people skills."
Post reply on HN