Python coding interview challenges • Hacker News Board

Re: Python coding interview challenges

#151

Post by ThrustVectoring » Mon, Apr 03, 2017, 5:51 PM UTC

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…

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.

Re: Python coding interview challenges

#152

Post by Paul-ish » Mon, Apr 03, 2017, 5:54 PM UTC

jacquesm wrote: post #149

Paul-ish wrote: post #136

Earlier quoted context omitted.

What do you do when tons of people apply for a position?

Find a better way to reach your target audience. Getting people to self-select is the very best way to reduce the load from interviewing.

How would you do that? Also, saying there will be a coding interview up front does cause people to self select.

Re: Python coding interview challenges

#153

Post by Apocryphon » Mon, Apr 03, 2017, 5:58 PM UTC

ThrustVectoring wrote: post #151

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…

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 it was done in a way with clear expectations of employee performance, then terminations would not be arbitrary. And the morale hit of being terminated at any time- a situation with legally exists in California atm anyway- would be mitigated by more companies being quicker to hire instead of forcing long arduous interview processes.

So then the situation becomes "If mgmt. is just, then they will keep me on, if they are dumb, then I can get quickly hired across the street anyway."

Re: Python coding interview challenges

#154

Post by jacquesm » Mon, Apr 03, 2017, 5:59 PM UTC

Paul-ish wrote: post #152

jacquesm wrote: post #149

Earlier quoted context omitted.

Find a better way to reach your target audience. Getting people to self-select is the very best way to reduce the load from interviewing.

How would you do that? Also, saying there will be a coding interview up front does cause people to self select.

It would definitely take up some team resources, but it's not more complex than the work they're already doing. So 'how would you do that' is the wrong question. The question should be 'how would they do that?' and the answer I don't know but I'm sure if you ask a team they'll be more than happy to explain, after all it is their (and not my) future that is at stake and given the fact that they are involved they'll do the best possible job to make sure they have to go through it the minimum number of times with the largest chance of success.

This is still far less effort than a wrong hire would cause. Anyway, I can see that my methods are not acceptable (yet), maybe in another decade or so?

Trust is hard. Even companies that trust their tech people with the corporate crown jewels still have a hard to impossible time trusting them with such everyday decisions such as who they want to work with. It's counterproductive to say the least but that's how we've been doing it for the last 40 years, so I don't expect any major changes in the near future.

Re: Python coding interview challenges

#155

Post by munificent » Mon, Apr 03, 2017, 6:06 PM UTC

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…

> why not embrace California's at-will status and hire and fire often?

This sounds like an utterly miserable experience for both new hires and coworkers of the new hire. Do you really want your company's onboarding process look like FNG syndrome?

https://en.wikipedia.org/wiki/FNG_syndrome

Re: Python coding interview challenges

#156

Post by Apocryphon » Mon, Apr 03, 2017, 6:08 PM UTC

munificent wrote: post #155

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…

> why not embrace California's at-will status and hire and fire often? This sounds like an utterly miserable experience for both new hires and coworkers of the new hire. Do you really want your company's onboarding process look like FNG syndrome? https://en.wikipedia.org/wiki/FNG_syndrome

See my response here: https://news.ycombinator.com/item?id=14025297

Re: Python coding interview challenges

#157

Post by dr_zoidberg » Mon, Apr 03, 2017, 6:09 PM UTC

brianwawok wrote: post #119

dr_zoidberg wrote: post #113

Earlier quoted context omitted.

Nice catch, but then: In [13]: Decimal(5000000).exp() * Decimal(5000000).exp() --------------------------------------------------------------------------- Overflow Traceback (most recent call last) in () ----> 1 Decimal(5000000).exp() * Decimal(5000000).exp() Overflow: [ ] The problem is that the multiplication blows the precision of the used format (either double for math.log(...) or the one the decimal module uses)…

Hey don't be a quitter, we can make Decimal support way bigger numbers via context

Alternative, buzzwordy approach: let's train a convolutional neural network to do addition!

Re: Python coding interview challenges

#158

Post by pseudalopex » Mon, Apr 03, 2017, 6:11 PM UTC

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…

Knowing when to use an AVL tree is orthogonal to being able to write one under pressure on a whiteboard. But as long as someone knows that different trees have different performance characteristics, I care more about how they decided what to optimize and why they recommend a lookup-optimized tree over a cache.

Re: Python coding interview challenges

#159

Post by JustSomeNobody » Mon, Apr 03, 2017, 6:18 PM UTC

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…

> Not revealed as a terrible company, perhaps, but as a terrible interviewer.

Some software is HEAVY on data structures and algorithms? But, then hopefully someone not interested in that would not apply...

Re: Python coding interview challenges

#160

Post by JustSomeNobody » Mon, Apr 03, 2017, 6:20 PM UTC

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.