Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview gone wrong

ashu1461.com

Post reply on HN
Print view View original

151–160 of 209 posts

Re: Interview gone wrong

#151

Post by _w1tm »

sampo wrote: post #129
TrainedMonkey wrote: post #118

Earlier quoted context omitted.

I have some experience in computer language design. The issue here is that `a==b==c` expression is magical - that is it does not follow from extending comparison binary operator. Specifically, `==` is a binary operator that that compares an expression before and after and returns a boolean. In this case, A==B==C is a trinary comparison operator. This is normally ok, except it's rare and the symbol it is using is over…

> it's not clear how short circuiting works It is clear if you read the docs. https://docs.python.org/3/reference/expressions.html#compari... https://docs.python.org/3/reference/expressions.html#boolean...

Is “let me check the docs” an appropriate thing to say in an interview setting?

Re: Interview gone wrong

#152

Post by carlmr »

throwaway313373 wrote: post #143
dzonga wrote: post #132

python was pleasant in the python 2 days. Now there's so many confusing ways to do one simple thing. and one thing Golang has made inroads is there's only one way to do something. and ruby is pleasurable because the interface is consistent i.e everything is an object.

What does the feature discussed in TFA (chained comparisons) have to do with Python 2 vs Python now. As another commenter pointed out [0] this feature existed since 1.4 [1]. Also, I don't understand why so many people seem to be so confused/surprised by it. I can't be 100% sure because it was a long time ago, but I think that a lot of tutorials/introductory articles mention it. Like, "Hey, did you know that Python ha…

I wrote Python for years before seeing it somewhere, going huh, and then I thought it's quite neat.

I still don't think it's that confusing. It does what you think it should if you're reading pseudocode, which is after all kind of Python's MO.

Re: Interview gone wrong

#153

Post by carlmr »

sgarland wrote: post #147
necovek wrote: post #11

Earlier quoted context omitted.

I disagree: if you are demonstrating your mastery of a language (and with Python, these things are important: using appropriate syntax is the difference between dog slow code and fast code), you should use idiomatic patterns like the above. Another of Python features is a great REPL: when unsure or confused by an interviewer, I'd just fire python from shell and type in 'x' == 'x' == 'x' to confirm and demonstrate it…

This is my opinion as well, but unfortunately isn’t always held by others. I once interviewed and by dint of knowing Python’s itertools module, absolutely destroyed the interviewer’s questions that they clearly thought would take some time to do. I was told later that while I “obviously knew Python quite well, it didn’t give a good signal for my capabilities.”

>I once interviewed and by dint of knowing Python’s itertools module, absolutely destroyed the interviewer’s questions that they clearly thought would take some time to do.

If I see such a situation I usually ask the interviewer whether they want a concise solution using libraries or they want to see how I would do this if I had to do it from scratch.

Or I just offer both, I show that I can do it, but that I know it would be easier to do with x.

I think this is a great opportunity to show you're a good communicator as well as a problem solver.

Re: Interview gone wrong

#154

Post by carlmr »

necovek wrote: post #60
mozman wrote: post #27

Earlier quoted context omitted.

In the real world you iterate, profile, and optimize

I am definitely a subscriber to not doing premature optimization, but in Python, there is a huge difference between found = searched_key in list(large_dict) vs found = searched_key in large_dict But also compare: searched_key in large_dict.keys() # O(1) and searched_value in large_dict.values() # O(n)

So much this. Write code that you can reasonably expect to not be slow af, while not sacrificing readability. Then profile and optimize if necessary.

Re: Interview gone wrong

#155

Post by dagw »

ball_of_lint wrote: post #75
reader9274 wrote: post #42

If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.

Most programming languages ought not to be optimized for a non-programmer to read, but rather for someone who writes code to read. There's a lot of options for a language to deal with a statement like this. It could be a syntax error, a compile or lint warning, it could work by doing order of operations and comparing the boolean from one compare with the third element, or it could work in the way you described. I'd p…

Most programming languages ought not to be optimized for a non-programmer to read

Python 'won' mostly because non-programmers could look at it, more or less understand what was going on, and feel that this was something they probably could learn.

Re: Interview gone wrong

#156

Post by dkdbejwi383 »

userbinator wrote: post #73
encomiast wrote: post #23

I know the point of the piece is the python syntax here, but I got stuck on: "judge things like code quality / speed / conciseness etc." Do people generally write concise code on right off the bat when confronted with a new problem? I've always taken the same approach I would with writing: get something that works; refactor for concision. Maybe everyone else is playing 3D chess and I'm still on Chutes and Ladders?

Do people generally write concise code on right off the bat when confronted with a new problem? As someone who has been on the interviewer side: this is an indicator of how much the interviewee "thinks first"; the ones who immediately start spewing tons of code are usually those who don't really have a good understanding of what they're trying to do.

Thinking by doing is also valid.

I code similarly to how I write, which is similar to how I draw etc. I start with very rough ideas and sketches, then I gradually iterate over those, refining ideas and throwing bits away. And eventually I have a working version/first draft/etc

I just can't get things done if I were to try and think of the entire solution first before getting anything down on paper. Maybe that's an ADHD thing, needing to let the idea take form lest it runs away and I get lost in the weeds

It's less "spewing tons of code" though and more starting with an outline, stub functions and comments to break up the steps before filling those out.

Re: Interview gone wrong

#157

Post by natebc »

_w1tm wrote: post #151
sampo wrote: post #129

Earlier quoted context omitted.

> it's not clear how short circuiting works It is clear if you read the docs. https://docs.python.org/3/reference/expressions.html#compari... https://docs.python.org/3/reference/expressions.html#boolean...

Is “let me check the docs” an appropriate thing to say in an interview setting?

yes.

Re: Interview gone wrong

#158

Post by skydhash »

grujicd wrote: post #112
cplat wrote: post #24

If your knowledge of Python comes from JavaScript, I would not blame Python for it. It's the failure of the person to not "read the instructions" and assume instead. Maybe conduct interviews in languages that you're familiar with?

If you were programming long enough, you easily had contact with dozens of languages. How do you pick up a new language? You can't really treat it as your first one. Especially if you need it "for yesterday". You won't read about "if" or "for". No, you scan for what's different from what you already know. If you're lucky you'll find "python for javascript programmers", but that probably won't go into non-core details…

If it’s a language I don’t know, I’d still read a book or check the doc for a tour of the syntax. I can scan one in a couple of hours and get an overview I can refer to later for a more specific question. Even if I needed it for yesterday.

Re: Interview gone wrong

#159

Post by ahoka »

Aachen wrote: post #135
tmtvl wrote: post #122

Earlier quoted context omitted.

Yet another way in which Lisp is vastly superior to any and all blub languages: (= 2 (+ 1 1) (sqrt 4)) ; => t ( t

I have no idea what this does or if you are joking. Could use some explanation

In the Lisp family of languages these comparisons are not implemented as operators, but functions.

The functions behave like:

= all the same

/= all different

> monotonically decreasing

>= monotonically nonincreasing

Also * is product and + is sum.

Re: Interview gone wrong

#160

Post by ahoka »

tmtvl wrote: post #122
reader9274 wrote: post #42

If you know nothing about Python or coding, and you see a=b=c, you'd think that's true when all three a,b,c are the same. Python does that beautifully here, and that's the intent. It's not Python that's confusing, it's your previous experience with other languages that's confusing you.

Yet another way in which Lisp is vastly superior to any and all blub languages: (= 2 (+ 1 1) (sqrt 4)) ; => t ( t

So Python is a Lisp?
Post reply on HN