aplusbi

The author also says "Under a scientific framework, input from intuition, tradition, experience, common sense, experts, and logic might be incorporated during the construction of a preliminary hypothesis"

The difference is between:

    My intuition is telling me this is true.

and

    My intuition is telling me this is true.  Let me test it.

I think you are taking the article out of context. At best intuition leads to a hypothesis. By itself it is definitely not a source of scientific knowledge. The author even explicitly states this:

>Under a scientific framework, input from intuition, tradition, experience, common sense, experts, and logic might be incorporated during the construction of a preliminary hypothesis

The last time I checked there is nothing on github's TOS page stating that your code must be open source. You could, hypothetically, include a LICENSE stating that while the code is public, it is still copyrighted.

Of course, I'm assuming if you have legal/contractual restrictions against open source, those restrictions also apply to making code publicly viewable.

I work for a financial software company and we have a lot of projects so it depends, really. Recently we've been looking for some frontend Javascript developers the project I work on. The interviews we've been conducting have reflected that - mostly questions on things like JQuery/Moo Tools, having the candidate code stuff using AJAX, etc. "Real world" stuff in other words.

We often hire C++/C#/Python/Perl/Ruby/Objective-C/Java/etc (seriously, we use all those languages) to work on existing code bases. We work on Linux, VMS, Windows, iOS, and BlackBerry. We have plenty of "glue" code, frontend code and code that needs to deal with large amounts of data.

We don't expect recent graduates to have much coding experience. You seem to think that we have some strict checklist which is not the case at all. I really don't know where you got this idea. My initial comment was simply meant to answer the OPs question. I don't always ask those questions, I weight many things in my decision (including whether I think I conducted the interview well - sometimes it's clear that I've failed to properly describe the problem) and discuss the candidate with other people who have also interviewed them.

I think the best programmers are ones who can utilize abstractions while at the same time understand what they are abstractions of. For example, someone who knows Django and SQL is probably a better programmer than someone who knows Django but doesn't understand what a relational database is.

While people might not need to write searching and sorting algorithms much any more, understanding the difference between an ordered map and a hash table can be crucial in many common "real world" scenarios.

I also have tried to stress that the answers to my algorithm questions are only part of the criteria in determining whether we hire someone or not. I brought them up because the OP asked specifically about coding questions, not hiring questions.

Interestingly enough no one I've interviewed has every suggested lexicographical ordering although I have implemented it that way myself to see how hard it would be (answer: it's kind of hard).

That said, C++'s standard library has a next_permutation function that returns the lexicographical next permutation of a pair of iterators (actually it does it in-place and returns a bool). If a candidate used that I'd allow it (as long as there was some discussion as to how it worked).

I've since stopped asking that question and now stick primarily with the split array question as I think it's less tricky. There's more than one way to solve it and most of the solutions build up on simpler solutions which makes for good discussion. I also don't ask for actual code for that problem unless I get the feeling the candidate will understand the problem better by expressing it in code.

Part of our interview process is having the candidate code-review some really bad code. The only problem with it is that it is biased against students/recent graduates. I'd say close to 90% of student/recent grad candidates do pretty poorly on the code review question.

These questions aren't about "real world" situations, they are about problem solving and basic coding. Questions are good, as is a discussion on how and why these things should be implemented.

For the split array problem I rarely ask for code (only when I think it will actually help the candidate), it's just a discussion. It usually goes something like this:

    Candidate: Well I can sort it first, then do a binary search.
    Me: How would you sort it?
    C: I'd use quicksort.
    M: Can you do better than an nlogn algorithm?
    C: Well I suppose since it's two pieces that are both already sorted, I can just find where they are split and then rearrange them.
    M: How would you find the split?
    C: I can go through each number until they stop increasing.

And so forth. The "best" solution (that I've come up with, anyway) is to find the split using a modified binary search, and then use a regular binary search on the piece that might contain your query. Not everyone gets that and that's okay.

In addition to asking coding questions I always ask candidates about previous experience and projects they've worked on. Sometimes the answers to these questions are more important. Most of the people I have been interviewing, however, are recent graduates or students who are just finishing college and may not have much experience or many projects that really engaged them.

I spend a lot of time thinking about how I can improve interviews within the confines of how my company conducts them. I've stopped asking the permutations question as I feel that it has too much of the "aha!" factor in that either the programmer goes "aha!" and solves it or they don't.

Like I said, 80-90% of candidates can answer my questions. I am also very generous with what I accept as an answer and how much help I give. My interview is as much a discussion about the question as it is the solution.

As for what I get out of the interview - you're right, it's not going to tell me how good of a programmer the candidate is. But it will tell if they can code, and will give me some idea of their problem solving abilities. (I've also personally solved both questions without help in under 15 minutes each, though not under stressful interview conditions).

I think the key difference is the implication that Apple's sole intent is to make good products. The people at Apple just want to make damn good products. is very different from Apple makes damn good products.

I've been involved in a lot of interviewing/recruiting especially of recent graduates. I don't have hard numbers, but it seems to me that the candidates who have masters degrees tend to do worse.

I've never asked FizzBuzz but I do regularly ask coding/algorithm questions. They are usually more difficult than FizzBuzz. I'd say around 80-90% can at least come up with a solution in 45 minutes with some help. Probably less than 10% can come up with a good solution entirely on their own.

I attribute this to two things, first I think our phone screenings work well enough to keep out people who really can't do FizzBuzz, and second that I'm fairly generous during interviews. I often don't expect real code, sometimes I'm satisfied with just a discussion of the algorithm (no white board coding at all). I don't expect code to compile and I even let candidates use undefined "helper" functions (although I usually only allow that if I get the feeling that they could implement them if asked).

* For those that are curious I have two favorite questions - print out all the permutations of a given (ASCII) string and describe a search algorithm for a sorted array that has been split in two and the two pieces have been swapped (i.e. - 4,5,6,7,8,1,2,3).

I like Noise Bridge's guiding principle: "Be excellent to each other." (which is a quote from Bill and Ted's Excellent Adventure).

Most of the vitriol is coming from the "cool" generation. It boils down to narcissism of small differences - the author is uncomfortable with the idea that he himself may be a "hipster" and so looks for all the things that are hip that he lacks. He then makes sure to publicly point out how hip these things are and how he lacks them.

I myself have been guilty of this but I eventually realized my own hypocrisy and just stopped caring about it. I'm a cool twenty-something techno-hipster - not because I want to be so much as because that's who I am.

Almost, |> isn't an operator in OCaml (although I think Batteries has something like |- that does the same thing) and printfn isn't in OCaml. Printf.printf is, but wouldn't work in this case (you'd need a format string). Also, List.map returns a new list, in OCaml you would probably want to do List.iter.

This reminds me of the Richardson Spite House, which was 5 feet wide and built to block the windows of another property.

http://www.nyc-architecture.com/GON/GON005.htm

Those things sneak up on you! It's surprising how much cyclists and pedestrians rely on engine noise.

Pedantic here - while Mickey Mouse was created in 1928, the cut-off for public domain works is 1923. Also there was a long period of time where works needed to be registered (and re-registered) so there are plenty of works that have fallen into the public domain since 1923 (Night of the Living Dead being a prominent example).

Technically it's not the same thing. Whether or not it is legally different is an entirely different matter - one that has not yet been resolved.

If the court decides that encryption is like a safe then, regardless of how impossible it is to open the safe without a key, the court can coerce you into decrypting your HD.

However, if the court decides that encryption is like a secret language that only you can translate (a more accurate representation of encryption, in my opinion) then they will likely rule that they cannot coerce you into decrypting the data.

The thing is, the court can compel you to open the safe. You don't have to reveal the combination but you do have to open it (or face contempt charges).

This is pretty much the same thing they are demanding from her - we don't want your password, we want access to your hard drive.

The only reason you would want to do this is if you use the same password for multiple things. You may have signed up with some website a year ago, used it once and then forgot all about it. If they get compromised you might not even know it.

If you change your passwords often then you don't need to worry about this as much.

There are areas of Brooklyn that rival Manhattan prices, but generally speaking the further away from Manhattan you go the cheaper the rent gets.

I think the the fact that the dangers are mostly statistical is what makes Everest so dangerous. Not to make light of the difficulty in summiting Everest, but you can literally just hike to the top. This invites a lot of amateur climbers who lack the experience to even recognize dangerous situations, much less deal with them.

He has a tendency to blow things out of proportion and to air these problems publicly, using inflammatory language when most people would choose to use more direct channels.

All of the incidents I have read about have been legitimate problems, but I personally would have handled all of them very differently.

This particularly incident, for example, probably could have been solved simply by e-mailing github. In Shaw's case, he assumed they were in on it. I'm sure he had his reasons, and certainly the troll behind dongml gets no sympathy from me but I don't think blaming github and dragging them into this was appropriate.

Honestly I've never understood why some people (seemingly) defend him unconditionally. It sounds like he's a really stand-up guy in real life, but I'm still willing to call out my friends when I think they've gone too far.

-Niki Yoshiuchi

I don't know much about github's customer service,= but from what I can extrapolate from Shaw's rant, their service had a flaw which was likely just an oversight. Shaw never made an attempt to contact github about it (under the belief that they were in on it) and instead chose to exploit another flaw in their service and then angrily blog about it.

I don't see how that makes github "out of touch" nor do I see how this situation was created by a "general disregard of customer service." Granted this might be true, but it doesn't sound like it had anything to do with this particular incident.

I think you are misinterpreting section 6. Section 6 is about the requirements for software that use the library. Specifically section 6 is about software that statically links to the library (section 5 is about dynamic linking). If you statically link to the library, the resulting binary contains the library and you are required to provide object files so that a user can relink with a different (and hopefully compatible) version of the library.

In the case of Apple, they have made modifications to the library itself. They are then using the library, with modification, in Safari. Safari can be released under any license as outlined in section 5/6 but not the modifications. Those need to be released.

I understand your argument. My point was that revealing the gag order is not self-incrimination - it is committing a crime.

Technically speaking, you are only allowed to refuse to answer a question if you believe that answering will incriminate yourself.

While I suppose in practice this is true, I don't think the 5th amendment would technically apply. By mentioning the gag order you are not incriminating yourself but rather committing a crime.

The "time bomb" is mentioned in the video - handing over copyright on payment.