211–220 of 305 posts
Straight link to code as well: https://github.com/bluejekyll/palindrome-rs/blob/master/src/...
It was fun because I realized I have a different option than stacks and arrays to solve this problem now.
Earlier quoted context omitted.
5. Didn't meet the specification. You need to ignore white space and punctuation. 6. Didn't include any tests 7. Bonus! This function also returns true if you pass it a palindromic array! Er... Maybe it shouldn't do that.
I realise you are nitpicking. But when you ask a normal person who knows how to code to write a palindrome function, then this is what you will get. This function is too simple to expect anyone to ask you any follow up question regarding the "spec" unless they are trying to game the interview. Also note that the duct typing properties of JS are often used to allow such string/array ambiguities.
Very interesting article, thanks for writing! I have but one, eh, comment: > Your code should be commented Sure.. but: > * @param {string} stringToTest - the string to test. > // make sure we have a string. > if (typeof stringToTest !== "string") { > > function isPalindrome(stringToTest) { > ... > // if we get here, it's a palindrome > return true; Do we really need to explain that stringToTest means string to test?…
I came here to make the same comment (pardon the pun.) This article takes such an expert tone. But it's just opinion. For me, that comment would be a red flag. He also says to write the most efficient code possible. Then doesn't. See the comments at the end of the post. Overall, I think what this shows is that as an interviewee, the best thing you can do is try to get an idea of the interviewer's expectations as quic…
Radix sort is O(n) in log(dictionary size) which is only a useful bound when the data set is larger than the dictionary (this is a severe but not fatal requirement. Some datasets have many duplicate values, and anyway in practice log(n) factors in real world systems are practically constant factors: an 1log(n) algorithm will be slower than a 100(1) algorithm.)
You can misstate a theorem, or forget the proof, OK, but doing both is poor form.
Earlier quoted context omitted.
I felt when I was a student that some teachers just wanted everyone to know how clever they were and sometimes that could be achieved by putting someone else down. Someone who wasn't in a position to talk back. The good teachers gave criticism, pointed to the code standards for the course and were fair in their marking. The best teachers asked questions that made the students produce better work and took time to expl…
You can see my reply to the parent comment. I always sit down and talk with the students, but for us to talk about the code, we need to be able to read the code. Unneeded comments make it significantly harder to read code. First time we talk about why I don't want "the what" comments, only "the why" comments. If they still do it in the next handin it's a fail unless they've explicitly provided me with a reasonable re…
Your comment merits a failing mark, downvotes, because you made the same subjectively wrong statement twice.
Earlier quoted context omitted.
I have had a teacher that said you needed to comment every single line because that's how code is written in the real world. I told him he was wrong and argued with him on more than one occasion. In the end, I just did it his way because there wasn't a good alternative.
Sounds like a job for a perl(or whatever) script. Might be fun to do some light ad hoc parsing. Also, with that rule, I can't resist // this line left intentionally blank.
// this line left intentionally non-blank.Earlier quoted context omitted.
As someone that was a student until last year, the real hard problem is that we have teachers that want this type of comments. Having different standards for different teachers the same day is a lot of context switching... A better idea would be to get a standard code style for all course...
My school actually had standard coding styles for each language they taught. Naturally, they all wanted a metric fuckton of comments (luckily the TAs didn't care as much about the comments part of those guides).
Earlier quoted context omitted.
I've had students that did this. It's a real pain to read code like that, and the 2nd time they handed it in, it was an automatic fail. Comments explain assumptions, and often "the why", never "the what" unless it's obscure because of optimizations.
Why not run a parser that removes all comments over all code that is turned in. It's easier to read the code with no comments and if there are no comments the sections that should be commented really pop out (you can then check to see if there are indeed comments in the original file). Simplistic comments actually help a lot when learning (even if they are just a reinforcement). Quite often our students write the com…
Earlier quoted context omitted.
You don't want to pay 10 people for a week. You want to pay one person at a time over a 10 week stretch. That way, you can evaluate each candidate independently and hire the best one. This is undoubtedly a better approach than doing a bunch of coding interviews, so you should have a strong incentive to make sure you have the resources for it. After all, you want to minimize the risk of hiring mediocre people and maxi…
I don't know where you work, but I have never had the luxury of 2.5+ months to get a position filled if we can help it (and it's silly to assume that the work required behind the scenes to get this all working would result in no gaps between candidates, so more than 2.5 months). I also don't typically have the luxury of having great candidates in front of me who will wait multiple weeks to get into some weird one wee…
I once was taken almost completely away from my engineering duties for a period of a whole month to help almost full time with what was a "critical" position that needed to be filled "now". A year and half later, when I decided to leave that company, they still had not hired for that position, and had an endless list of why every candidates didn't make the cut (and we had interviewed some excellent candidates who got thumbs up from all of the technical staff who had interviewed them).
It's different everywhere, but in general for a competent tech worker with about 3+ years of experience, I'd say you're looking at at least 6 months to find someone, probably closer to a year, not because there fails to be a supply of good candidates, but because that's just the time penalty for internal politics.
While this particular anecdote happened at an established firm, I experienced nearly the exact same thing in start-ups as well, literally the same political bullshit excuses used to reject otherwise great candidates even when we were "desperate" to hire someone.
Earlier quoted context omitted.
I feel that regex is kind of like SQL -- it's universal enough that knowing the major tropes is important for general software development.
Problem is that every framework have their own dialect of it, and many of them are not even regular expression, but something beyond that.