Google does the same kind of software interviews as anywhere else. They aren't special. You code on a whiteboard and it's supposed to be compilable in C or Java. The process beyond that is just as subjective as anywhere else and is largely based on gut. They depend largely on employee references/friends.
The data they collect is really only to make the process more efficient, not more effective. They reward employees that process the most phone screens in a month. The strangest thing, in my opinion, is that the interviewers usually don't make a decision at all, they just give a rating. Then, a group of people who've never even met the candidate decide whether to hire them based on forms that were filled out.
| Google does the same kind of software interviews as anywhere else. [...]
| You code on a whiteboard and it's supposed to be compilable in C or Java.
It may seem like a strange idea, but not all places interview like this. The company I currently work for doesn't do this and the one I will start working for soon doesn't interview like this.
The reasoning is that my job is not to stand in front of a white board and write syntactically correct code without the aid of an editor or compiler, so maybe there is a better way to screen candidates that directly test the skills they will use on the job.
There's a difference between syntactically-correct code (meaning every single paren/brace is balanced, no dropped semicolons, should compile exactly as written, etc.) and what I call "valid" code. Expecting a candidate to write the former without an editor and compiler is silly.
A good interviewer (and good hiring committee) wants to see that you can write "correct-ish" code: it looks like it would compile modulo a typo or niggling detail, but the algorithm, data structures, and control flow are clear and valid. A good interviewer will also tell you that up front, e.g. "I'm interested in your code, not your syntax". If they don't, ASK!
The problem is: not everyone is a good interviewer, and it's surprisingly hard to teach someone to BE a good interviewer.
I think I agree with all of that. Especially the "interviewing is hard" part. But what's wrong with having someone sit in front of a computer to write some code?
At the company I'm leaving, we ask candidates to do a small project as a first pass. If the code isn't awful, we call them in to pair program with us (we're a pairing shop) on the code they wrote to improve it.
The company I'm joining just has you come in and pair (they're also a pairing shop) on projects their team is actually working on for most of a day.
I find both to be pretty good approaches. Better than having someone write code in an unfamiliar setting (the white board) to solve problems which are often, but not always contrived (write quick sort, etc.), at least.
We've had pretty good success with identifying good candidates since we switched over to this model and the place where I'm starting is a consultancy which is pretty well-regarded in the startup community, including HN, so they've probably had reasonably good success identifying talent.
How big are these companies, how many people do they hire per week, and how many do they interview? Any number of perfectly reasonable interviewing strategies in smaller companies fall apart at big-company scale (1000+ resume submissions per DAY)
Fair point. The companies are small and medium-sized. I'm not convinced that those models can't scale, though. One large-ish company that I know of who still does something similar is ThoughtWorks. They have on the order of thousands of employees and their interview process consists of, among other things, a take-home code submission and on-site pair programming.
If you're getting 1000 resumes per day, I think you would be able to weed out a significant number of them just by giving them a coding assignment to work on. Churning out a resume is easy, but sitting down for a few hours and writing well-designed code takes effort.
They probably can scale up to a point. Thoughtworks has 2100 employees. Google has 45,000.
How would you grade/score ~1000 code submissions per day, though? You could conceivably do Coursera/Topcoder-type automated grading, but that can only get you so far and can't distinguish good code vs. bad code vs. "copied from Glassdoor" code. It might be useful as an initial filter, though. You'd have to constantly be implementing new questions w/ associated grading scripts, though, as the problems would inevitably leak.
This isn't really true, you can use whatever language you want for the programming sections. If you say you only know PHP, they'll find you four interviewers that know PHP.
Interview feedback is not really "filling out a form", either. I take about 6 hours to write feedback for a 45 minute interview. It's very detailed and really covers a chronology of what happened during the interview. Interviewers also submit a hire/no hire score for the candidate, so it's not only the hiring committee that makes the hiring decision. If an interviewer is willing to say "this is the best person I've ever interviewed in my life", that's a big deal.
Yes, it is. We are mostly professionals here and understand the limitations of technology, specifically when talking about latency and implementations ranging from websockets to long polling. We look past these minutiae and get to the real subject of getting data to the user as soon as possible. Generically, this is referred to as "real time".
I actually wish we called this something else like say "persistent". Real-time systems have a very specific meaning for many people and while yes we all get it, it is probably a point of distraction for a lot of people to hear this term constantly misused.
Probably could be considered a competitor. This offers socket.io built-in, but doesn't seem to have the reactive data binding templates like meteor. This looks to be a Ruby on Rails for node.
There's a whole spectrum of users, as well. Programmers can be Python users, wherein the python implementation takes complexity hits to simplify it for the user.
It's all subjective, and the design of the high level concepts (maybe mechanics?) influence the complexity at every level below it. The idea of a 'file' goes from the GUI down to the hard disc format.
They don't, it's an illusion because the background is a flat grey and some icons are darker than others.
It's consistent because every icon has a gradient, even if subtle - in contrast with the original, where some are flat and others have a 3D effect from the gradient, and some even have a gradient on the opposite direction making a complete mess of convex/concave illusion on the home screen.
It's also consistent because all icons have just the right amount of detail. Compare the safari, clock, compass, notes, reminders, newsstand and passbook icons.
Lastly, he modified the margins back to the original proportions, which are better balanced. Compare the iTunes and App Store icons.
Seems like a disadvantage to me. It's mostly just confusing and the only thing it affords is the ability to use :keywords as functions (:like so) which is just sugar for property access, so["like"]. This is broken, though.
The coolest thing about :keywords in Clojure is that they really are functions and you can do things like (map :keywords ontoSomething) to extract the same property out of many things. It don't work in Wisp.
What you're not realizing, though, is that each time you use the string "like" as a key for a map/dictionary, you're allocating a new object on the heap. So what if you have many keys, and they're all strings? What if you have many maps that share the same keys? That's a lot of memory to allocate, and strings are an extremely inefficient way to implement what is essentially a unique identifier to address map values. Instead, use an integer as a unique identifier.
That's basically what keywords do -- they are human-readable and compile down (prob. using some hash) into some integer, and the integer is stored globally only once. The biggest savings in memory comes when using maps, and that's how & why keywords get their name.
Javascript strings are immutable and literals are almost certainly preallocated and stored in a table of constants.
Why should using a string keys cause heap allocations?
If you have a VM where strings are immutable and interned, you're right. Java doesn't guarantee that strings are interned (though you can ask the VM to intern it), so Clojure treats them differently.
Also, Java declared java.lang.String as final, so Strings can't be extended to implement clojure interfaces to get nice behavior, like IFn and IKeywordLookup.
I'd expect `(:bar foo)` to desugar to `foo["bar"]()` since the keyword is being used as a function. Property access in clojurescript uses the ugly `(.-bar foo)` syntax.
No, to get foo["bar"]() in CLJS you write ((:bar foo)). :bar in this case is a function, which returns a value by a key ":bar" from "foo", it's not a property.
This has been my experience with recruiters but once you get past the wall of pleasantries and fake attitudes, they usually talk with more sense.
Edit: Sibling comments are talking a lot about the author's personal motivating factors but are ignoring the bigger message of poor hiring tactics like repeating talking points and marginalizing personal goals. I got you, though, op.
I think he's asking how it got so obfuscated in the first place. Seemingly, the spammers could just pilot a standard up to date client with a bot, rather than try and figure out the protocol.
I'm sure it's more complicated than that however, like client side rate limiting or something.
I bet they would put the rate limit in the client, since they did that with the banned word list, but rate limiting would make more sense at the server. Maybe they did both.
Now you could fire up a new VM for each client or use a botnet to do your bidding. Oh, how the Internet has advanced.
