Everyone has his own coding style, we were rookies, and the teacher actually took the time to read through all our code. I suspect he'd known anyway.
I once graded (hand-written) homework assignments for a class of 150 students. It was incredibly easy to identify people copying off of each other, as long as you review everything in a single sitting. The best is identical grammar/spelling errors.
This is what happens whenever you let undergrads lose in a lab.
How ironic that this is the one time that "loose" is actually the correct spelling, yet "let[ting] undergrads lose" is still somehow appropriate to the topic.
This tech would kick ass in the studio, or perhaps the theatre or practice room
Maybe if you wanted a recording with a deliberately high noise floor (a.k.a. "crappy recording"), or a very distracting performance/rehearsal. I would say to RTFA, but it's not worth it anyways.
And the language type is rarely interesting- I want to know that the variable outsideTemp holds degrees farenheit, not that it's an integer. But Hungarian doesn't tell me that
Good Hungarian notation does exactly that, actually. Check out Apps Hungarian, which encodes the semantic type of the data, rather than the language-level data type.
Of course stupid Hungarian notation is stupid. Stupid anything is stupid. Problem is, most people don't hear about the right approach.
Hyperlinks are always GETs. The only way to get a link that POSTs is by using a hidden form and javascript that submits the form onclick... which is counterproductive.
You're missing the joke... GET requests look like this:
GET/url?a=b&c=d HTTP/1.0
POST requests look like this:
POST/url HTTP/1.0
a=b&c=d
Same amount of content... URL looks shorter, but the exact same data as the querystring gets sent inside the request body. Thus, switching from GET to POST does not alter the bandwidth usage at all, even if it makes the URL seen in the browser look shorter.
isn't it fun how the first tier of grammar nazis falls flat on their faces, when confronted with creative writing?
That's probably because creative usage of language is far outweighed by mistakes, and Occam's Razor applies. The logical response is to assume a mistake was made, until the author indicates otherwise (or demonstrates mastery of the language, as would be the case with established writers).
So, go ahead and be creative; but don't act astonished when people just think you're being stupidly.
What you see here is a classic case of trying to do something smart and cool but end up screwing up.
Actually, that particular atoi solution is pretty common as a baseline, and I would consider it neither smart nor cool; merely a good start. In an interview setting, I fully expect to follow up with the "interesting" details:
What classes of input will utterly destroy this function (NULL pointers, garbage pointers)
What classes of input will produce the wrong output? (negative numbers, overflow, non-digit characters)
What classes of output errors can you expect to see? (arbitrary numeric values, in this case... nothing particularly interesting; but some functions, such as the GNU atoi, fail in very predictable and thus detectable manners)
How would you test this function?
What are some of the differences between various interfaces for this routine (depends heavily on the language being used, but for C++ there are about 20 different potential interfaces that could be used).
Your QA/QC argument is a bit of a strawman, as an interview environment (and the expectations therein) are very different from a regular development envornment (which contains unit tests, functional tests, an entire QA/QC team, etc).
You're missing the point of the exercise. Get the simplest solution first. Adding support for negative numbers is easy to add once the basic algorithm is present. Validating for digits may or may not be relevant to any given parsing routine. In either case, that should be a followup discussion, unless you're actually hiring someone to reimplement the libc.
I'd have two counters, one being incremented from zero in a for loop (to max out at length($stringarray)), the other being initialized to the length of the string array and decremented each time through the loop. I'd then swap $stringarray[$forward_counter] and $stringarray[$backward_counter] each step of the loop
That's a common mistake. You want to stop as soon as your counters cross each other, otherwise you end up doing a double-reversal of the string.
The real doozies aren't the mistakes people make—many off-the-cuff solutions have trivial errors. But it's a good litmus test if someone either nails it right off the bat (pass), or if they waffle around without really getting anywhere (fail).
Your solution was definitely correct. However, starting from the back is a tad bit better if you already know the length of the string (how much will depend on the hardware, but it's generally not enough to worry about).
...some variation on a for loop with a counter of the size of the string array being decremented. I'm sure you can fill in the rest.
The funny thing is, I see people actually do that in interviews. They hand-wave the approximate solution, but if you push them to actually write the algorithm, they can't!
There's a certain amount of truth to the drummer screwing everyone else up. I've seen plenty of cases where a guitar or bass got off... stumbled for a few beats... and synched back up with the band. If the drummer does that, it's likely to confuse the entire band, and it will be more jarring to the audience (most of whom can't even clap on a 2 and 4). Essentially, the cost of a drummer/cowbell tempo mistake is much higher than the cost of anyone else screwing up, so it's more acceptable for the rest of the band to have shit tempo.
Think about it like NP-Complete problems. If you don't have the answer, it's probably going to take exponential resources to calculate it. If you have a possible answer, it only takes polynomial time to verify the correctness of the answer. While any prediscovery may not provide any new information, it will strengthen the validity of the existing information.
Keep in mind that at every company, HR is the enemy.
I've never had any beef with the HR where I work, and I am heavily involved in the recruitment process for technical positions. Be careful about your stereotypes.
It is fair to say, "Any key/value database will be at least as fast as any relational database", since one degenerates to the other. However, I find it quite easy to believe that there are a good number of optimizations that can be applied to a key/value database that don't apply to relational systems with foreign key integrity. There are more constraints, and more constraints usually leads to more efficient implementation. For an example, check out memcached.
Profiling in this way requires instrumentation, which would noticably slow down the browser. It's definitely not something you want to put in anything that gets distributed to end users. That, and the increase in data set size would only marginally improve the results.
"you know what that particular work is a studio pice; I thought was fun and my audience would appreciate its not something I can do live; without kit."
That makes me think about bands doing "unplugged" sets or variants to their songs. Everyone knows it'll be a little different from the electric or studio version, so it's accepted as being different.
...I'm not sure "ever again" needs to be part of the definition.
Every time I've ever heard the term "Bricked", the "ever again" has been the most significant implication. The term loses its meaning if you expand it to include any device that is currently not functioning.
Still different than vaporizing hundreds of people (both from an emotional point of view and from a practical one). You can bring aid to people who are without power. You can't do a whole lot to help out all the tiny bits of people spread about inside the husk of a football stadium.
...a botnet launching a DDoS on a few websites can cause as much damage as a terrorist bombing a bank. Probably more so.
Now, that all depends upon the monetary value you put on the lives of the bankers and bank customers. The fear from "mass destruction" is not necessarily the structural/financial damage, but the massive loss of human life that comes with it.
Re:Can we get back to the old definition of WMDs
on
Botnets As "eWMDs"
·
· Score: 1
Bah, useless word games! If I converted your house into carbon and water (via combustion), most people will argue that I've destroyed it.
Slashdot Mirror
I once graded (hand-written) homework assignments for a class of 150 students. It was incredibly easy to identify people copying off of each other, as long as you review everything in a single sitting. The best is identical grammar/spelling errors.
How ironic that this is the one time that "loose" is actually the correct spelling, yet "let[ting] undergrads lose" is still somehow appropriate to the topic.
Maybe if you wanted a recording with a deliberately high noise floor (a.k.a. "crappy recording"), or a very distracting performance/rehearsal. I would say to RTFA, but it's not worth it anyways.
Good Hungarian notation does exactly that, actually. Check out Apps Hungarian, which encodes the semantic type of the data, rather than the language-level data type.
Of course stupid Hungarian notation is stupid. Stupid anything is stupid. Problem is, most people don't hear about the right approach.
Hyperlinks are always GETs. The only way to get a link that POSTs is by using a hidden form and javascript that submits the form onclick... which is counterproductive.
You're missing the joke... GET requests look like this:
POST requests look like this:
Same amount of content... URL looks shorter, but the exact same data as the querystring gets sent inside the request body. Thus, switching from GET to POST does not alter the bandwidth usage at all, even if it makes the URL seen in the browser look shorter.
That's probably because creative usage of language is far outweighed by mistakes, and Occam's Razor applies. The logical response is to assume a mistake was made, until the author indicates otherwise (or demonstrates mastery of the language, as would be the case with established writers).
So, go ahead and be creative; but don't act astonished when people just think you're being stupidly.
Actually, that particular atoi solution is pretty common as a baseline, and I would consider it neither smart nor cool; merely a good start. In an interview setting, I fully expect to follow up with the "interesting" details:
Your QA/QC argument is a bit of a strawman, as an interview environment (and the expectations therein) are very different from a regular development envornment (which contains unit tests, functional tests, an entire QA/QC team, etc).
You're missing the point of the exercise. Get the simplest solution first. Adding support for negative numbers is easy to add once the basic algorithm is present. Validating for digits may or may not be relevant to any given parsing routine. In either case, that should be a followup discussion, unless you're actually hiring someone to reimplement the libc.
That's a common mistake. You want to stop as soon as your counters cross each other, otherwise you end up doing a double-reversal of the string.
The real doozies aren't the mistakes people make—many off-the-cuff solutions have trivial errors. But it's a good litmus test if someone either nails it right off the bat (pass), or if they waffle around without really getting anywhere (fail).
Your solution was definitely correct. However, starting from the back is a tad bit better if you already know the length of the string (how much will depend on the hardware, but it's generally not enough to worry about).
The funny thing is, I see people actually do that in interviews. They hand-wave the approximate solution, but if you push them to actually write the algorithm, they can't!
There's a certain amount of truth to the drummer screwing everyone else up. I've seen plenty of cases where a guitar or bass got off... stumbled for a few beats... and synched back up with the band. If the drummer does that, it's likely to confuse the entire band, and it will be more jarring to the audience (most of whom can't even clap on a 2 and 4). Essentially, the cost of a drummer/cowbell tempo mistake is much higher than the cost of anyone else screwing up, so it's more acceptable for the rest of the band to have shit tempo.
Think about it like NP-Complete problems. If you don't have the answer, it's probably going to take exponential resources to calculate it. If you have a possible answer, it only takes polynomial time to verify the correctness of the answer. While any prediscovery may not provide any new information, it will strengthen the validity of the existing information.
I've never had any beef with the HR where I work, and I am heavily involved in the recruitment process for technical positions. Be careful about your stereotypes.
It is fair to say, "Any key/value database will be at least as fast as any relational database", since one degenerates to the other. However, I find it quite easy to believe that there are a good number of optimizations that can be applied to a key/value database that don't apply to relational systems with foreign key integrity. There are more constraints, and more constraints usually leads to more efficient implementation. For an example, check out memcached.
Profiling in this way requires instrumentation, which would noticably slow down the browser. It's definitely not something you want to put in anything that gets distributed to end users. That, and the increase in data set size would only marginally improve the results.
That makes me think about bands doing "unplugged" sets or variants to their songs. Everyone knows it'll be a little different from the electric or studio version, so it's accepted as being different.
Every time I've ever heard the term "Bricked", the "ever again" has been the most significant implication. The term loses its meaning if you expand it to include any device that is currently not functioning.
Still different than vaporizing hundreds of people (both from an emotional point of view and from a practical one). You can bring aid to people who are without power. You can't do a whole lot to help out all the tiny bits of people spread about inside the husk of a football stadium.
Now, that all depends upon the monetary value you put on the lives of the bankers and bank customers. The fear from "mass destruction" is not necessarily the structural/financial damage, but the massive loss of human life that comes with it.
Bah, useless word games! If I converted your house into carbon and water (via combustion), most people will argue that I've destroyed it.
You're reading Slashdot from a typewriter?
Ah, you must use vi.