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

181–190 of 252 posts

Re: Python coding interview challenges

#181

Post by khedoros1 »

FLUX-YOU wrote: post #163
southphillyman wrote: post #84

Earlier quoted context omitted.

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 can conceivably move up to management, never have to deal with algorithm hazing again, and make more than the guy that has to refresh every few years. The rewards just do not add up for this to remain an industry practice.

That sounds like a career change that I wouldn't enjoy, despite being able to also avoid some of my least-favorite aspects of staying on the dev side of things.

Re: Python coding interview challenges

#182

Post by khedoros1 »

collyw wrote: post #57
andrepd wrote: 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.

Why not ask me to bring in some work I have and discuss it?

For one, you're excluding all the people who've only done work that they can't bring in.

Re: Python coding interview challenges

#183

Post by khedoros1 »

bigtimeidiot wrote: post #77
hashkb wrote: 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, 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.

Re: Python coding interview challenges

#184

Post by jorgemf »

pseudalopex wrote: post #158
jorgemf wrote: post #91

Earlier quoted context omitted.

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.

Yes, this is what I meant

Re: Python coding interview challenges

#185

Post by Declanomous »

NTDF9 wrote: post #174
JustSomeNobody wrote: post #160

Earlier quoted context omitted.

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 sol…

I've never applied for a strictly dev position, but my friends have told me they've been asked about how different forms of self-balancing trees work. I haven't implemented my own self-balancing tree since Data Structures, and I'm pretty sure they haven't either. If someone asked me to implement one in an interview I'd honestly think they were crazy. Who would implement a data structure or algorithm they haven't used in nearly a decade without looking an implementation up first?

Bearing in mind that I use my programming ability for analysis rather than developing applications, I'd say that programming is like 90% fundamentals and 10% looking stuff up. If a company really wants to test someone's programming ability in an interview, I feel like the best thing to do would be to make up a programming language, give them a reference sheet, and then ask them to program a couple different versions of fizz-bizz.

Obviously it's not a perfect idea, but I think you'd at least be testing the skills people actually use when programming, rather than whether they can remember every bit of syntax from every language they have listed on their resume. I mean, if I lied and said I knew javascript, I'd almost certainly fail a programming test that used a made-up language based on it.

Re: Python coding interview challenges

#186

Post by jorgemf »

meheleventyone wrote: post #141
jorgemf wrote: post #134

With this type of post I always read comments complaining why they should know those things for an interview. They are not necessary. It is like some more knowledge is going to harm them. I wish I would know more about everything. Sometimes the connection between knowledge and how to solve a problem are not clear when you learn that knowledge. Why is it important to know how is the syntactic structure of a sentence i…

I don't think most people are complaining about gaining knowledge but the relevance of the test to job performance or the requirement to study whilst working and raising a family. "... you wont be able to discover how to solve a problem if you don't have knowledge about the solution in advance." Is simply false, whilst research is a skill all of its own it's most definitely possible to go off and learn key techniques…

It is not false, for example Albert Einstein was developing his Theory and he could do it because he was in a research ground where they were doing research about infinitesimal calculus, which was handy for Einstein to apply to his theory. But I think it wouldn't be clear to apply infinitesimal calculus to his theory if he didn't know it in advance. Or at least, we aware of it and its possibilities.

When you face a new problem, you just don't know how to find a solution, you based your hypothesis in the knowledge you already have. You can do research, but the more knowledge you have the less research you will do. And that time you save is money the company saves.

Anyway, you decide what to do with your life. If you are happier raising a family that is good. If you are happy learning stuff to apply to better jobs, that is good too. But obviously you cannot have everything because time is finite.

Re: Python coding interview challenges

#187

Post by jorgemf »

fnl wrote: post #150
jorgemf wrote: post #124

Earlier quoted context omitted.

> "before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index" How I am going to ask you to tweak an index, if you don't know how to browse a tree? Although I would have asked you about B+ and B* trees, the ones used to index a database. There are differences in those trees and you need to know t…

How big is the chance that you select the candidate who happens to know all solutions (e.g. by learning them by heart recently for the dozens of interviews he's planning on doing), but is not a good technical fit? My estimate is: pretty high; Let me explain why. If you indeed need someone who knows about B* vs B+ trees, why not ask him about that separately ("explain me the difference between ..."), to see if he has…

I was not talking about implementing anything.

I disagree with you in a lot of things. I don't like whiteboards because they are stressful and feels strange if you don't use them regularly. I was a teacher which uses whiteboards daily and they are completely different to use a computer. I would rather ask the candidate to talk about one of his projects and start asking relevant questions related to the job position and applied to the project he knows. And have a discussion this way. And the iteration with the candidate is only biasing your decision towards his personality and not his skills. To know if he does the things like I would do them.

But that is my opinion, the person who is hiring is the one who decides who he wants to hire. I feel more confident in finding a good fit/candidate my way that how you described.

Re: Python coding interview challenges

#188

Post by khedoros1 »

enraged_camel wrote: post #164
JustSomeNobody wrote: post #160

Earlier quoted context omitted.

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.

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 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". The discussion would end up going into some properties of capacitors, why they chose that exact form of oscillator, expected use-cases, etc. The behavior of the object lower in the "stack" becomes important, and so does a real understanding of how they work. Of course, actually requiring them to build one would be ridiculous.

Re: Python coding interview challenges

#190

Post by jorgemf »

kafkaesq wrote: post #177
jorgemf wrote: post #91

Earlier quoted context omitted.

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 photog…

The research you have to do is based on your previous knowledge. The less you know the more you need to learn when you are facing a problem you don't know how to solve it. But people is lazy, if they know a way to solve it they will go that way even if it is the worst way possible.

I am not talking about implementing an AVL tree without any help or resource. That is simple stupid, we have internet we must use it and save time. My point is that you need to know that there are balanced trees, know some of them and they characteristics. That knowledge will save you time when you face problems related to trees. You are not going to know all the trees because researches are working on new ones every day, but you should have some knowledge in the area.

If you interviewer drop you because you hesitate in something, maybe it is the interviewer problem and not yours. We are not perfect, we should know people will make mistakes and hesitate. I was rejected of interviews when I hesitate when they asked something about linked lists. I was happy it happened, because I was in shock when I was explanning how I did something with and A* algorithm and a octree and I couldn't believe the next question was about a linked list. I wouldn't be happy in that company.

Post reply on HN