Live data from Hacker News

Python coding interview challenges

github.com

81–90 of 252 posts

Re: Python coding interview challenges

#81

I don't understand code challenges. Can you even program without Google and Stack Overflow anymore? And god-forbid being experienced in a dozen frameworks and libraries if it's not the exact combination the company uses.

You can definitely code without Google and SO. And you should. Once you have a grasp of what you are doing I think it's essential to not rely on those. Doing things only because SO says it it's usually a very good way of losing track of what your code actually does. They are there as a reference and as a help not as a main source.

Re: Python coding interview challenges

#82

Earlier quoted context omitted.

Honestly, I think you'd learn more about a potential hire that way than by presenting them with these sort of challenges.

"We see you're familiar with compression but how about pandas?"

I fear the part of the interview that gets into spiders for web scraping...

Re: Python coding interview challenges

#83

Earlier quoted context omitted.

I'm a lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday. Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).

Where does one get a job writing actual algorithms and data structures? I actually enjoy that and am pretty good at it. I'm sick of jobs that are nothing but glueing together poorly documented and tested libraries.

Data Engineering, SRE, Production Engineering are really good for that kind of thing. Especially at a larger company, but the truth is those opportunities aren't going to come up that often, you don't want to be continuously inventing your own technology unless you're living on the bleeding edge like Google.

Re: Python coding interview challenges

#84

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…

Honestly, is it unreasonable to require that people brush up on this stuff every couple of years? In my experience the majority of companies just want you to be able to do fizz buzz level whiteboarding and intelligently speak to your experience. I feel like we all know in advance which companies typically require a month long review of algorithms before the interview. IF you want to work for one of them then do what you need to do to get the job there. We all agree it's annoying but I really don't think it's as big a deal as people make it out to be.

Re: Python coding interview challenges

#85

Earlier quoted context omitted.

I'm a lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday. Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).

Where does one get a job writing actual algorithms and data structures? I actually enjoy that and am pretty good at it. I'm sick of jobs that are nothing but glueing together poorly documented and tested libraries.

I'm currently working in finance. Before that I was working at a major search engine which doesn't start with G.

Re: Python coding interview challenges

#86

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 lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday. Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).

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) in linear time.

The details aren't so important as the fact that adding a dependency would have been overkill for my needs. This isn't to say that efficient graph implementation libraries should not exist or be used, but I was able to produce this code faster by having that basic CS knowledge.

Re: Python coding interview challenges

#87
post #47
post #42

Earlier quoted context omitted.

It's not about actually having to implement these algorithms in your practical, day-to-day work. It's a challenge to test your reasoning and problem-solving ability in abstract, that you can administer in 15 minutes. You can't really test a candidate with real-world workloads, can you.

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.

While I fully agree with you in that interviewing is broken, and it's broken because we throw away a lot of great people, you'll be surprised how much time a company spends finding the right candidate.

Imagine we spend an hour per candidate on screening, and we pass 10% of people, and we spend 6 hours on each on site,with 25% of them passing.Finally 50% of candidates accept the offer: This is very typical math, and it ends with over 100 hours per developer hired. For each hire, we also had a declined offer, 6 candidates rejected on site, and 72 failed screenings!!

Given those round, but not really all that far from reality numbers, any increase in screening time will spiral out of control unless some other multipliers change. The one that is most likely is that said company is giving offers to less than half of the people that would have been successful.

Those numbers also show why it's so important for a company to make competitive offers and woo candidates, and why they'd not like it when people interview at 6 places at once: Run the calculations just changing the acceptance rate down to 30% and up to 80%. If you are trying to recruit from a big name university, chances are that your candidate really is talking to a dozen serious SV companies and gets 4 serious offers.

Therefore, while I agree with your sentiment, you can probably see why it's so hard to convince someone running the traditional SV pipeline to make changes, as you are either raising costs or telling them that their current outcomes are a gigantic dumpster fire.

Re: Python coding interview challenges

#88

In a way I prefer this to "how many ping pong balls can fit in a school bus" that was all the rage in the 90s and early 2000s. But... man... I have a computer science degree, I've been coding for 20 years, and I've held (and kept) a CTO role at two mid-sized startup companies. Currently I'm considering looking for a job at a larger company (where I wouldn't be CTO but I'd be hopefully paid more) and these kind of que…

Keep in mind that, because the number of programmers is increasing, the majority of them are fresh out of school or close to it. Algorithms interviews are largely designed for interviewing people who don't have much experience, so they're skewed toward testing what people learned in school.

If after 2 CTO roles you interview for a job and they ask you to write a linked list algorithm, then would you want to work there? I mean you might, but that alone should at least beg the question. If they're not asking you how you'd manage a team of smart but stubborn coders or structure their company's software architecture and services to be more reliable, then they certainly aren't paying much attention to you or what your strengths and experience are. Or they simply don't know how to hire an experienced person, which signals that they don't know what to do with an experienced person once hired.

Also, it would take the vast majority of great coders at least a half hour to code a linked-list from scratch in C and get it right, depending on what you're doing.

So don't worry.

Re: Python coding interview challenges

#89

Earlier quoted context omitted.

I'm a lowly c++ software engineer. You might not have to deal with that stuff, but for me it was Tuesday. Kidding aside, someone has to build those tested, stable libraries that handle those problem (or even untested bleeding-edge if you are breaking new ground).

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: Python coding interview challenges

#90
post #61

Earlier quoted context omitted.

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

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