|
MALE SHOEGAZE posted:That's stupid but you should really consider coming up with a better answer, even if it's a lie. What exactly is wrong with saying that, if it's true? Put another way what would a "better answer" look like, and why would it be better? Would it be better to say "I don't program at all in my spare time; it's something I only do if I'm being paid"? I would have thought it indicated a significant problem with a company's hiring processes if they allowed a candidate to make it all the way through to a final interview, but to then have the interviewer arbitrarily and capriciously dismiss the candidate based on an answer to one question (without so much as probing any further into that answer). We can presume that if the company had arrived at the decision that it didn't want to hire people who just program games in their spare time, then they would screen for that at an earlier stage in the process, and given that they seemingly didn't do this it follows that this was an arbitrary decision based on the whim of the interviewer.
|
#
¿
Mar 20, 2016 18:34
|
|
|
|
| # ¿ May 9, 2024 23:24 |
|
|
feedmegin posted:Also, and this is a small thing, but I assume C# has the usual logic operators, in which case '(foo & 0x1) == 1' is probably better than foo % 2. I mean, a decent compiler should optimise the latter to the former anyway, but at the hardware level modulus is either a lot slower than an and (on x86 for instance) or not even in the ISA (for ARM). It's already been pointed out that summing an arithmetic sequence has a closed-form solution, so if you cared at all about efficiency you'd use that, not wring your hands over whether it's better to use % or twiddle bits.
|
|
#
¿
Jun 13, 2016 20:17
|
|
|
If I was the interviewee looking at that exact problem, I would point out that a closed-form solution exists but ask the interviewer if they were asking in order to see whether I could provide a solution involving iteration, and if they said yes then I would offer to give a solution in that form. If I was the interviewer hoping to test whether the interviewee could come up with a solution involving iteration to a problem, I hope I'd manage to find something to ask that didn't have quite such a straightforward closed-form solution, but if one candidate spotted one I wouldn't regard them as being above the other candidates on that basis, unless maybe it was a position where strong mathematical aptitude would be advantageous.
|
|
#
¿
Jun 13, 2016 22:18
|
|
|
ToxicSlurpee posted:Though the thing that baffled me the most was interviews I had where I ended up being asked to write code in very short terms in languages that I made absolutely no indication that I knew. It wasn't on my resume. I never mentioned the languages. I even said "my web dev skills aren't great." Then the interview was like "hey do this thing in PHP in half an hour, go!" with no indicator that I'd be writing PHP. I don't know PHP. At all. They might just want to spring a language on you that you nothing about to see whether you can pick thing up quickly in order to get poo poo done. That's a good skill to have, although of course using a language in anger when you don't know it is a good way to make boneheaded mistakes and write bugs, so it's to be used with appropriate caution. Or they might be incompetent, either/or
|
|
#
¿
Jun 17, 2016 10:34
|
|
|
icecreamcheesesteak posted:It would be hard to write anything in PHP if don't even know the syntax at all. I'm assuming in this context that they'd be allowed access to Google and to ask questions incidental to the problem at hand, like "what's the standard library function for doing xyz in PHP". Not just hacking away blindly in Notepad. Syntax-wise PHP is a semicolons-and-braces language, it's not like it's really out there.
|
|
#
¿
Jun 17, 2016 22:45
|
|
|
feedmegin posted:Just like senior level developers in C-like languages being able to write fizz buzz is unimportant, right? Im sorry but this isn't obscure or anything, it's a basic part of the language. I think you are overestimating the extent to which everybody needs to know about bitwise operators. Some people will need to know that stuff and some people just won't have been exposed to it because they've only done things at a higher level of abstraction. There is a difference between knowledge of bitwise operators and being able to implement fizzbuzz. Fizzbuzz tests whether you can implement a (simple, unambiguous) set of behaviours; implementing a set of behaviours as requested is something pretty fundamental to working as a developer. Bitwise operators, in contrast, are a piece of trivia - have you studied them or had cause to use them before, or not? If you have, then you will know how to use them and if you haven't then you won't. Certainly I would expect that if someone works in software development they should be able to pick up an understanding of bitwise operations rapidly, and I might have reservations about them if they struggled.
|
|
#
¿
Jun 19, 2016 17:13
|
|
|
Cuntpunch posted:I mean, when is trivia *too* trivial? I think if a valid answer to a question is "I don't know, why the hell would you do that in the first place" (as in the case of the "#define class struct" thing) then it is not a suitable interview question. I mean, if it's never going to come up with a sane team writing sane code then why do you care whether the candidate can work out on the spot what would happen? I think the examples of questions you gave in your post are solid, with the possible exception of the faulty machines one.
|
|
#
¿
Aug 23, 2016 23:41
|
|
|
b0lt posted:You should never do #define class struct, but you should be able to reason about what it would do, because you know the difference between a class and a struct. If you want to determine whether the candidate knows the difference between a class and a struct, why not ask them "what's the difference between a class and a struct?"
|
|
#
¿
Aug 24, 2016 09:20
|
|
|
return0 posted:Because this tells you if they know what #define is, and their comments on the line of code beyond the immediate answer can provide additional insight into their practical experience? Well, okay. I feel like if you want to test the candidate on whether they know how the preprocessor works you have better ways of doing that than asking them stupid questions. Like for example, you could ask them what's wrong with this: code:
|
|
#
¿
Aug 24, 2016 11:53
|
|
|
|
| # ¿ May 9, 2024 23:24 |
|
|
In case you didn't want to go to the trouble of running code, the problem is that the C++ preprocessor does a simple text replacement, so something like 6 * ADD(3, 5) becomes 6 * 3 + 5, which is 23, not 48 like you would think to look at it. The usual way you would correct this is to add some brackets in the macro definition: #define ADD(x, y) (x + y)
|
|
#
¿
Aug 24, 2016 13:27
|
|