Hacker Newsnew | comments | show | ask | jobs | submit | shioyama's commentslogin

Happy to see that ruby (2.0 at least) passes all the tests except the "baffle" one.

Edit: sadly, it doesn't.

-----


If you're using Rails, the ActiveSupport::Multibyte::Chars library (#mb_chars on any string) passes all these tests except the upcase of baffle:

  irb(main):001:0> RUBY_VERSION
  => "1.9.3"
  irb(main):002:0> Rails.version
  => "3.2.14"
  irb(main):003:0> # example 1
  irb(main):004:0* example1 = "noe\u0308l".mb_chars
  => noël
  irb(main):005:0> example1.reverse
  => lëon
  irb(main):006:0> example1.compose.slice(0,3)
  => noë
  irb(main):007:0> example1.g_length #grapheme_length
  => 4
  irb(main):008:0> example1.compose.length
  => 4
  irb(main):009:0> # example 2
  irb(main):010:0* example2 = "😸😾".mb_chars
  => 😸😾
  irb(main):011:0> example2.length
  => 2
  irb(main):012:0> example2.slice(1,1)
  => 😾
  irb(main):013:0> example2.reverse
  => 😾😸
  irb(main):014:0> # example 3
  irb(main):015:0* example3 = "baffle".mb_chars
  => baffle
  irb(main):016:0> example3.upcase
  => BAfflE
  irb(main):017:0> # example 4
  irb(main):018:0* example4 = "noël".mb_chars
  => noël
  irb(main):019:0> example4 == example1
  => false
  irb(main):020:0> example4 == example1.compose
  => true

-----


    "noe\u0308l".size # => 5
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin13.0.0]

-----


Ah, oops. I read the post too quickly, now I see the problem.

-----


"noe\u{0308}".size => 4

You code is wrong

-----


You forgot the "l":

    "noe\u{0308}" # => "noë"

-----


I've been using names from the Mr. Men series of books, so e.g. tickle, grumpy, topsyturvy, daydream. Easy to remember because the characters are each so unique and different, and gives each machine its own personality: "Oh crap, grumpy is acting up again", etc.

-----


Another one I discovered recently: http://xbreaker.github.com/plusstrap/

-----


20 years ago, if you had told people that the world's most widely-read source of general knowledge would go out of print and be replaced by a website editable by anyone, anywhere, people would have said you were crazy.

But that did happen. Yale may not "go out of print", but I don't find it hard to imagine new online schools competing and winning in the battle to redefine education.

-----


> Learning the techniques of design without the basics is like trying to be a writer by learning all the functions of MS Word but not having read Shakespeare.

You can be a perfectly good writer without having read a word of Shakespeare.

-----


Do you really think you can be a good writer without having read any good writers?

-----


I didn't say any good writers, I said Shakespeare. There are many routes to becoming a good writer.

-----


That's a feature of Compass, not Sass.

http://compass-style.org/

-----


More accurately, SASS includes the ability to create functions to build out prefixes, and Compass includes default functions to do this.

-----


Yeah, we do this with SASS without using compass.

-----


I stand corrected. I think though that Compass is the most common way people do this.

-----


No language hate - but are there similar projects that don't require a ruby installation?

I'm currently playing with a very, very small environment. I might want to check out a (powerful) css preprocessor project, but it feels wasteful to add a dependency on an otherwise unnecessary (for my work/projects) language. Alternatives? Suggestions?

-----


And Stylus with Nib - I don't believe they do the lighten / darkening of colours however.

-----


Actually, lightening and darkening are built-in functions in Stylus:

http://learnboost.github.com/stylus/docs/bifs.html

Stylus is amazing

-----


You may find my Stylus plugin useful: http://boronine.com/colorspaces.js/

-----


How do Stylus+Nib compare to Sass+Compass, in your opinion?

-----


They are both awesome and compare quite well :D I think its mostly a question of the syntax you prefer (and possibly the way you'd like to manage the dependency, with ruby gems, npm, or manually).

-----


IMHO Stylus is an overall win over SASS. The ability to write transparent mixins for my team (made by people not wanting to know how to implement `display:inline-block` on IE) is so great I can't be happier.

I've been able to completely replace SASS on Liferay [1] themes development and raised my team's productivity a lot.

[1]: http://www.liferay.com

-----


I left a PhD program a few years back (technically graduated, but I don't think of it that way). A year or so before I did, I remember very clearly being out to drinks with my professor and fellow students, and mentioning that I had no intention to continue a career in academia. In fact at the time I was thinking of translation (I've since drifted to web development, but languages and translation are still central to much of what I do).

The response (in Japanese, but I'll translate) was "what a waste" ("mottainai"). What a waste. All that potential I had, and now I was just going to waste it on "work", like everyone else. No doubt my supervisor, who said it with a genuinely disappointed look (echoed with a nod by a fellow student and friend sitting beside me, which only made it worse) meant it in a positive sense, but I never forgave him for it. It stuck with me, somewhere very deep inside me, first as something confusing and distressing, then as a kind of symbol, something emblematic of everything that is wrong with academia.

To anyone who is hesitating: if your only reason for staying in academia is the fear of what will happen if you leave, then it is time to leave.

-----


As someone who has not yet worked professionally as a programmer (nor hired one), I might not be the best person to comment on this article (so take what I write with a grain of salt). But as someone aspiring to do so, I find this article and others like it on HN frustrating.

For one thing, as mbenjaminsmith noted, for small (and I'd argue medium-sized) companies, setting up so many hoops for a programmer to jump through doesn't strike me as a very smart strategy -- you'll likely end up with very few candidates. But more importantly, the "hoops" listed in the article mostly filter for a particular type of candidate. In fact, the whole "jump through hoops" approach to hiring itself frustrates me -- not because I don't think I could jump through them, but because of the place I would end up in if I did.

I come to programming with (what I consider to be) a fairly diverse background. One of the things that I immediately sense in recently having crossed over (in my free time, currently) into coding and into the profession of coding is how homogeneous the community tends to be: on the surface (for example) almost exclusively male and dominated by a relatively narrow demographic, but deeper down also lacking in a diversity of life experiences.

I would argue that the process described in this article is partly responsible for maintaining this lack of diversity, by the simple fact that it encourages the "hoops" mentality.

Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny? I have no idea. Can I find the largest int in an array? Sure, but why in the world are you asking me this?

And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons?

People have such a diversity of skills and experiences. Sure, a portfolio can express some of this. Selecting from your community (#3) also strikes me as very sensible. But to find the outlier candidates who have broader potential and knowledge of problems outside the "canon" of standard programming practice, I think you have to take a more open-ended approach.

In the end, I guess maybe the problem for me is that the whole "How to Hire a Programmer" idea itself strikes me as somewhat misguided. A guide to "hiring a <fill_in_the_blank>" is only ever going to filter for cookie-cutter representations of <fill_in_the_blank>, whatever that profession may be.

-----


> Why do programmers think asking if Oct 31 and Dec 25 are the same day is funny? I have no idea. Can I find the largest int in an array? Sure, but why in the world are you asking me this?

The first question is silly. It's probably intended as a shibboleth, but it's a pretty useless one: people who can answer it probably understand what is octal/decimal/hex, but lots of people who do know octal/decimal/hex have never heard of that silly joke.

The second question is very easy and it's good as a first filter: if you can't answer it then it's very very likely you cannot code. They're asking it because there are indeed people who interview for that position yet cannot answer it.

> And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons?

I think the 1/200 ratio is rather hyperbolic and not based on any actual data. In my experience interviewing candidates for a not very well-known company (so we didn't have 1000s of candidates for every position, more like dozens), more than 2/3 of the candidates would pass the really easy questions.

But yes, if the candidate fails Fizzbuzz then it's probably pointless to continue the interview. Of course the candidate might have other skills, but we're talking about interviewing for a programmer position.

-----


Thanks for the context.

> But yes, if the candidate fails Fizzbuzz then it's probably pointless to continue the interview.

I didn't really mean to imply that basic programming skills are not a prerequisite for a programming job, which I guess is what the second quote of mine above seems to imply. What I'm saying is that testing itself shapes the type of candidates you'll get, not just in the way that testing is meant to (i.e. screening out the ones that are not qualified) but also in other, unintended ways.

If the first thing you do in your interview is check if I can pass FizzBuzz, what does that say to me about your company? Tests like fizzbuzz are so uninspiring and uncreative. Aside from the fact that some strong candidates may just blank on them even though they can program fine, the deeper issue is that testing in this way says to me as an interviewee that you see candidates in terms of black-and-white "testable" skills.

-----


> In the end, I guess maybe the problem for me is that the whole "How to Hire a Programmer" idea itself strikes me as somewhat misguided. A guide to "hiring a <fill_in_the_blank>" is only ever going to filter for cookie-cutter representations of <fill_in_the_blank>, whatever that profession may be.

If your team needs a programmer, and you're looking to hire a programmer, then it doesn't matter how knowledgeable, well-rounded, or otherwise interesting someone is, if they're not actually capable of programming.

I don't think anyone would consider it a failing of the interview process if they were looking for an accountant and their hiring process weeded out the people who couldn't actually do accounting.

-----


> I don't think anyone would consider it a failing of the interview process if they were looking for an accountant and their hiring process weeded out the people who couldn't actually do accounting.

Not to knock the accountants, but I think programming involves a lot more creativity and open-ended thinking, and I'm not at all convinced that a focus on "hoop"-like testing brings out those aspects of a potential candidate.

(As noted in my other replies, I didn't mean to imply that programming skills are not important for a programmer to have.)

-----


> And FizzBuzz (linked in #1): yes I get it, it's easy and it filters out 199 out of 200 candidates, but what about those 199 other candidates? Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons?

No, absolutely not. If you cannot code fizzbuzz or find the largest int in an array, you will not succeed in a job where you have to program computers (regardless of whether "programmer" is the job title).

It should be mentioned that fizzbuzz is not about your ability to write perfect code down to every last semi-colon in the first pass on the whiteboard or your ability to navigate a maze of secret trap-doors, it's about checking that you know and understand "for" and "if". That's all. Really. I'd be happy to explain modulo to you if that's the problem. If you have a bug in your code, I'll give you hints, not do my evil cackle and fail you.

-----


In hindsight I think I ended up emphasizing the wrong thing in the quote above. Of course being able to handle "for" and "if" is going to be a prerequisite to any programming job, I'm not disputing that. Maybe FizzBuzz is a good test for that, assuming the candidate doesn't go blank under pressure and that the tester is someone as understanding as yourself, willing to give hints to fix bugs, etc.

But the test itself is not neutral: it sends a message about the employer's priorities, conveys an image of what the ideal candidate should be. It really doesn't matter if the employer thinks of it as merely a screening test. Once you're testing something, you're making a statement.

And as a statement, "tests" like FizzBuzz are pretty off-putting and uninspiring, to me at least and (I think) to a lot of potentially strong candidates. I can see that in a large company with thousands of applicants, this kind of thing is handy as a way to cut down the numbers, but I don't get the sense (in general) that the costs of doing things this way are considered or debated enough.

-----


So, we administer an online coding test that's similar in complexity to fizzbuzz, but a different problem. If you come to us through a personal reference, we skip the test. If we come to you, because we've learned about you, we skip the test.

If you come to us, and we don't know each other, you'll expect to be screened. Why would you not prefer writing a tiny bit of code, rather than do the "guess what we want to read on your CV" game? Especially when we tell you it's actually a good filter?

-----


> If you come to us through a personal reference, we skip the test. If we come to you, because we've learned about you, we skip the test.

Sure, and how about add to that: if we can (reliably) evaluate your skills based on work you've done, we skip the test. That together would already significantly cut down the number of people who would have to take the test, no? And I can imagine other ways to cut it down further.

> Why would you not prefer writing a tiny bit of code, rather than do the "guess what we want to read on your CV" game? Especially when we tell you it's actually a good filter?

It's the aggregate result of testing like this that bothers me. I'm just not convinced that you can write a "good filter" in the format of fizzbuzz, by which I mean a filter which does not result (as a side-effect) in attracting (and favouring) a certain type of candidate, with a certain way of thinking and world view -- beyond what you are actually explicitly testing for.

Maybe that's a worthwhile trade-off for a large organization which has to deal with huge numbers of applicants, I understand that. But for smaller companies and startups, where creative thinking and original ideas, problem awareness etc. are important, I just can't see how fizzbuzz-like tests should be a priority.

-----


What's the aggregate result of testing for fizzbuzz? If you pass you go to the next stage, if not, you're out? The point of fizzbuzz is that it is so simple that if you are capable of any programming at all, you cannot not pass it.

When I say "filter", I'm talking about a negative filter: It will sort out the ones that can't program at all, it won't say anything at all about the ones that can.

Perhaps 1 out of 200 is a little high, someone else mentioned 2 out of 20, which is probably closer to home for us. In order to give as many as possible of the 20 a fair chance, we need the 18 rejections to be as effort-efficient as possible. Evaluating a strangers Github portfolio is significantly more work than evaluating his answer to a problem the evaluators are familiar with.

Your assertions about start-ups, large companies and creativity confuse me. We are slightly larger than a large start-up, but we very much want and screen for creativity, ideas and problem awareness. But if you can't code a solution to the very simplest imaginable of problems, we do not want you, and I don't see how it's not suicide for a start-up to think differently.

The biggest difference in this regard between us and a start-up is that we have had some time and resources to develop, tune and make consistent our recruitment process. Do we miss good ones? It would be weird if we didn't. But a bad hire is orders of magnitude more damaging than missing a good hire. And that's twice as true for a start-up with smaller resource buffers to absorb the damage.

-----


> What's the aggregate result of testing for fizzbuzz? If you pass you go to the next stage, if not, you're out? The point of fizzbuzz is that it is so simple that if you are capable of any programming at all, you cannot not pass it.

My assertion is that an aggregate result of fizzbuzz and co. is to narrow the field in areas other than what you're explicitly testing for.

"It will sort out the ones that can't program at all, it won't say anything at all about the ones that can." <- yes, and it will also say a lot to all candidates (for good or bad) about your priorities in hiring. Maybe that's fine, but for me at least (and judging from other comments in this thread, others as well) it would be a turn off. So you would potentially lose me and others as candidates, even though we would pass the test. That's my point.

> But if you can't code a solution to the very simplest imaginable of problems, we do not want you, and I don't see how it's not suicide for a start-up to think differently.

I'm sure you know much more about hiring for startups than I do. But in a very general sense, I don't see screening tests as encouraging creativity, if anything they do the opposite. Others have made similar points in this thread. Maybe they're necessary, but they have costs.

I see your point though about a startup not having the same resources to absorb the damage from a bad hire.

-----


> Is it not possible that among them, you might have missed other candidates whose broader set of experiences would have taught you something that you didn't know, something more important than the fact they failed FizzBuzz, for whatever inconsequential reasons?

Sure, it's possible, but that's the best case scenario. What makes you think it's more probable than the alternative? Hiring someone who cannot program for a programmer role seems to have many potential drawbacks, have you considered them? When your money is on the line, you either learn to make decisions based on probabilities and expected values rather than mere possibilities, or you lose your money with high probability.

-----


> Hiring someone who cannot program for a programmer role seems to have many potential drawbacks, have you considered them?

My problem is with the focus on testing, I didn't mean to imply that programmers don't need to have basic programming skills. The quote above was misleading -- sorry about that -- see my clarifications in other replies.

-----


Worth thinking about it, the thing with the homogeneous nature. Also important during imterviews for programmers or engineers is if they know the market and / or product. It's quite a difference if you developing an iOS app game or some fancy cloud based ERP-sofware. This example works equaly well with ICE drive trains for cars or helicopter rotor blades. Programmer ain't euqal programmer. But that would mean that a trial project actually could help... I should think about it...

-----


I've been living across an ocean from my family for over 10 years, deactivated my FB account 2 years ago and never turned back. So I really don't understand your "ridiculous to even consider" -- there are many other ways to keep in touch, and doing without the firehose of low-quality information (wall posts, movie recommendations, etc.) pouring through FB gives you more time to focus on the high-quality information that can be better communicated through other media (phone, email, etc.)

I understand that leaving FB (or never using it) is not for everybody, but "ridiculous to even consider" goes way too far. I think actually it would be great for a lot more people to consider it, even if they end up deciding not to actually do it.

-----


I meant it would be ridiculous to even consider in my circle of friends.

Facebook is used by everyone I know because it is convenient. It is easier to chat with people, message them, and post photos to them, on Facebook that it is to email individual people. e.g. if someone posts a photo we can all comment on it and discuss it together. With email this is not really possible.

The only reason a lot of my friends have email accounts is because they need one to sign up to online services like Facebook. They do not even check email. It is just a box with thousands of unread friend requests and spam messages. That is why it would be ridiculous to consider quitting Facebook for me. I would be cutting myself off. Obviously I would still keep in touch with friends via phone but we would engage a lot less.

-----


It's not my case, but I've heard from some people that they got on Facebook because friends where organizing events there and not having an account meant not being included in these events. This might be a case where it's "ridiculous to even consider".

In the end it depends on the ways people use it. If it's the only channel for communication, then you have to be in it.

-----


You just have to be cool enough so that people start thinking "how can we organize the event so that X will also show up". Problem solved :-)

Another question: do you really want to meet people who would exclude you from an event just because you don't have a Facebook account? Friends don't exclude friends...

-----


You seem to assume it's on purpose. When almost everyone in your circle has a Facebook account, it's easy to forget that person X or Y doesn't (usually depending on how close a friend they are with them).

Personally, I don't miss my account, but I can understand why others can.

-----


I was going to post something similar. Glad to see I'm not the only one who felt that line stood out.

-----

More

Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: