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

221–230 of 252 posts

Re: Python coding interview challenges

#221

Post by ramblenode »

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…

The problem with your reasoning is that you expect the interview to mirror job requirements rather than select for job performance. In many cases the best instrument to measure the latter will resemble the former, but there's nothing intrinsic about the relationship. If giving someone a brain teaser or having them recite trivia provides a strong signal for job performance, then it makes sense to use these instruments. You could argue that they don't provide a meaningful signal (which I think Google may have discovered with the brain teasers), but that is a separate discussion.

Something else to consider is that the interview is optimized to select for true positives and reject false positives at different rates. It's been discussed elsewhere that for a company like Google avoiding false positives is much more important than finding good candidates. So it may be the case that some instruments like trivia recitation provide the right signal at the intersection of the optimization curves. The fact that many (even most) qualified candidates score poorly on these instruments doesn't impugn their utility; their primary goal isn't to identify good candidates but to filter out bad ones.

Re: Python coding interview challenges

#222

Post by enraged_camel »

khedoros1 wrote: post #188
enraged_camel wrote: post #164

Earlier quoted context omitted.

You don't need to be able to build a capacitor from scratch in order to understand how they work. Furthermore, electrical engineers don't have to build capacitors from scratch during job interviews to prove their competence.

No, but there's a level of the EE tech stack where you do need to understand (and have the ability to build) the level below. I don't need to know: how to construct a transistor, build a logic gate, build a look-ahead adder, construct an ALU, CPU, computer hardware, write assembly, or write a compiler to do my job (although the last couple start getting close enough to my bailiwick that I think they're useful). I'd e…

>>I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation".

Sure, but that's the equivalent of drawing a diagram that explains how quick sort works, as opposed to implementing it using real code. Most companies demand the latter during interviews.

Re: Python coding interview challenges

#223

Post by jorgemf »

FLUX-YOU wrote: post #213
jorgemf wrote: post #191

Earlier quoted context omitted.

> If you work really hard, learn all of this stuff, and do a really good job and save your company a bunch of trouble by knowing all of this, you won't get a dime for it, and that's the problem I think that is your problem. I don't stay in companies where I don't feel valued. And anyway you are receiving a salary every month for your work. If you think you should get more, ask for more or move to another place. For s…

>My security lies in my knowledge and my skills, and that is something I take with me whereever I am. Sorry, I was confusing, I meant network and information security. Using a good password hash/library, not trusting user input, knowing some basic attacks or stuff from OWASP Top 10 and how to reproduce them. That stuff is still a problem. I'll admit I probably know less than I should because it's at the fore-front of…

Oh I missunderstood, sorry. I think everything is important, the more you know the better you can do your job. Probably maintenance comes before security, and security before performance. But it depends on the case.

Re: Python coding interview challenges

#224

Post by tekkk »

To me it is reasonable to presume that a software developer candidate knows the basics of CS: algorithms, data structures and such but for anything that require deeper knowledge I think it should be only asked if it is mandatory for the job.

Sure if you want to maintain a certain "prestige" you should maybe use them to limit your applicant pool but in the end if your work is nothing but coding front-end JavaScript it doesn’t matter do you know how to traverse B-trees or not. And if a need somehow arises it is very easily googleable and implementable with good enough CS education.

I think what the interviews should be about, and the best that I have been, have involved some basics sure but also one had few “real-life” coding exercises and in another I had a code review about one of my project’s code (which I was surprised by). Nothing tells more about a person than having them to explain what is their passion but if you are only interested in people that can jump through some loops that’s the people you are going get. Maybe in that kind of company that's just how they do things.

I’d argue most people can intuitively tell, maybe not why, when a recruitment process feels “right” compared to one that is forced and does nothing but dehumanize you to a walking Wikipedia and ticket-monkey. But maybe in programmers there is also some that seem to like that idea so I’d say it is more of a skill and culture fit than anything else.

But in any case the whole process should be based on some structure that actually measures something real. I personally don’t like being reduced to few facts about missing knowledge on a spreadsheet which I could learn in a week or so. It hurts my ego and most of all makes not want to work in the said company in the future so when I’d know those things I won’t be reapplying.

Re: Python coding interview challenges

#225

Post by throwaway9475 »

khedoros1 wrote: post #183
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, we should learn the basic algorithms and data structures (and their performance and storage characteristics) because they're the building blocks of everything else we use. You're using some API? OK, cool. Knowing some about its internal workings means that when you've got some wonky performance issue, you've got a basis to start reasoning from, to find and fix the cause of the problem.

Never once has knowing about the performance of linked lists or hashmaps been necessary to fix an API issue. 99% of your API issues will be "this doesn't work for X reason", not "this API response is slow because weren't using X instead of Y data structure".

Re: Python coding interview challenges

#226

Post by throwaway9475 »

rebootthesystem wrote: post #207
bskap wrote: post #125

Earlier quoted context omitted.

The problem with your approach is that it excludes anyone who spends most of their time writing code for a business. I legally can't provide you with the code that I have written over the last several years. You're limiting your applicant pool to people who have been paid to work on open source, freelance web developers, and people with very little life outside of work. I agree that puzzles aren't all that great of a…

Not entirely sure how you might have reached that conclusion. Anyone dedicated to their craft will naturally --out of sheer interest-- devote time and effort to getting better at it. For example, as a young EE I was constantly reading data books (yes, physical data books) and application notes. I had hundreds of data books and probably went through all of them twice and some several times. I could, at the time, talk…

So here's the thing: not everyone is you, not everyone is passionate about technology, and it's not reasonable to expect people to do more of their job outside of work for free. You might like, and that's great, but people have families and hobbies and interests that sometimes have nothing to do with the 40 hours they churn through for their bosses. I'm so sick of interviewing for companies who want "passionate" developers, which translates to "doing more work for free".

If you're curious about why we have workplace harassment laws, talk to basically any woman with a job and then rethink your sweet nostalgia.

Re: Python coding interview challenges

#227

Post by khedoros1 »

enraged_camel wrote: post #222
khedoros1 wrote: post #188

Earlier quoted context omitted.

No, but there's a level of the EE tech stack where you do need to understand (and have the ability to build) the level below. I don't need to know: how to construct a transistor, build a logic gate, build a look-ahead adder, construct an ALU, CPU, computer hardware, write assembly, or write a compiler to do my job (although the last couple start getting close enough to my bailiwick that I think they're useful). I'd e…

>>I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation". Sure, but that's the equivalent of drawing a diagram that explains how quick sort works, as opposed to implementing it using real code. Most companies demand the latter during interviews.

The places I've interviewed (a few big names and a few small ones) either wanted something pseudo-code-like (on the whiteboard), wanted an explanation of the algorithm (potentially with some clarifying diagrams or code), or actually provided me a computer with an IDE.

Re: Python coding interview challenges

#228

Post by inetknght »

logfromblammo wrote: post #194
quacker wrote: post #122

Earlier quoted context omitted.

> need to roll their own new solutions in the face of so many well-established libraries I'm not defending interview quiz-time, but it isn't (or shouldn't be) about rolling your own solution. It's about understanding concepts. Understanding the basics of time/space complexity are pretty fundamental when designing systems. Developers frequently encounter hashing and (probably less-often) trees, so I don't see an issue…

If you're measuring my design ability in the interview, you had better give me an opportunity to use that ability after being hired. Too many times have I been asked questions that shaped my expectations of the job, only to be disappointed later on. The worst offender in this respect put me through a technical screen that could only reasonably be passed by someone with a bachelor's degree in CompSci or equivalent wor…

> the code I write "should be understandable by a kid fresh out of high school"

tl;dr: "you're going to be replaced by a kid fresh out of high school so you might as well make it easier on us to do it"

Re: Python coding interview challenges

#229

Post by Apocryphon »

poikniok wrote: post #217
Apocryphon wrote: post #212

Earlier quoted context omitted.

The interview process would presumably be shorter and less complain-worthy than the current industry standard.

Well I can confidently say that people I know don't have a problem with the current algorithmic interview process, in fact my friend group generally finds it fun, where as conversely I don't know anybody who would take a job with a non-insignificant chance of being fired.

That's fair, and certainly there are plenty of engineers who are content with the current state of tech interviews, but there also seem to be many who aren't, given that this conversation is taking place on a comments thread full of criticisms of the tech interview process, and these threads seem to manifest at least once or twice a week on HN.

Re: Python coding interview challenges

#230

Post by khedoros1 »

throwaway9475 wrote: post #225
khedoros1 wrote: post #183

Earlier quoted context omitted.

No, we should learn the basic algorithms and data structures (and their performance and storage characteristics) because they're the building blocks of everything else we use. You're using some API? OK, cool. Knowing some about its internal workings means that when you've got some wonky performance issue, you've got a basis to start reasoning from, to find and fix the cause of the problem.

Never once has knowing about the performance of linked lists or hashmaps been necessary to fix an API issue. 99% of your API issues will be "this doesn't work for X reason", not "this API response is slow because weren't using X instead of Y data structure".

You sound like you've worked with significantly different code than I have. Your "never once" is my "almost always", and my "X reason" is often because I'm working with an immature, unreleased library developed by another team at my employer.
Post reply on HN