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

111–120 of 252 posts

Re: Python coding interview challenges

#111

Post by fencepost »

swalsh wrote: post #68
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…

I was going to agree with you, 98% of my career has been "google for a library, then use or tweak". It's RARE we ever actually do anything "new". However there ARE companies that do, and every once in a while YOU may have to do something new. In those cases it's good to make sure you have a foundation to build on. I have 4 books in the "The art of computer programming" series on my desk. They've been more or less dec…

Googling for a library is all well and good, but if you can't evaluate whether it's well designed and well written then you might as well rephrase it as "Google for someone else's problems to add to my own."

The background knowledge to understand what you're looking for and looking at is really important in these cases. You mention having and having read TAOCP, that already puts you ahead of >99.99% of the people doing programming out there - 95% of whom couldn't tell you who Knuth is, what he's written, or what Drofnats refers to.

Re: Python coding interview challenges

#112

Post by recursive »

riebschlager wrote: post #8
nickpeterson wrote: post #4

"Before we hire you, we first need you to outwit this burmese python..."

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)

Re: Python coding interview challenges

#113

Post by dr_zoidberg »

brianwawok wrote: post #100
dr_zoidberg wrote: post #94

Earlier quoted context omitted.

It breaks quite early: In [8]: math.log(math.exp(5000) * math.exp(6000)) --------------------------------------------------------------------------- OverflowError Traceback (most recent call last) in () ----> 1 math.log(math.exp(5000) * math.exp(6000)) OverflowError: math range error In [9]: math.log(math.exp(500) * math.exp(600)) Out[9]: inf

Hey let's not be a quitter >>> (Decimal(5000).exp() * Decimal(6000).exp()).ln() Decimal('11000.00000000000000000000000')

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

I had also thought about the intention of the question trying to get you to express the sum as bit operations (thought I admit that sounds like going for a very low-level profile), or maybe just "thinking outside the box".

Re: Python coding interview challenges

#114

Post by tonyedgecombe »

jacquesm wrote: post #26
problems wrote: post #15

Earlier quoted context omitted.

Yes, you're expected to be able to write basic stuff like most of these challenges without Google or StackOverflow. There are some however here that you really shouldn't be, like remembering specific algorithms - if you're just memorizing 20 different sorting algorithm's exactly implementation, clearly that's not producing much if any value for you. If someone however was to give you this Algorithm section https://nb…

I've been coding for 4 decades. There are so many different standard libraries and function calls to remember that only the people that are one-trick ponies (one ecosystem, deep knowledge) are going to be able to do the majority of these without an outside reference. And those are exactly the people you would not want for a job because they would most likely not have the flexibility to shift away from that ecosystem…

I doubt there are many people with a deep knowledge of just one ecosystem after 4 decades, plenty with a shallow knowledge after that time though.

Re: Python coding interview challenges

#115

Post by fencepost »

lordCarbonFiber wrote: post #89
rpedroso wrote: post #86

Earlier quoted context omitted.

I primarily write python web-based APIs for a web application + 2 mobile apps. Just the other day, I was dealing with an endpoint that had to update hierarchical data (i.e. a collection of trees). Due to the circumstances, normalization wasn't an efficient option. I ended up throwing together a barebones tree with a 5-line DFS implementation to traverse it. It handled inserts, updates and deletions (for my use-case)…

And because your code was implemented in python (rather than use prebuilt libraries that call back to C) it was 100x slower than it should have been. Im all for knowing the fundamentals but there is a strong argument for knowing the right tool for the job.

re: the debate between Python being slower and C faster, it all depends on context. If the context is "this is going to be called multiple times for every transaction" then yeah, look into recoding it. If the context is "this is going to be called for this particular edge case and may execute 10 times a week and take an extra 3 seconds each time" then there are more productive places to put your energy.

At the level of programming that the grandparent is talking about, I'd accept the judgement of the programmer working on it as to the appropriate solution.

Re: Python coding interview challenges

#116

Post by rebootthesystem »

hashkb wrote: post #61
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…

> I'm a kick-ass get-things-done full-stack web engineer. And modest, too. 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.

I think you are looking at this wrong. I have zero problems with someone presenting themselves this way and would definitely consider hiring the person.

Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't.

My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc.

A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough.

I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview.

I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.

Re: Python coding interview challenges

#117

Post by joshuamorton »

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…

"Perhaps you won't, but since we don't know yet exactly what you'll be working on, we might know broadly what PA or even project, but we can't know what problems you will encounter or what direction it will take to debug any problems that arise, we want someone with a broad base of skills who can at the very least recognize performance problems and solve them in a simple case. We expect that if you can solve this relatively simple problem in an environment with no resources, that with the aide of documentation, profiling tools, and teammates to lean on, you'll be able to address much more complex issues that arise. On the other hand, if it takes you documentation and teammates to solve this simple case, who knows what kinds of tools it will take you to solve real world problems that arise."

"Correlation does not imply causation" doesn't imply that correlation never implies causation.

Re: Python coding interview challenges

#118

Post by jacquesm »

empthought wrote: post #106
jacquesm wrote: post #79

Earlier quoted context omitted.

Introduce them to the team they will be working with, have them do a code review or take a ticket and find their way through docs and discuss a potential solution. In general teams are a much better judge of talent and ability than recruiters or your typical interviewer, especially in a normal work setting.

That's really expensive for the team in terms of time investment for possibly no payoff. Someone has to make sure that a candidate that gets to that point has a good chance of being hired. That person is "your typical interviewer."

Your typical interviewer, if he or she does not have relevant knowledge is just as likely to throw out the baby with the bathwater as they are to select the right candidates. There is no reason not to have the team do the pre-selection. I know this is all terrible news for recruiters and HR people alike but really there is nobody better qualified to determine who they want to work with on a particular problem than the existing team. The only situation where you would be better off with other people making that decision is when there is no team yet.

One thing I used to totally loathe during my brief stint as a programmer employed at a large organization is that when new people showed up that were already hired it was then up to us on the floor to make the best of a whole series of bad decisions preceding that moment.

So, let's involve the team in the messaging and pre-selection as well as giving them the final say.

Think about it this way: if you believe that the team you employ is the best possible group to do the work, don't you feel they are also the best possible group to determine how to expand the group?

Re: Python coding interview challenges

#119

Post by brianwawok »

dr_zoidberg wrote: post #113
brianwawok wrote: post #100

Earlier quoted context omitted.

Hey let's not be a quitter >>> (Decimal(5000).exp() * Decimal(6000).exp()).ln() Decimal('11000.00000000000000000000000')

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
Post reply on HN