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

Python coding interview challenges

github.com

Post reply on HN
Print view View original

171–180 of 252 posts

Re: Python coding interview challenges

#171

Post by Apocryphon »

enraged_camel wrote: post #168
Apocryphon wrote: post #145

Never mind the specifics of the selection process, Silicon Valley's risk-adverse approach to hiring is baffling. Instead of making candidates go through an overly rigorous process, why not embrace California's at-will status and hire and fire often? Employers and employees already view each other with suspicion in terms of loyalty, the former willing to downsize capriciously at any moment, and the latter willing to j…

>>Never mind the specifics of the selection process, Silicon Valley's risk-adverse approach to hiring is baffling. I think it makes perfect sense. A bad developer hire is not just unproductive. They also tend to be a burden on their coworkers and reduce their productivity by asking trivial questions and writing buggy and/or hard to maintain code. With startups the risk is even greater. Think about it: the odds are al…

I've read that rationale, and it makes sense, but it almost makes it sound like the organization is humoring a bad dev without oversight for months upon months until they suddenly realize their inability. Maybe they should spend more time actually running their company instead of interviewing candidates all day.

Re: Python coding interview challenges

#172

Post by plandis »

logfromblammo wrote: post #110
hashkb wrote: post #90

Earlier quoted context omitted.

No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.

Not revealed as a terrible company, perhaps, but as a terrible interviewer. If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries. That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm g…

Ironically enough I was never asked about DFS during my interview but needed it for the first thing I worked on after getting hired.

Re: Python coding interview challenges

#173

Post by kafkaesq »

hashkb wrote: post #90
bigtimeidiot wrote: post #77

Earlier quoted context omitted.

> If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?

No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.

Saying "I don't know depth first search" is fine,

No, it most definitely is not "fine". Even momentarily hesitating on question like "Would you use BFS or DFS in this case?" is more than enough to merit a quick transition to the "Do you have any questions for me?" phase, in many a modern, "As hire As, Bs hire Cs, you know" interview session, these days.

Re: Python coding interview challenges

#174

Post by NTDF9 »

JustSomeNobody wrote: post #160
cauterized wrote: post #27

I see these challenges as a great way for excellent experienced developers to weed out incompetent companies. I'm a kick-ass get-things-done full-stack web engineer. I've never had to deal with one of these sorts of problems in my day to day work; and if I did, I'd just find an existing, tested, stable library that already handled them. A company that needs someone to solve these sorts of problems doesn't want me on…

That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.

>> That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.

Dude, in EE interviews, we just ask them some basic about capacitor and how to use it. We don't ask them to derive the mathematical equations of electrolytic capacitors.

In fact, in most EE interviews, you just use them to solve ONE problem and be done. Nobody questions you know EE stuff once you've solved ONE problem.

In programming interviews, you have to solve MANY problems and interviewers just want to keep finding ways of docking points.

Re: Python coding interview challenges

#175

Post by NTDF9 »

recursive wrote: post #67
wpietri wrote: post #47

Earlier quoted context omitted.

You absolutely can test a candidate with real-world workloads. It takes longer than 15 minutes, though. I have no idea why anybody cares about the 15-minute thing. Each person you hire adds thousands of hours to your available labor. So even if I spend 100 hours finding the right candidate, I'm still way ahead. And the better my working environment is, the lower my turnover, in which case I can spend even more.

And how many candidates do you have to consider to find the right one? And what proportion of the interviewer's time is spent on the live coding interview vs setting it up and arranging it? I've been in this boat recently. It doesn't really take much to get to double or even triple digit hours if you don't automate something .

Define "right candidate"?

Is right candidate = person who solves algo questions for 5 hours on a whiteboard?

Re: Python coding interview challenges

#176

Post by recursive »

recursive wrote: post #112
riebschlager wrote: post #8

Earlier quoted context omitted.

I'd rather take my chances with a snake than trying to solve "Add two integers without using + or -".

I couldn't resist. add = lambda a, b: add(a ^ b, (a & b)

And if you need to handle negatives:

    def add(a, b):
        while a and b:
            if a ^ b

Re: Python coding interview challenges

#177

Post by kafkaesq »

jorgemf wrote: post #91
bigtimeidiot wrote: post #77

Earlier quoted context omitted.

> If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?

As an engineer you should be able to see the global picture and know other things. Because you wont be able to use something to solve your problem if you don't know it in advance. I mean, you don't need to know the details, but you need to know how things works. For example, you might not need an AVL tree in your daily job, but if one day you need it to use it, you wont be able to notice if you don't know what is an…

... but if one day you need it to use it, you wont be able to notice if you don't know what is an AVL tree and what is its advantages over other trees.

No, what would happen is you'd say to yourself "Hmm, looks like I need a self-balancing tree. Haven't thought about those in N years..." and do a few seconds of keyword searching. The idea that people will be utterly helpless on their jobs without instantaneous photographic recall† of AVL tress (and A-star, and all the other crap people are bullied into memorizing these days) just doesn't hold water.

† Which, as we know, is the only level of recall acceptable in the modern interview process. Even momentarily hesitating in your recall of certain definitions will easily get you flushed by some interviewers.

Re: Python coding interview challenges

#178

Post by ThrustVectoring »

Apocryphon wrote: post #153
ThrustVectoring wrote: post #151

Earlier quoted context omitted.

Good developers won't tolerate a contract-to-hire offer or will sniff out that they're a fire-fast environment. That, and it's pretty terrible for employee morale.

I'm not suggesting contract-to-hire, so much as a formalized and transparent concept of probationary periods. I'm pretty sure at-will employment means you don't need to bother with contract-to-hire unless you want to be cheap with paying your employees benefits. So these employees shouldn't be on contract anyway unless expressly temporary. It certainly would be terrible for morale if implemented thoughtlessly. But if…

Sure, the end state of "everyone hires quickly and fires quickly" is better, but there's an intermediate state where only a few companies use the new paradigm. In that one, the "can get quickly hired across the street anyway" isn't true. And the people who get fired are going to spin narratives about how getting let go was management being stupid and untrustworthy, regardless of how true that is, so you'll wind up generating noise that scares off developers.

Re: Python coding interview challenges

#179

Post by duiker101 »

hashkb wrote: post #109
duiker101 wrote: post #74

Earlier quoted context omitted.

In that 2% of the cases where you have to come up with something new, I don't really think that knowing pretty much any of this would help. You are storing a lot of information that will probably never be used. On the other hand, knowing how to come up with the solution. Knowing where to ask, what books to read or what people to ask, seems like a more important skill.

You are OK with not knowing how to invent, innovate, push the envelope, etc because you don't need to in order to collect your paycheck? Seems sad! Where is your passion for the craft?

You misunderstood me. Of course I love to invent and innovate. That's why I don't like memorizing solution to coding challenges. But just because I don't know them by hearth doesn't mean I don't know where to find the solution. Which is the more important skill.
Post reply on HN