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

31–40 of 209 posts

Re: Interview gone wrong

#31

Post by whack »

zitterbewegung wrote: post #8

I'm confused about this blog post. Python is mostly C inspired but actually more pseudocode inspired (which helps its popularity) which is why chained expressions exist. Also, why would you conduct an interview in a language where even if you don't know the syntax (and this is obscure) you could have looked it up or disallowed the interview to be done in Python? I think the due diligence with this issue is more to th…

> Also, why would you conduct an interview in a language where even if you don't know the syntax (and this is obscure) you could have looked it up or disallowed the interview to be done in Python?

The norm in most of my interviews has been that candidates can solve coding problems in whatever language they are most comfortable with. For most languages like Python etc, it would be a mistake to reject a candidate just because they don't have experience with that specific language.

Re: Interview gone wrong

#32

Post by tbrownaw »

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?

There are degrees of conciseness.

I've seen real code that looks like

    if(bool_var == false) {
      other_bool_field = true;
    } else if(bool_var == true) {
      other_bool_field = false;
    }
Which I suppose could be called anti-concise.

Re: Interview gone wrong

#33

Post by awesome_dude »

zitterbewegung wrote: post #8

I'm confused about this blog post. Python is mostly C inspired but actually more pseudocode inspired (which helps its popularity) which is why chained expressions exist. Also, why would you conduct an interview in a language where even if you don't know the syntax (and this is obscure) you could have looked it up or disallowed the interview to be done in Python? I think the due diligence with this issue is more to th…

Mate, let's be honest, we've all been in interviews where the interviewer had a serious misunderstanding of the language the job was supposedly using, let alone some other language.

Re: Interview gone wrong

#34

Post by Buttons840 »

dartharva wrote: post #26
pcthrowaway wrote: post #20

Earlier quoted context omitted.

1 == 1 == 1 is actually true in Javascript due to type coercion You're probably thinking `1 === 1 === 1` which is indeed false

I tried 2 == 2 == 2 in my browser's (Chrome) console and it evaluated to false.

I stealth edited my post. Sorry.

Re: Interview gone wrong

#35

Post by throwaway313373 »

int_19h wrote: post #15

In this respect, Python makes a lot more sense since that is how you'd normally write such an equality in math, and generally how people chain them: A=B=C means A=B and B=C. Part of the problem here is that we treat true/false as "just another value" in programming, and thus the usual operators are used to compare them. In math notation, if you wanted to compare the result of comparison A=B to a Boolean value C, you'…

I think that the main issue here is not treating true/false as values but allowing them to be implicitly converted or compared to numbers with the assumption that true equals 1 and false equals 0.

I think that Rust got this right. It doesn't allow you to add integer to boolean or multiply boolean by float etc, because it is unclear what does it even mean mathematically.

Also, most languages implicitly assume that any value of any type is either "truthy" or "falsy" thus you can do something like `while(1) { do_stuff() }`. Rust doesn't allow this BS, `if` and `while` expect a boolean so you have to provide a boolean.

Re: Interview gone wrong

#36

Post by userbinator »

whack wrote: post #31
zitterbewegung wrote: post #8

I'm confused about this blog post. Python is mostly C inspired but actually more pseudocode inspired (which helps its popularity) which is why chained expressions exist. Also, why would you conduct an interview in a language where even if you don't know the syntax (and this is obscure) you could have looked it up or disallowed the interview to be done in Python? I think the due diligence with this issue is more to th…

> Also, why would you conduct an interview in a language where even if you don't know the syntax (and this is obscure) you could have looked it up or disallowed the interview to be done in Python? The norm in most of my interviews has been that candidates can solve coding problems in whatever language they are most comfortable with. For most languages like Python etc, it would be a mistake to reject a candidate just…

The norm in most of my interviews has been that candidates can solve coding problems in whatever language they are most comfortable with.

I assume they've already filtered out candidates whose "most comfortable language" isn't the one they're hiring for, or they're going to have a difficult time when they come across the one who wants to use APL or x86 Asm.

Re: Interview gone wrong

#37

Post by awesome_dude »

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?

Yeah - when I went through University the mantra I was taught was

1. Get it working

2. Get it working well

If you're faced with an unfamiliar domain, you don't rock up to it and throw all the super optimised fastest code at it. in fact I would view someone who did as having done the test before (making it worthless).

Re: Interview gone wrong

#38

Post by noncoml »

I am idiot but I would, and have in the past, have wasted the whole interview time argue in that I am right and he is wrong.

Yes, John, some switches do start sending the packet before finish receiving it. It’s called cut-though switching. Hope you googled it. And yes it was worth losing the job offer over it.

Re: Interview gone wrong

#39

Post by nerdponx »

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?

Everyone thinks differently. "thing1 == thing2 == thing3" is a pretty natural expression of the idea here IMO.

Re: Interview gone wrong

#40

Post by nerdponx »

necovek wrote: post #11
taxman22 wrote: post #2

Any time you use language specific tricks in an interview, you’re probably going to confuse your interviewer and not do well.

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…

In this case the candidate evidently didn't understand it either, but was repeating a pattern they had seen before, which IMO is a form of anti-mastery: don't do things that you don't understand, especially when you're supposed to be demonstrating your skill and understanding.
Post reply on HN