21–30 of 305 posts
On the flip side of things, I might prefer to see a candidate come up with something like this as first stab rather than that 35-line mammoth of an isPalindrome() function in the article. function isPalindrome(str) { return (str.split("").reverse()).join("") == str; }
def is_palindrome(str):
return str == str[::-1]One has to be good at programming, analytical skills, problem solving and communicating ideas. And after that a little research on how a company interviews should help. Even if someone reads all these books and cracks the interview, its very difficult to hold on to job with out the required skills.
> Let’s be honest, most developers don’t love having to write code as part of an interview process. Some have even threatened to quit the business over it. I actually prefer a coding interview over an interview with an unprepared interviewer, who is making up questions on the fly and expects the exact answer he/she has in mind.
If my job is largely coding, I expect to demonstrate coding abilities.
If my job is largely bullshitting, I expect to demonstrate bullshitting abilities.
And so on.
On the flip side of things, I might prefer to see a candidate come up with something like this as first stab rather than that 35-line mammoth of an isPalindrome() function in the article. function isPalindrome(str) { return (str.split("").reverse()).join("") == str; }
[Disclaimer: I run http://InterviewKickstart.com . It's a hyper-focused bootcamp on coding interview prep] Probably one of the biggest mistakes developers make, is to treat coding interviews like they are standardized tests with a checklist of evaluation. They are not. They are like a date. The other person is judging whether they want to work with you, more than anything else. No matter how good you are, you won't g…
I'd instead suggest that it should never get to the point of an in-person interview unless both parties have already applied the necessary culture filters. Sure, you could get surprised at the on-site and then change your mind, but you're just wasting a ton of your own time if you either don't properly vet the important culture properties aheadof time, or else sublimate away your own culture standards because you believe you have to appear conformist in order to get the job.
A good example would be open-plan offices. I have many friends in tech who deeply loathe the cognitive damage done to them by their employers forcing them to work in open-plan seating conditions. Yet they also are too afraid to either speak up or to reject employers who use open-plan seating, thus perpetuating open-plan dogma.
My perspective is that if an employer feels I'm worth the investment to bring to the team, they must feel that trivial other things to accommodate what helps me work best are also worthwhile. If, instead, a company would reject me based on "culture fit" for these side issue accommodations, or would refuse to grant them and try to pressure me to work without them, then in either case I'm dodging a massive bullet by either rejecting them or letting them reject me.
But one thing I should absolutely never do is to compromise on those issues (e.g. "no matter how good you are, you won't get into a long-term relationship ... if you don't conform"). If my goodness isn't enticing enough for them to not just make the offer but also think hard about what it would take for me to be happy with them and make it happen, then I'm simply better off staying away from them.
As it happens, a lot of companies don't really care about the goodness of their employees. They just want warm bodies who will conform to the company line. I understand that represents most jobs.
I'd like the future to be a world where that doesn't represent most jobs, so I boycott all such jobs, even if it means my search space is drastically reduced as a result.
It's just too cognitively unhealthy to human minds otherwise.
1. "On this particular challenge, I am expecting many will use RegEx as a part of the solution" Really? 2. "replace(/[^a-z0–9]/ig, '');" If I were interviewing and a candidate did this I would ask if he/she knows what i18n is
also are you seriously going to quiz someone about i18n for a interview? does that really tell whether they are a hire/no hire?
unfortunately not true with interviewers at other companies. they are definitely looking for the correct answer. if you can't "get" a problem, you are not getting an offer.
Is there even room on a whiteboard to write comments and tests ? Often there's barely even room to write readable code ... If you're writing in a shared text editor then sure. And isn't all the talking you do already commemts enough? Edit: I'm bad at reading comprehension on a mobile screen. The tests and comments bit is in a different section.
I am told that the unit-test kool-aid has taken over the universe of common sense, and I respond: "surely not", and then this...
My position w/ something like Fizzbuzz to any level of developer wouldn't require much in the way of either comments or tests (or, if embedded in a larger system, bugs would be flushed out quickly)
Do you disagree?
kill me now. are you testing for insight or implementation correctness?
a whiteboard is a place to draw a diagram, not code. see how they visualize and reason about strings would be better
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?…
'use strict'; // avoid ambiguity and sloppy errors