|
Space Whale posted:When i checked if the input range included even numbers So if the question posed to you was exactly what you said - "How would you compute the sum of all odd numbers from 1 to 1000?" - then it's possible they thought you went overboard by doing all this: quote:logic to handle inputs, bumps up the start of the sequence if it's even and bumps down the end if it's even, make sure the start is less than the end They didn't ask for a method which can compute the sum of all odd numbers over non-continuous unordered sequences. Quite likely they tossed you an introductory softball question and when you broke out a parametric equation solver to compute the angle of the pitch they thought "Why didn't they just hit the stupid ball?" At my last job as a hiring manager we would give potential applicants a fairly basic test that involved making an object with some polymorphic properties and a linked list in which to hold them. It can be argued all day over whether this was a Good Test or not but I remember very clearly one applicant who did it in Java and wrote ObjectFactories for every single thing. The whole test ended up something like fifteen printed pages. As a result we went into the interview having serious concerns over whether they could actually do coding tasks without going to pieces overthinking the situation and not ever completing anything that wasn't perfectly [according to them] architected. edit: It's also possible they were looking to trap you with unstated assumptions! The right thing to do is to ask "Is the input ordered? Is it all integers between 1 and 1000?" and so on. Then apply solutions as you see fit.
|
#
¿
Jun 13, 2016 13:17
|
|
|
|
| # ¿ May 9, 2024 21:34 |
|
|
Space Whale posted:The fact that you can't actually trust your interviewer and it's basically a guessing game of what they really want is another horror. You should try not to take it too personally and really don't think of it like a "trust betrayed" situation. Half of their entire job at that moment is to determine whether you have flaws that would be a detriment to their goals and that means poking at spots that look weak. "I think my interpretation is correct" is a very common assumption when programmers are given problems and the inability or unwillingness to determine one's own correctness is more often than not a weakness. Always question your assumptions - in an interview situation, that means question the interviewers. Make sure you understand the problem before you break out the REPL or Notepad or even a piece of paper and a pencil. No one cares how fast code can be produced if the code is solving the wrong problem. Producing wrong code costs real money.
|
|
#
¿
Jun 17, 2016 17:48
|
|
|
That almost seems a bit more personable than having to type up answers to those same questions in to every automated HR screener that exists. At least this way there isn't an opportunity for a lovely applicant to just pound in those those answers canned from some "ACE UR INTERVIEW!" site. Close your eyes and imagine you're talking to a Real Human and go nuts on it. Meaning no offense, from the last several posts it sounds like you're having a stressful time with interviews in general. Have you tried doing a mock interview and getting feedback from that? It can help when you get practice in a situation where there isn't something riding on it.
|
|
#
¿
Jun 29, 2016 23:32
|
|
|
Cuntpunch posted:I guess for a guy who talked up how much he was just fascinated by the tech - how he spent lots of his personal time working with and around it, it just felt very weird to not be able to get into a *technical discussion*. In my experience this scenario isn't that unusual when it comes to interviewing. The "fascinated by tech" story is easy to fabricate when you're trying to show that you're not just another worker drone, you're really interested. Good for you for probing deeper into things and discovering that it was masking a lack of depth.
|
|
#
¿
Aug 10, 2016 13:44
|
|
|
Asking a candidate about the potential consequences of delete this; is a perfectly good C++ question  #define struct...not sure where they might have been going with this, maybe wanting the candidate to recognize that #defines are just text replacement so if you and the files you include don't ever use the word 'struct' you'll be fine?
|
|
#
¿
Aug 23, 2016 15:00
|
|
|
|
| # ¿ May 9, 2024 21:34 |
|
|
hobbesmaster posted:You can use it anywhere technically, https://isocpp.org/wiki/faq/freestore-mgmt#delete-this You couldn't use it in a non-member function because this isn't defined. Sounds from Mr Moo's response like that's the (bad) question that was being asked. I have written code a couple of times where delete this; was used but each time I ended up redesigning in such a way that it's not necessary. It's unexpected behavior for an object to commit suicide in C++ so IMO it's best avoided unless you absolutely positively can't hold on to an owning pointer with a reasonable lifetime.
|
|
#
¿
Aug 23, 2016 15:52
|
|