I always found this interesting. For the designers that simply cannot write HTML code to reflect the desired design. What tools are they using to get the job done? Are they just taking existing templates and "hacking" it together?
Because Instagram can make whatever TOS they feel is necessary when they are interacting with your data.
You are using Instagram's servers and products display data. Therefore they can, essentially, do whatever they want with said data if you agrees to their TOS. Why do people still feel they have some recourse when you are volunteering your data to a private company in a public domain?
Not sure why you getting downvoted. It appears that anyone with an opinion which is not inline with the general consensus gets downvo... Nevermind..
In any case, I think the idea that true happiness comes from within, which I think is what your describing, makes sense. True happiness cannot be manufactured by buying "experiences". I don't think a laundry list, created by someone other then you, of things to do with your money can make you happy with yourself. If your not happy with yourself nothing you experience will just make you happy.
It starts with you and I'm not sure that money can buy you internal happiness.
A better idea would be to find out how people without money are able to be truly happy. I'd love to see that list...
I have known homeless artists, poets and musicians who were much happier than some very wealthy people I've met. Creative endeavors are the most common, with lots of genuine friendships being high on the list as well.
Their whole hypothesis is that money can buy happiness, but there is a weak correlation because people have poor consumption patterns, and if people just had better consumption patterns, money would correlate strongly with happiness. There are a couple of assumptions baked into this hypothesis that I can tear apart on the spot:
1. This assumes that consumptive happiness is additive and unbounded, i.e. if consuming A makes you X points happier, and consuming B makes you Y points happier, consuming A and B makes you (X + Y) happier, ad infinitum. There is no evidence of this, and this is such a strong assumption that to assume it in the absence of evidence is fallacious.
2. Their data surrounding giving does not control for interpersonal interactions, and personality characteristics. Since these two variables are both strongly confounding, their results are weak at best.
Beyond that, this is a review paper containing no new data. They are essentially taking isolated data points and playing connect the dots to generate their own pet hypothesis.
My "pet theory" of happiness is actually the distillate of the idea of happiness as established in a variety of neutral literature (from Aristotle to moderns like Layard and Lyubomirsky), informed to a degree by evolutionary biology. Do you really trust the impartiality of people publishing in journals for "Consumer Psychology"? That reminds me of health studies commissioned by cigarette companies.
Down-vote away, it only saddens me to the degree that it makes people less likely to be exposed to a dissenting but informative viewpoint. I don't care a whit for the popularity contest aspect of it.
Since your account is only 84 days old, maybe you're not aware that jokes are generally frowned upon and will usually get you down voted. Live and learn :)
A wise man once said "Nothing is original. There is nothing new under the Sun. It's never what you do but how it's done".
While I agree that saying "My Product X is like Y on steroids" is somewhat unoriginal and maybe even uninspiring, the simple fact is that every idea is pretty much an evolution of a previous idea.
That being said, I'm not to sure what the point of the article was :)
Sometimes I feel like it's a total crap-shoot with getting interviews at some of these large companies. There were quite a few positions available in the DC Metro area that I was probably more then qualified for or at least qualified enough to get a phone interview. Needless to say, I was never contacted. It's good to know that some people actually get to a phone interview :)
The big companies get so many candidates that they can't possibly do all applications justice. So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen.
"So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen."
This is probably the best piece of advice you can give for starting the job application process. Having an internal person already working in the company recommend you to HR will immediately put you on the top of the queue. At the very least, you'll get an initial phone interview quickly. This is, in fact, the only way that I've able to have successfully get in the door, at both small companies and also larger companies like Google and Microsoft.
The other option is the "career fair", but that tends to only work if you're still a student or near-student status.
Do you really want to be subjected to coding on a whiteboard?
Edit: Instead of down-voting, why don't you explain to me why you would want to code on a whiteboard when it's completely pointless. Might as well throw in some of those pointless questions like why are manholes round?
Whiteboard coding is good because interview questions are not about specific 100% solutions to complex real-world problems like programming usually is. Interview questions are about general problems whose solutions will fit nicely onto a whiteboard. You lose the ability to get realtime syntax highlighting, but you gain the ability to have multiple trains of thought, the ability to draw diagrams and arbitrary symbols, and the ability to point at things as you explain your thoughts to the interviewer. Do you really enjoy it when someone comes over to your laptop to ask you a question about code? Now imagine that for four hours in a row. That's what a laptop interview would be like.
When I was interviewing at Google, someone asked me a question that required me to remember some math. I did not remember it, but I knew how to derive the answer I needed. So I went to another whiteboard, talked my way through the sub-problem while drawing some math symbols, and then transferred the answer back to the original problem, halfway completed on a different whiteboard. Try doing that while hunched over your laptop.
I agree that this process is nothing like the job you're interviewing for. That's because it's an interview, not the job. We try to get a picture of who you are and what you know in a few hours, and that's just not enough time to let you loose with a laptop to see how you approach real-world problems. Not to mention, real world problems don't often involve much "computer science" knowledge. But you still need to know that so you can confidently attack problems that venture into that area.
And largely, the process works. There are very few programmers at Google that can't program. If I have an idea, I can explain it to pretty much anyone, and get good feedback. At other jobs I've had, I've had to explain thing like arrays to coworkers. That means I'm not going to get any feedback on my complex idea, and that sucks. Google is not like that, because we filter those people out at the interview.
Not too long ago I would have agreed with you, but I've recently changed my mind. Coding on a whiteboard is not completely useless:
1. It's a good indicator of how much you know for simple problems.
A few weeks ago I started helping a friend with a particular language and framework. He claimed to know it, having read several books on it. So I said great, go to the board and write a function that adds two numbers together. And he couldn't do it. Who knows, maybe he could have done it on a computer? Maybe he would have Google'd it quickly, or relied on code autocompletion, or the muscle memory from his fingers typing it, etc. But that's not what I wanted to know. Anyone who's written thousands of functions in a particular language could write a simple one like this on a wall, using paint, while hanging upside down. His inability to do so told me: he is not well-versed in this language. PERIOD.
2. You can practice.
"So what", you protest. "Google isn't going to ask simple problems. They'll ask hard ones." And maybe they will. And maybe having to solve it in a foreign way really will fuck you up. But my question to you is: If you know you're interviewing at Google soon, why the hell would you allow whiteboard coding to remain foreign to you? If you suck with whiteboards and you care at all about getting the job, then buy one and practice solving problems on it. Why would Google want someone who doesn't care enough to prepare for their interview? It's not that hard of a skill to pick up. And I daresay it will make you a better, easier-to-communicate-with programmer.
If there was one thing I could tell all applicants at Google, it's to read up on the process, and practice. There is a huge amount of information out there[1]. I feel sad interviewing really smart, capable people who could have breezed through with just a few hours of review and practice.
I imagine it must feel horrible interviewing smart people who would do great at work but whom you are unable to hire due to arbitrary hoops set up by your own company.
> 1. It's a good indicator of how much you know for simple problems.
Google doesn't solve simple problems.
> 2. You can practice.
Maybe if the interviewee was still in college they could "practice" coding on a whiteboard, but considering they may have other obligations like family and work they probably won't have time to practice such a pointless skill.
Personally, I wouldn't need to practice in the first place as I interview extremely well and could easily code on a whiteboard, I just find it antiquated and pointless to do so which was the reason for my comment - not because I am bad at it.
Yes, but that doesn't mean you don't need to know how to solve them. If you can't solve simple stuff, you won't be able to solve hard stuff that depends on knowing the simple stuff cold.
they may have other obligations like family
and work they probably won't have time to
practice such a pointless skill.
Yes, that's a possibility. But once again, if you're Google, you're getting 10s of thousands of applications a week. You can afford to set the bar as high as possible. Every Google employee I know regularly works 10+ hour days there, and sometimes does work at home, too. If you have two applicants of similar skill, but one has more free time to devote to your company, it's obvious who you'll prefer.
I work at Google. We write (diagrams and code) on whiteboards on a regular basis. We don't ask you to do it during an interview because we're sadists, we ask you to do it during an interview because working here, you will be doing it in the course of your ordinary work.
Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
I worked at google for four months. That wasn't my experience at all. I ended up on a team that despite working in the same office, barely spoke with each other, rarely ate lunch together, lost 1 member for each month I was there, and I didn't even have a 1 on 1 with my manager until 3 months in when I asked him why he was having 1 on 1s with everyone else, but not me. It was the singularly most soul-killing work environment I've ever encountered. What is this strange concept of whiteboard coding and collaboration of which you speak?
The relevant job skill here would have been the willingness to do anything for the great pay and food. I wasn't and I had other employment options I chose after it became clear I would not be allowed to jump to another project anytime soon.
I love working at the whiteboard -- my best ideas come while working at the whiteboard. But writing code on a whiteboard during an interview bears little resemblance to the code/diagrams written on a board during day-to-day work.
Day-to-day work is necessarily collaborative and productive... Whereas when at the board in an interview one person knows the "answer" and is across the table testing the other. It's a completely different set of pressures and requires different skill.
Further, I must have one of those faces people pity because its often that when I end up at the whiteboard the interviewer wants to "help" me if I don't spout off the answer immediately (I've learned to at least start talking so they will give me a second to think). This sometimes entails them trying to lead me down a path which is not the way I would have approached the problem. I'm confused, they think I'm an idiot, now I'm flustered, could this interview go any worse?
I've learned to politely ask for a second to consider and usually that completely solves the problem. I've been successful in technical interviews -- but the idea that it's the same thing as when working out hard problems with team members seems a little silly?
... will typically code better with a keyboard and
editor than someone who relies on the keyboard
and editor to be able to code
The whiteboard sucks for problems for which you either don't know the solution, or for which you know the solution intuitively, but can't reproduce it line by line in successive order. In such cases people go back and forth, adding new functionality or correcting the existing lines to fit a new condition ... and this happens a lot for recursive algorithms. For instance I cannot reproduce the in-place QuickSort line by line, but I can work it out by evolving it from the basic idea, a process that takes a couple of minutes and a lot of corrections.
So you're basically encouraging people that rote-learn solutions and that line above is bullshit.
Leave room between the lines so you can add stuff. Mark it up as you evolve it. If you need to, you can rewrite the clean version on another part of the board. Better yet is if you can figure it out in your head before you start writing, becaus that will definitely make you a better coder.
> Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
That is very subjective and I'd love to see some evidence of this.
Once upon a time I was working with a psychologist who wanted me to do a take-home exercise. Knowing that I was a software developer and an excellent typist, she insisted that I perform the exercise while writing by hand. She said that it was because I would be using a different part of my brain when handwriting than if I were typing.
Which brings us back to the whiteboard interview. I ask: If I am correctly interpreting what the psychologist said, why force interview candidates to use their brains differently than they normally would while coding?
I can't downvote, but I fail to see what's the problem with "coding" on a whiteboard and why people are stressing out over it. When I interview people I ask them to write code on the piece of paper. All I'm looking for is a presence of a half-decent idea and them not using things like strlen() when iterating through a C-string in their doodles. The rest we will talk over. I never expect polished code on the whiteboard, it's always a starting point for a conversation that follows.
Yeah, it's just to see if a person understands that some basic pointer operations and that regular strings in C are "special" because of their \0 at the end.
do employers really expect candidates to right syntax accurate code on a whiteboard? I just always assumed that pseudo-code was appropriate. There are a lot of key strokes that my fingers know but my brain doesn't. It's very easy to get confused and thrown off your game.
do employers really expect candidates to right syntax accurate code on a whiteboard?
Yes they do. I've still got my Google 'Hire Squad' t-shirt somewhere (when you get trained on how to do interviews at Google you used to get a t-shirt) And they expect the interviewer to transcribe what you write on the white board into your feedback so that the hiring committee can read your notes and know what you're talking about.
You see the part you've missed here is that at Google, the person doing the interviewing has nothing at all with the person deciding if you should be hired. They interview you, using the techniques they were trained to use, they transcribe the whole thing like a court reporter, adding what color they can and a float between 0 and 4 (0 is 'run way', 4 is 'walks on water') And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.
Writing syntax accurate code on the white board is always a plus. Although one candidate on seeing the dozen different color markers, wrote both syntax accurate and colorized code. That was good for a chuckle (and strangely I think it got them points in the committee).
And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.
Doesn't most of the personality of the person get lost in this setup? I mean, hiring people purely on technical merits may sound fine, but I'm not sure if that makes for a very pleasant working environment.
Compatibility with Google culture is something that the interviewers are trained to look for. You can't do an interview until you've worked at Google for more than 6 months, for this reason.
I think the whole hiring committee removes a lot of biases that people may have and the end result, in my opinion, is a workplace that's a lot more diverse than any other I've been at.
I don't necessarily expect candidates to have perfect syntax for a given language. (there's a presumption that they would be able to look up correct syntax in practice) At the same time, if you're unable to express your ideas in something close to real code, it is a signal that you're not sufficiently familiar with the language you chose.
Excepting declaring funky things like arrays of pointers to functions in C, what competent developer doesn't know the syntax to his or her own best 2 or 3 languages?
There is a difference between forgetting to put a semicolon at the end of a line (totally harmless on a whiteboard interview), and not knowing that semicolons end statements in C.
Of course, not knowing say, part of the standard library, say the semantics of rand(), without a man page or Google search is much more excusable.
OR you can hand the applicants a laptop and allow them to write code, which is what they are going to be doing on the job presumably. or does Google develop their applications on whiteboards now? I'm thinking a Minority Report-esque digital screen that programmers drag/drop with voice activation to "code".
In all seriousness, I really don't get whiteboarding in interviews.
For whiteboard coding, I've always given interviewees their choice of programming language and have said, "Don't worry about syntax." For me it's more about how you approach the problem than whether you can spell correctly.
I code in a variety of languages and every time I use .indexOf(), I can't remember if it's (needle, haystack) or (haystack, needle). Of course, my IDE shows me the correct way and I go with it in 0.3 seconds.
On a whiteboard, if I were marked down for getting that the "wrong", I don't think I'd like to work for those kind of people anyway. I have no interest in memorizing the exact syntax of every standard library call in every language. When I can look it up almost instantaneously, my mental efforts are best spent elsewhere.
I think there is a difference between if you know the API the language provides and if you know the syntax of the language.
I don't care if they can't remember order of parameters, or really even the name of the methods. But if you can't write syntactically correct code without an IDE, it seems like a problem.
Probably depends on the employer. I've always asked people to write actual code, rather than pseudo-code, because I've found that a lot of pseudo-code I've gotten doesn't make sense or majorly glosses over things. (Think "and then a miracle occurs".)
But I personally wouldn't dock a person if they screwed up the syntax on a whiteboard coding interview - I really use it more as a way to extend the conversation. I do have the bad habit of correcting syntax, though, because I find it too distracting once I see it.
Coding syntactically correct code on a whiteboard is a waste of time. Drawing pictures, diagrams, and pseudocode while trying to solve a problem with others is a great way to get collaborative work done.
DC office is funny. It's so small it doesn't have it's own recruiters. The recruiters in Denver handle recruiting in DC. So if you want to interview, talk to them.
Also, if you do interview, keep in mind you'll have to travel to MV for a full day interview and also a full day interview in DC. Which is actually nice if you have the time; the DC team is so small that they want to be selective with future team members.
The DC projects were cool too, one was google code I believe, and the other was a tool to allow the collection of data sets such as water well tests in developing Africa, etc.
Google only hires 1 in 1000 applicants or so (at least that's what they tell you on day 1). Try not to take it personally that you failed buzzword bingo with their recruiters.
Perhaps someone should take a look at your resume to find out why?
I'm sure those who have wrote complex scripts would probably disagree with you.
Do you know what writing complex scripts in equally complex environments entails? I sure don't, therefore it makes me sufficiently unqualified to determine "meta levels" (whatever that means) for that skill.
Unless you are deeply familiar with both, i'm not sure how you can say one is higher then the other.
I hit the "reply" button to tell you that no, no amount of "complex scripting" is as mentally challenging as developing a Turing complete language.
But maybe you mean scripts as any program? In that case, I agree that developing things like, I don't know, database engines and file systems and such are equal in complexity to developing a language.
I suppose the only caveat is that those things are usually teams -- sometimes huge teams. A language is often a 1-man or small team effort.
I personally don't like the idea of "levels", especially with programming. IMO it adds to the "I'm better then you cause I do xyz code" mindset which seems to get adopted more and more each day. It actually almost turns me off and makes me not want to participate in the community.
Perhaps that mindset is more common among those in the valley or other tech "hot" areas. But around here, Washington DC, if you know People Soft and SharePoint you can easily command a salary ~130k salary. Knowing how to write your own Ruby implementation or js library gets you pretty much nowhere.
If you increase your skill/knowledge that doesn't hinder your ability to use PeopleSoft/SharePoint. It certainly expands your options. While you can get a good salary using those technologies, eventually they will be obsolete. When that happens, we'll start to see news stories posted on some future-HN about how older IT workers are being passed up for younger, fresher IT workers and how it is a biased industry. When in fact, its just a group of people who decided that sitting in their comfort zone doing their day-to-day was good enough and when it was time to move on, they couldn't find any other jobs that fit their particular niche they'd had for the last decade(s).
Or it could just be that the younger crowd is using the tech that is popular today, therefore they are in higher demand.
10 years from now some next best thing will replace Ruby and the cycle continues..
As in my original post, the issue I have is the concept of knowing how to write your own language being considered a HIGHER skill then someone knowing Sharepoint or visual basic in depth.
Who's right is it to say that my particular skill is better or higher then yours..
Knowing how hardware works, how languages are compiled/designed, how libraries are architected. It can only increase your knowledge of [insert technology here].
I think you're confusing "Levels" with A > B (A is better than B) when in reality the point is that: A comes after B. You must first understand B, then you can move on to the next level in your path of understanding programming.
Actually I've found that in Silicon Valley, no one cares about quantifying programming levels, and care more about what you did and what you know.
When I applied for jobs on the East Coast, they all seemed to want things like GPA (even though I'd been out of school for 15+ years), and especially results from programming tests like Brainbench.
Pretty much.. But my bubble is better then your bubble! :).
FWIW I am a "programmer".
This list also doesn't take necessity into account. Is "A" programmer better then "B" programmer if "B" programmer has never had to derive their own programming language while "A" programmer had this requirement or need?
