Microsoft patents lawful intercept on Skype - <AUTHOR> http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=1&f=G&l=50&d=PG01&p=1&S1=20110153809&OS=20110153809&RS=20110153809

<comment><USER2> C'mon, you don't honestly believe in 2012 that a conversation held over public networks using free software that embeds itself in every browser on your machine, watches your searches, automatically talks to the mothership every night, and keeps real-time track of your contacts, is actually private do you?

How do you think Free got to be worth so much?

<comment><USER3> By charging for Not Free services like multiuser video calling and providing extremely competitive long distance calls on the PSTN.

</comment></comment><comment><USER4> I feel the need to state what is probably already obvious to the HN crowd: Microsoft did not invent the idea of lawful interception. It is used in full force for both fixed and mobile networks, and select government agencies can call carriers to get records and do live wire tapping.

[http://en.wikipedia.org/wiki/Communications_Assistance_for_L...](http://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act)

<http://en.wikipedia.org/wiki/Lawful_interception>

Microsoft's premise is that the techniques used for VoIP are different then traditional lawful interception, but I don't think anything described in the patent is non-obvious. Nonetheless, they will probably get it awarded, as more then 50% of patent applications do (forgot where I got the statistic from), and even more when its from large tech corporations that have dedicated in- house patent lawyers filing the patent applications.

When you think about it, the USPTO gets money from awarding patents and collects yearly fees through the 20-year life of a patent, and the army of patent examiners they have on staff do not come cheap (starting salaries range from 52-79k), and for the most part they are self-funded and do not rely on U.S. Congress money - so there is every incentive in the system for them to award every patent applied for.

<comment><USER5> Patent examiner salaries are 52-79k? In Washington, D.C., the most highly paid metro area in the USA?

No wonder they can't manage to hire engineers who know any of the many technologies that have been around for decades and still get repeatedly patented every week. That's as bad as the continuing prohibition on admitting computer engineers and software engineers to the patent bar while software becomes an ever larger fraction of the case load.

<comment><USER6> Not to be confrontational, but where do you see that there is a "prohibition on admitting computer engineers and software engineers" to the patent bar? I have a CS degree, and work with plenty of others with software experience or computer engineering/software degrees, all of whom are admitted to the patent bar.

<comment><USER5> Last I checked there was a list of eligible engineering degrees and software engineering was not on the list.

</comment></comment></comment></comment><comment><USER7> Skype and Microsoft aside - what is there to patent to begin with? They effectively describe mangling the call setup to make the call go through a recording agent. This is _obnoxiously_ trivial.

</comment><comment><USER8> Someone found a way to bypass the PR dept to let you know that Microsoft's IM networks support lawful intercept (and that company policy supports this).

<comment><USER9> Yes, once this one is issued, Microsoft's competitors, both proprietary and free will be proud to proclaim Microsoft has a patent on lack of security!

</comment></comment><comment><USER6> Extremely important to note: this is a patent application, not a patent. That is to say, this has no legal effect, Microsoft cannot use the patent application to sue anybody, etc. etc. Also, the claims (which are the heart of any granted patent) are likely to change before this gets issued as an enforceable patent.

standard disclaimer: this does post does not constitute legal advice.

</comment><comment><USER9> Patenting the man-in-the-middle attack ought to mark the end of software and business method patents. It's (1) obvious, (2) been done, and (3) making hacks patentable ought to be contrary to public policy.

</comment><comment><USER10> I don't think this patent was specifically targeting Skype. If you search for the keyword Skype, it actually says that the method may or may not work for VOIP applications.

Besides, the patent was filed back in 2009, long before Microsoft acquisition in Skype.</comment>


Ask HN: Tips for starting a Classified site with a specific niche - <AUTHOR>

Me and my friend are planing to start a classified site with a specific niche in India. We are students and we don't have much money to invest... We will use OSclass and we have a niche. So I need some tips from you. Thank you. <comment><USER2> Start Simple configure it for what you need now not what you think you need. If you put a lot of categories in and they don't get used it will look empty. Better to add and split categories as it gets more use.

Have you figured out where you revenue will come from? If its from the students you need to work out what they'd be willing to pay for and how much.

</comment><comment><USER3> Why have you decided to use OSclass?

<comment><AUTHOR> Actually we were searching for a platform for classified sites. And we found it.

<comment><USER3> Have you deployed it?</comment></comment></comment>


Steve Ballmer selling Windows 1.0 - <AUTHOR> http://www.youtube.com/watch?v=tGvHNNOLnCk&feature

<comment><USER2> For those who don't realize, Microsoft made this as a joke for one of its events.

<comment><USER3> This would be way crazy for an ad. It was very nice tho. Coming down to play such a humour role in your own company's ad isn't something all executives can/will do.

<comment><USER4> MS execs are usually pretty good about things like that. Bill Gates' last day usually comes to mind.

<http://www.youtube.com/watch?v=1lE21kpE3M0>

<comment><USER5> Surely you can't mention this without the Bill Gates "Windows 95 will revolutionize PC gaming" video.

<http://www.youtube.com/watch?v=KN0K58EfJSg>

</comment></comment></comment></comment><comment><USER6> And Steve Ballmer selling Windows XP:

<http://www.youtube.com/watch?v=_-8IufkbuD0>

</comment><comment><USER7> Watching this in mute can make you convinced it's Cramer from Mad Money.</comment>


Ask YC: OfficeZilla.com at Twiistup right now, help me win. - <AUTHOR>

The YC board helped me find the minor amount of angel funding I needed to buy new servers and better rackspace.
I signed up for Twiistup.com expecting not to get in but here I am now.  If this article doesn't get removed I have an opportunity to get $5,000 in Yahoo Search Marketing which would be just very huge.
The instructions for voting are here http://www.mozes.com/_/leaderboard/display?id=186&projected=1
It is free.  It would be a huge thing!
Thanks
George OfficeZilla.com <comment><USER2> Okay George you got my vote :)</comment>


Sublime Tutor – Interactive Sublime Text Tutor - <AUTHOR> https://sublimetutor.com/ <comment><AUTHOR> Since I've been coding more, I was looking to make the switch from Notepad++ to Sublime Text, which is what everyone seems to recommend. I found this tutorial and went through it over the past few days. At first, I couldn't see the difference between ST and Notepad++, but now really see how well ST works. The key for me was having my own code open contemporaneously and trying what I was learning on my own code.

Anyways, definitely increased my productivity greatly! Thought I would share.

<comment><USER2> I find ST to be crashy, particularly if you pile on a few plug-ins. Notepad++ was a breath of fresh air in that department.

<comment><USER3> I've had the plugin host crash a handful of times in the last 5 years, but never had the editor itself crash due to plugins. In fact, I'm pretty sure that's why the plugin host exists in the first place.

<comment><USER4> The plugin host only exists in the beta version (v3), though, right?

<comment><USER3> Not sure, you might be right. I have been using v3 for a long long time now, so I can't say for sure.

</comment></comment></comment></comment></comment><comment><USER5> I was actually thinking just yesterday, "I wish there was some Sublime tutorial that just repetitively worked you through keystrokes to learn the muscle memory. That's been the biggest impediment to moving off of Textmate."

And then this. Thank you Hacker News AI for predicting exactly what I need to read today.

Now...is there something like this for Ubuntu?

<comment><USER6> > Now...is there something like this for Ubuntu?

As in a similar tutorial for Ubuntu? If that's what you're asking, then not really. Pretty difficult to learn an OS. Though you might be able to find some similar stuff for bash or vim if you look hard enough.

<comment><USER7> > Pretty difficult to learn an OS.

Ubuntu is not what I would call "pretty difficult to learn." Using it as your primary OS for 1-4 days is pretty much enough.

<comment><USER6> My point is that you can't really "learn" an OS. Linux distros are a combination of hundreds or thousands of tools. Yeah, you could get the hang of using Ubuntu in under a day, but you can't just "learn" all the stuff it can do.

</comment></comment></comment></comment><comment><USER8> For those interested: you can use Sublime Text keyboard shortcuts in VSCode.

[https://marketplace.visualstudio.com/items?itemName=ms- vscod...](https://marketplace.visualstudio.com/items?itemName=ms- vscode.sublime-keybindings)

<comment><USER9> It's a step in that direction but some key things don't work. Like the behavior of ctrl+shift+D is not available in VS code. Neither is multiple cursor copy/paste. Text drag & drop is missing. There are many other small quirks that won't let me make the move. A decent ftp client is also not there. The only one that works is shitty entire folder sync, I can't upload individual files. Their git and intelliJ integration is good though.

<comment><USER10> ctrl + shift + d in Sublime is shift + alt + down in VS Code. Multiple cursor copy & paste works fine.

<comment><USER9> No it's not. It copies the entire line in VS code. In sublime it copies the selected text. Huge difference.

</comment></comment></comment></comment><comment><USER11> I thought this said 'Sublime Tour' and started to get excited the band was coming back and then I remembered. :(

<comment><USER12> Then you remembered you were on HN?

</comment></comment><comment><USER13> I'm sure this is a great resource for those starting or just switching to ST3, but I wonder how the value holds up for those who have been using this editor for awhile now. Can anyone share their experience?

<comment><USER14> Idk, it's still best GUI editor in terms of performance, but I don't like it because of the price and it's not open source(but I can see the price being justifiable). I used ST2 for some time until I moved to Vim, and after few years of Vim I moved to Emacs.

And I think I've finally achieved what I wanted from the beginning, programmable environment. Editing speed is not nowhere near close to my proficiency in Vim, _but_ the things that really make my code better in the end is not faster typing but REPLs, and all those nice interfaces and plugins (I don't like to call Emacs plugins, plugins, because I believe they are much more than that, they usually provide you completely new environment with huge array of possibilities). So in the end I think it always comes down to Vim and Emacs. You hit the limitations pretty fast with other editors, your needs and technologies you work with change, so ST3 can be fine for you for some period, or much longer than it did for me, but I think it is worth at least trying to learn one of those 2 pesky old editors that everybody goes crazy about. Because people go crazy about them for a reason. ST3, hmm, not so much.

<comment><USER15> I too have come to that conclusion and I have started to learn VIM. Emacs is scary. How is spacemacs? Thats seems like the new cool kid in the block.

<comment><USER14> I didn't like spacemacs, but that's just me. Whole point of Emacs for me is customizing it to your own liking, spacemacs feels just forced to me. Even Emacs+EVIL feels much better, but then again, that is just me.

</comment></comment></comment></comment><comment><USER16> How great is sublime compared to Atom? I'm at my wits end with Atom but feel like I have no other windows text editor that can compete (even though I detest atoms interface and how buggy it is).

<comment><USER17> Every time someone is frustrated with Atom, we are obligated to suggest VS Code, because VS Code is actually pretty awesome.

<comment><USER18> I keep Sublime Text around for ephemeral scratch space, for quickly opening and then closing files, and for browsing through large files. Otherwise VS Code for my editing.

</comment></comment></comment><comment><USER19> For those who use sublime (I've moved to Atom and then VS Code), how is Sublime 3 ? (and is it any good for a JS/TS developer?)

<comment><USER20> I still use it after spending months with Atom and VSCode.

Currently I use it mainly for Python, Ruby and Elixir but it has great JS packages too.

If you're curious and want to see screenshots of a bunch of packages and how to install them, I whipped up a post about it a while back:

[https://nickjanetakis.com/blog/25-sublime-text-3-packages- fo...](https://nickjanetakis.com/blog/25-sublime-text-3-packages-for-polyglot- programmers)

</comment></comment><comment><USER21> You can also check out [https://sublimetextbook.com](https://sublimetextbook.com) Preview: [https://www.youtube.com/watch?v=izk7yzcb- rE](https://www.youtube.com/watch?v=izk7yzcb-rE)

</comment><comment><USER22> This is pretty awesome! Thanks a lot.

</comment><comment><USER23> I'll definitely give this a look, although given that I use Sublime almost exclusively in Vintage mode, I wonder how many of the tips will apply.

</comment><comment><USER24> Congrats on catching up to Emacs which has had a tutorial built in for decades. _pops open the champagne_</comment>


Refactoring Large Functions - <AUTHOR> http://robert.muth.org/refactoring-large-functions.html <comment><USER2> Do people really prefer:

          function doFirstBit() {}
          function doSecondBit() {}

          function big() {
              let x,y,z;
              [x,y] = doFirstBit();
              [x,z] = doSecondBit(x, y);
          }

to:

          function big() {
              let x,y,z;
              // First bit...
              ...
              // Second bit...
              ...
          }

To me, it's no harder to find the portion of interest in the latter when making a local change, and substantially _easier_ to understand the whole thing (because you can sit down, maybe with a printout if that's your thing, and read through it linearly without having to jump back and forth to the subfunctions). And passing data between the portions can quickly end up nastier than my contrived example above, at which point people start doing things like creating a class just to hold what used to be the function's stack-frame.

Not saying very long functions are something to celebrate. But if they're organised sensibly they're not a huge problem, and to be honest probably bother me less than functions which aren't abstracting anything terribly interesting and only get called once.

<comment><USER3> The readability/understandability points other make are good.

But I'd add that large function like this tempt the programmer to do something like using one of the intermediate variables in the first "bit" to make a decision in the second "bit" out of convenience. Add ten more "bits" and ten more such "conveniences" and you get an incredibly fragile, bug-prone mess.

Which is to say, a purely lexical-order division of operations is bad because you easily wind-up with undefined defined interface between the various operations. Figuring out both how a simple for-loop really works as well as how the original programmer _intended_ it to work, can be quite hard. Add several for-loops and you get a true mess.

Some people get really good at cranking out these long functions and as you say, it look superficially easier. I wonder if a language could support "functional abstraction brackets" that would allow these long sections but guarantee their logic isn't folded together

Something like

          function big() {
              let x,y,z;
              {{@First_bit //begin forced separation...
              ...
              {{@Second_bit //begin forced
              ...
          }

Here "First_bit" would be guaranteed to be equivalent to functions of just x, y, z.

<comment><USER2> If I'm understanding you right, "C-like-syntax" languages generally allow this:

           function big() {
               let x,y,z;
               {
                  // First bit
                  let localToThisSection = 42;
                  ...
               }
               {
                  // Second bit
                  ...
               }
           }

<comment><USER3> Yes, If your x,y, and z are both inputs and outputs, that works.

If you wanted a syntax that exactly mirrored what happens in the gp's second example, you'd need more work. Plus if you force a begin-bracket to have a label, you avoid the editor having to use "fun3756" when automatically abstracting out the subroutine.

</comment></comment></comment></comment><comment><USER4> John Carmack on this topic:

[http://number- none.com/blow/john_carmack_on_inlined_code.htm...](http://number- none.com/blow/john_carmack_on_inlined_code.html)

And I easily agree 100% with him having tried both approaches in bigger projects.

<comment><USER5> The anecdote Carmack shares from aviation is interesting:

      >Indeed, if memory serves (it's been a while since I read about this)...
      >
      >The fly-by-wire flight software for the Saab Gripen (a lightweight
      >fighter) went a step further.  It disallowed both subroutine calls and
      >backward branches, except for the one at the bottom of the main loop.
      >Control flow went forward only.  Sometimes one piece of code had to leave
      >a note for a later piece telling it what to do, but this worked out well
      >for testing:  all data was allocated statically, and monitoring those
      >variables gave a clear picture of most everything the software was doing.
      >The software did only the bare essentials, and of course, they were
      >serious about thorough ground testing.
      >
      >No bug has ever been found in the "released for flight" versions of that
      >code.
      >
      >                                                          Henry Spencer

<comment><USER6> Henry Spencer is one of the internet's greatest treasures.

</comment></comment></comment><comment><USER7> Some things are better said in one chunk, there are no rules. I often write longer functions while figuring things out, when I need more context in front of me to stay in flow.

Then I wait, and wait; until I can't stand it any more, at which point I usually know enough to substantially improve the code.

Assuming it survived that long. Refactoring code that you're going to throw away is not very constructive. And the more effort put into making code pretty, the harder it will be to let go when that's the right thing to do.

None of this works in a corporate setting, where there's never enough time or money to do anything properly. There are no awesome short term profits to be made from prototyping and keeping code in good health. Corporations also usually prefer rigid rules over competence and intuition, which means whatever cure they come up with will be worse than the disease. And as a result, corporate code is usually crap code.

</comment><comment><USER8> It is important to remember that functions exist for the sake of humans, not computers. The computer wouldn't care if all the code was in a giant main() function with GOTOs and a manually-managed stack, the programmers are the ones who have a problem with this.

</comment><comment><USER9> Item number 0 MUST be :

Make a copy of current function as old_function and add unit test to check if input on refactored function still produces same results as old_function.

<comment><USER10> That's why you have version control and batches and fuzzing etc.

<comment><USER9> Not sure how version control can help here, as unit tests are not run on old versions.

About batches, could you be more specific, i might be missing something here.

And for fuzzing, it will test your new function, but will not provide any guarantees that your new functions is working exactly like the old one. You might be surprised, bet there could be bugs in old function which can be fixed by refactoring. Sounds nice? But might be some legacy codes is depending on the bug that you fixed, and for backwards compatibility reasons that bug must stay be renamed from "bug" to "functionality".

<comment><USER10> I meant "branches". Mobile devices speak for us, it's an unbearable situation.

</comment></comment></comment></comment><comment><USER11> The article mentions Steve McConnel's advice on parameter lists (from his great book "Code Complete: A Practical Handbook of Software Construction"), but left out some interesting commentary on function length from the same book:

Some studies of code quality from the 1980s reported that defects per KLOC was _inversely_ correlated with function length, leveling off around 200–400 LOC per function. Software composed of many tiny functions is more difficult to understand because there is more context "off screen" to keep in your head.

A Cisco study of code reviews found that 200–400 LOC is the limit of how many LOC can be effectively reviewed per hour. Applying the findings of these studies suggests that neither functions nor patches/pull-request diffs should not exceed 200 LOC. FWIW, I have worked on commercial software that had functions many thousands of lines long! :)

</comment><comment><USER12> I've seen my share of code bases and many times I've seen a long function, I've made a number of other observations:

The long function has a lot of comments that try to describe the different steps. The comments are often confusing because whoever wrote the comments couldn't quite understand themselves what is happening.

There is a significant frequency of bugs found in the functionality implemented or coordinated by that function.

The long function has poor code coverage.

For me, a long function is usually a code smell.

<comment><USER13> Yeah often the comments are the names of the inner functions that should be extracted out too.</comment></comment>


Cockroaches deliver kicks to avoid being turned into "zombies" - <AUTHOR> https://arstechnica.com/science/2018/11/karate-kicking-cockroaches-can-fight-off-zombifying-jewel-wasps/ <comment><USER2> The video[1] in the article of the kick defense is pretty crazy.

[1] [https://www.youtube.com/watch?v=Rt8XoT2-qwQ](https://www.youtube.com/watch?v=Rt8XoT2-qwQ)

edit: remove all but the reference to the article's video</comment>


Tuition-Free University Gains a Following - <AUTHOR> http://www.businessweek.com/bschools/content/jan2010/bs20100121_194827.htm?campaign_id=rss_topStories <comment><USER2> I have a duty to my namesake to bring this up :-) Peter Cooper (the 19th century industrialist and Presidential candidate - not me) pioneered the tuition-free education concept in the United States with the Cooper Union, which is still running today: <http://en.wikipedia.org/wiki/Cooper_Union> \- online universities are cool, but the Cooper Union is a full-on bricks and mortar college.

<comment><USER3> There is also Olin College, outside Boston. In fact that's what I thought this article was going to be about. It's only a few years old but it has a good reputation already.

<comment><USER4> Sadly, Olin's endowment took a rather major hit and is no longer tuition-free. It's actually almost $39,000: <http://olin.edu/admission/costs.asp>

<comment><USER5> That's quite pricy... The tuition-free thing served its main point though, which was to attract students before accreditation.

</comment></comment></comment></comment><comment><USER6> _that would be free to students all over the world, one of just a handful of tuition-free universities._

One of a handful? All higher education in Sweden is tuition free for all students regardless of where they come from.

Maybe he means "one of a handful in the US", but the "students all over the world" part suggests he's talking worldwide?

<comment><USER7> Swedish schools won't be free for foreign students starting next year.

<http://www.sweden.gov.se/sb/d/12821/a/140013>

<comment><USER6> Hm, I wonder what the opposition thinks about this. Currently it looks like they'll win the election this fall, and might reverse this (in my opionion) bad decision.

</comment></comment></comment><comment><USER8> This is a great concept and Shai is to be applauded for his efforts here. It is a bit of a bummer that they need 5 MM in funding to keep it going. Anyway, even here in the states, you can cut the cost of education significantly by testing out of courses. Through the College Level Examination Program you can test out of most of your freshman and sophomore year courses for $75/per test. Most private colleges are now b/n 30-50k/year, so saving can be pretty significant. If you go to a state school saving can be really considerable as well. e.g., 1200 vs. 8k. +++ you don't have to take 15 weeks of a course to test out of it. More info can be found here: <http://www.collegeboard.com/student/testing/clep/about.html>. Education inflation is insane. We see this as one way to keep educational costs down.

<comment><USER9> My private college would have made me pay for the credits even if i tested out.

</comment></comment><comment><USER10> It's a great idea. However, until they become accredited here in the US, the education is pointless. I talked with the head of transfers at my university, and was told they wouldn't even accept these classes for credit. Also, I don't know how many establish companies would take you seriously if your resume education listed a Bachelors from The University of the People.

Might be fine outside the US, but it has some BIG hurdles to jump here!

<comment><USER11> Why do education and accredidation have to go together? I'd much rather learn on my own (through these online courses), then take a one-month intensive series of accredited projects and tests (a bit like a Google interview) to get a diploma.

</comment></comment><comment><USER12> I decided to go through the application process. I'm currently a student enrolled in a community college transferring to Baylor this Fall.

The question that really poked out to me was: "5 Please finish this statement: "When I think of Online Education I think…". "

Well, of course, I think infancy. The internet as a whole is probably still in an infancy stage with nothing set in stone. I started thinking about it from a philosophy POV too. My Phil101 class consisted of 70% natural texans, 10% out of state, and 20% international students. There was an obvious amount of disgust from the natural texans not only to the international students but to the out of state students. I realized a major problem with discrimination and fear had to do with just plain lack of familiarity. I had always got along with the African transfer students because our stories were similar in a way. We were both just looking for a place to fit in where we were basically regarded as foreigners. The texans would criticize, laugh, and just be pure cruel to the transfer students. I would get questions and express my agnostic/absurdist opinion and get the same exact vibes. It wasn't because we were picked on that we could get along though. It was because we had experienced more than just what "texas" is. An online environment can not only teach students subjects but can teach students about one another if it is made interactive in some way. My countless hours spent on IRC in various networks has already contributed to my ability to be able to put myself in another's point of view.

Anyways, back to the point! Online education could pull off some things that a traditional college fails at achieving. "Its who you know and what you want to make!" Well... I haven't met anyone in my traditional college other than professors. I have the need to create, but there's really no intermediate for creating or place to talk to others who might be interested. An online community not only has the chance to create great contacts (how much easier is it when student A just gives you his email address?) but also allow for hubs of creation to spawn on sort a viral scale. Creation is limited in traditional environments that I've been a part of! If online institutions decide to stray from what we call tradition, maybe, just maybe, they will create what should be called higher education. Because, baby, this ain't it.

</comment><comment><USER13> I think the biggest problem with any online university is letting the students network with each other. I took a grad-level class at UC Boulder last fall, and probably would've flunked it if it wasn't for my coworkers available for me to ask questions. That said, I've gotta look into UotP's social network thing.

Fun thought, it'd be interesting to teach/mentor techical knowledge (i.e. programming) in exchange for a business education. It'd let you organize the skills you've learned, learn how others approach technical skills through teaching, and learn formal business skills all at once.

</comment><comment><USER14> The social/communal aspect of this looks interesting, especially as one of the questions is "what can you bring to your fellow student". A good study group is worth its weight in gold.

The selective admission process should also help: your social surroundings should be fairly fixed and you can be sure they're fairly motivated.

Part of me would like everyone to be included, but the aforementioned, and that the students will require time/effort from the teachers, means it's more or less required.

</comment><comment><USER15> A great Mixergy interview with Shai Reshef not just but two weeks ago.

<http://mixergy.com/shai-reshef/></comment>


Why I won't get hired or my skills used? - <AUTHOR> This sounds silly but I've been trying to find a remote "job", or something just to gain experience in the web development field (js,  html, css )  but it seems to be hard as hell to get someone interested, I've sent resumes and nobody replied. It's starting to become a depressing situation and to kill my desire to become a programmer. <comment><USER2> You're going to have a difficult time finding a remote job as your first gig. Hiring someone to work remotely involves a high level of trust:Trust that you have a high level of comoetency (which, given yiur description, you dont) and trust that you will be honest about the time that you put in(which doesnt really matter if you complete projects before their deadlines.)

You would gave better luck starting out as a freelancer and finding something in your personal network. No one is going to hire you for remote work without a portfolio

</comment><comment><USER3> Second the resume,

\</comment><comment></comment><comment></comment><comment>

         First-name lastname
                Address
              Phone number
                  Email

Summary/skills \- x years of experience in x \- strong knowledge in/of x \- advanced knowledge of x \- work traits \- merits \- positive character traits

Professional experience

Company name Street address City, state/province, zipcode Country

Job title/role | startdate-end

\- responsibilities -responsibilities -responsibilities

Company name Street address City, state/province, zipcode Country

Job title/role | startdate-end

\- responsibilities -responsibilities -responsibilities

Company name Street address City, state/province, zipcode Country

Job title/role | startdate-end

\- responsibilities -responsibilities -responsibilities

Education

Schoolname [highschool], state/province/or city/country Diploma name | year achieved

Collegename [college/univ.] state/province/or city/country Degree name | Year achieved

Certifications

Cert 1 Cert 2 Cert 3

References

Reference name Title Company Address Phone number Email Website

Reference name Title Company Address Phone number Email Website

Reference name Title Company Address Phone number Email Website

Reference name Title Company Address Phone number Email Website

\</comment><comment></comment><comment>--

Large clear font for headings Double spaced company info under professional experience 1.25-1.5 spacing in responsibilities[1.25 spacing in summary/skills]

1.25-1.5 spacing under other sections except references

Center your contact information Left align the rest Use bullet points instead of dashes

Try to focus on listing relevant work experience in most recent first to oldest

</comment><comment><USER4> Web development tech is like singing. Everyone can do it. Few can do it well. When you do it well, it sells itself.

Think of something cool to do, do it to the best of your ability, keep improving it, and before you know it they will come to you.

You should never run out of things to improve. If you think you have something that is "perfect," it means you either need better feedback or you need to read more or both, because there is always room for improvement. That last 10% is what makes people stand out.

<comment><USER5> > Web development tech is like singing. Everyone can do it. Few can do it > well. When you do it well, it sells itself.

I don't know where your working but I run across plenty of people that can't do it well that still manage to be employed.

<comment><USER4> If you do it well, you don't have to be an employee.

Of course corporateland is an entirely different game. If that's the game he wants to play, why even waste time with something practical? Getting an MBA, having meetings all day, and looking out for #1 would be a much straighter path to the goal.

<comment><USER5> > If you do it well, you don't have to be an employee.

Well, you have to do a bunch of things well, most of which are unrelated to programming.

</comment></comment></comment></comment><comment><USER6> Instead of trying to become a programmer by getting experience by getting hired, try becoming a programmer to get experience to get hired.

</comment><comment><USER7> Join a hacker or builder club (note, these are experimenters and builders and steal nothing) Network with people, build stuff and improve yourself to the point where you have marketable skills. People at the entry level are not hired for work on projects. They need to learn active program creation and debugging etc

</comment><comment><USER8> People don't want to be negative, but you will find it hard and maybe impossible.

People honestly do not want to hire someone for a remote position that needs to "gain experience". You should be employed for 2+ years as a programmer, before trying to find a remote job. Maybe you have?

</comment><comment><USER9> Others have stated that remote work for people with no experience is going to be hard to come by. One thing that I will add is that since the work is remote the companies aren't restricted to a certain market when looking for developers. If there is a company in Chicago, for instance, then they will typically be limited in having to find developers in the Chicago area. Companies that are remote won't have this problem. You are competing with people that may have portfolios or side projects for the same position, which will make it hard for you to actually get a position when you have no/little experience in a given technology.

</comment><comment><USER10> I feel like its easier to get hired for a remote job if you've already worked remotely previously. See if you can whip up a few non-trivial projects of your own and build up a small portfolio, if you haven't already. Then the first step might be taking on a manageable project like building an MVP for someone.

Even taking a project that you worked on in a tutorial, extending it and being able to speak intelligently about your design decisions will help you get a foot in the door on many small projects.

</comment><comment><USER11> Why does it have to be remote? Try asking to be an intern at a local startup or small company? If you don't know any, ask at the local university.

As many said, finding a remote job as a first gig is very hard. Heck, it's very hard for established people - I've worked for 15 years and I only had one remote gig.

</comment><comment><USER12> Get some help building a better resume with appropriate keywords. Do you have work samples? Certs, degrees? Ask a professional to review your shit and optimize it for getting hired.

</comment><comment><USER13> It might be beneficial to post your resume here (blank out your name / other personal information).

</comment><comment><AUTHOR> Just to mention, all I've applied is for entry level.</comment>


How to Hire a Programmer - <AUTHOR> http://www.codinghorror.com/blog/2012/03/how-to-hire-a-programmer.html <comment><USER3> They always tell you when you are interviewing you should never bitch or gossip about your old job. Articles like this are the inverse of that, the employeer is subtly bitching about every bad hire they've ever made. This is a giant red flag that whoever is doing the hiring sucks at their job.

I've had a few interview process that have included some or all of these 6 steps, and I've turned down every one of their offers at the end. Not because I don't have the time to work on a sample project,or because I can't cobble together and isolate some sample code for them to take a look at, and not because I don't know how to play the interview game.

It is because your interview process takes too damn long. One or more phone screens, one or more in person interviews, then a request for a sample project or source code, then a request for references, then a meeting with team, etc. That takes months, with weeks of down time in between.

If you can't figure out if a person is a good fit socially and is a competent programmer in less time that, you suck at hiring and shouldn't be doing it.

<comment><USER4> It's probably a bit extreme to say he's "bitching".

This sort of thing is quite useful to those of us who have an involvement in hiring, but don't have a lot of experience.

I've been involved in hiring a couple of people, though the process I go through usually involves:

a) Read a code sample, if available. b) Face-to-face interview (telephone if face-to-face is difficult). c) Hire/No-Hire

The interview usually involves talking about our company and the interviewee talking about their previous experience. The hiring decision is usually based on "I like the feel of this guy", with some weighing up of their skill set, the job role, and also how interested they would be in working for us.

I've found this works for the company I work for. We don't hire large numbers of people, so I don't think this approach could scale - as an example, the largest block of CVs for a position that I've seen is about 10. I don't know how it would work if we got 100 CVs.

<comment><USER5> He's saying negative things about former employees. So much for symmetry. Interesting that employees cannot prudently make negative remarks about former employers even in general terms, but employers can make negative remarks about former employees. If a negative remark would lead a prospective employer to wonder if a candidate would eventually say the same things about him, why wouldn't a prospective employee think that a prospective employer who made remarks about bad hires would not eventually say the same things about him?

<comment> hippee-lee I think it depends when and where you discuss a negative experience. Sure, not a good idea in an interview.

But what about doing a personal reflection, say a blog post or something on your own time about the observations and lessons learned with regards to things like culture or development philosophy directly related to that company? As long as you do it in a way that doesn't break any non-disclosure agreements why should you be punished for it and do you really want to work for someone who would look negatively on you for expressing what you have learned from a bad experience? Even more important - perhaps the employer doen't know how bad the culture is inside or worse they do know and rely on you not ever saying anything to continue recruiting others similar to you?

Then, during the interview you can find a way to bring a summary of the negative experience into the conversation without it looking like you want to trash or burn your former employer or manager. There are many opportunities for this, a common question one gets asked is to describe what you have learned from mistakes on the job. This is open and general and one could easily work programming specific or soft skill lessons learned into the discussion that do not paint your former employer in a positive light. And if your former employer has not earned the right to a positive reference you should not be required to give it to them just because you want to continue working.

</comment></comment></comment></comment><comment><USER6> You missed one Jeff ... treat them with respect.

I've interviewed at a lot of places, and some of the things these companies do is breathtaking ... that's when they're _interested_ in you. They try to schedule you into 3-4 hour interviews like you don't have a job to do that day. They send you coding assignments that take 4-8 hours to do. Interviewers get your resume 15 minutes before they walk into the room with you, then ask you to rehash your entire background (because ... you know ... that shit isn't in the resume in front of you already).

Then there's the default position some of them take that 90% of the people they interview are idiots, so they're just going to treat you as such until you prove them wrong.

I had one firm set me up for an interview, and then cancel it without actually telling me, until I emailed about 2 hours to the time of the interview wondering what was up etc etc

But that's just the half of it, as soon as some of them decide you're that worthless programmer who didn't pass their pet brainteaser/trick question, they won't even do you the courtesy of telling you that you're out of the running. The recruiter who was all so chummy with you and positive about your prospects goes AWOL and you get that dreaded automatically generated rejection email.

If you felt good enough about me to actually talk to me on the phone to get me to interview, why can't you even email me to cut me? Just man up and do it like the movie Moneyball. "Sorry x, you didn't make the cut. Good luck in your search". I'm a professional, I can take it.

Its all rather exasperating, because we both want the same thing in the end.

</comment><comment><USER7> John D Cook has a lot to say about this: [1]

" _One of the marks of a professional programmer is knowing how to organize software so that the complexity remains manageable as the size increases. Even among professionals there are large differences in ability. The programmers who can effectively manage 100,000-line projects are in a different league than those who can manage 10,000-line projects. ... Writing large buggy programs is hard. ... Writing large correct programs is much harder._ "

Jeff Atwood's metrics will help you filter out engineers whose complexity ceiling is <1k lines -- StackOverflow answers, whoopee -- but that's not a terribly hard thing to interview for. Much harder to interview for the very best, the mythical 10x productivity programmers[2], those who can handle 100k LOC, 1M, or more. Perhaps this is the difference between an experienced non- expert and a real expert[3].

In my experience not a lot of employers care about this, perhaps because their challenges aren't those of complexity-in-scale, or perhaps because complexity hasn't bit them hard enough yet, or perhaps because they are "unconsciously incompetent"[4]. About the only hiring signal I've identified for this is interest in functional programming -- languages like Clojure and Scala exist precisely to raise the ceiling of complexity a human can handle[6] -- and as such I'm trying to learn this stuff and trying to find people via the community who care to hire engineers with these skills. Unfortunately my own bias may be blinding me, you never know which side of Dunning-Kruger[5] you're on until it's too late.

If you care about these things: I'd love to know who you are and what you're working on, email me.

[1] [http://www.johndcook.com/blog/2008/09/19/writes-large- correc...](http://www.johndcook.com/blog/2008/09/19/writes-large-correct- programs/) [2] I am not one of these, but I strive to be one someday. [3] <http://www.dustingetz.com/how-to-become-an-expert-swegr> [4] <http://en.wikipedia.org/wiki/Four_stages_of_competence> [5] <http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect> [6] Clojure creator Rich Hickey talking about complexity: <http://www.infoq.com/presentations/Simple-Made-Easy>

edit: man, this got 2 downvotes in 2 minutes, cmon guys i put a lot of thought into this!

<comment><USER8> Have to show some support for this post.

Engineering is a combination of technology and art. Therefore, it is impossible to have a simple process for interviewing engineers that magically works. Otherwise, such posts would not have been brought up so many times in HN.

Also, some people are good at people evaluation, some are not. An excellent engineer could be a lousy interviewer. On the other hand, a mediocre engineer is lack of the ability to evaluate a top engineer within an hour. Therefore, the employer must first know who are his/her best interviewers. If s/he can't identify her/his own people, I highly doubt s/he is able to identify good candidates.

The hiring signals I pay attention to are one's curiosity and one's depth in understanding in at least one programming language or one computer science topic, no matter if that topic or programming language has any relevance to the position to be filled. Here is the rationale. To be a very good engineer, one needs both internal motivation and intelligence. Both of the two signals speak for internal motivation. A deep understanding on any topic shows the candidate is sufficiently intelligent. Such a candidate, even if s/he knows little about the languages and/or the frameworks the position requires, s/he would learn it very fast and would be very good at it. To be realistic, it is really not hard to learn a programming language and a framework.

<comment><USER9> Good thoughts!

I think software has a lot of reusable principles/concepts. And these days syntax is really skin. Programming languages get used a lot because their ecosystem.

You are definitely very correct to demand perfection in at least one walk of our profession. Because those concepts get reused nearly everywhere.

Another thing that I don't understand is rejecting people merely because they don't know answers to some questions from the algorithm and data structures text book. Software engineering today is so much about so many things.

Above all I would say productivity and passion is the only factors I would use to judge people today. Because those factors decide nearly every other factor.

</comment></comment></comment><comment><USER10> Good luck hiring someone who is merely unhappy in their current job.

If someone is in a full-time job, it is hard enough to find time to go to interview. Good luck finding a free week to do a side project for you. They will self-select out of your selection pool, yet they are very valuable possibilities. Ditto for a probation period, why would someone with a job go work for 3 months for the possibility of maybe getting a different job?

Yet that said, I don't think this is bad advice. A company will see many candidates that could have worked out, the challenge is making sure you don't wind up with a promising looking dud. A high rate of false negatives are OK, so long as you don't get a false positive.

But it also isn't the only good way to do it.

<comment><USER7> the challenges you describe are, i think, why networking is really the only viable way to find the best talent - self-selection can work in your favor, if you're doing it right.

One of the leaders here in the Philadelphia tech community, Kyle Burton, talks about networking on HN here[1] - he is running a Clojure startup and has had little difficulty hiring due to the time he spent cultivating the local community. he hosts his own clojure meetup which it appears he can hire from at will. edit: i just emailed him to belatedly ask permission to quote him, maybe he will chime in here.

" _I was actively recruited to the team. I personally believe that this was because I made a conscious effort in the fall of 2008 to start being much more active in the community at large. I started doing more visibile things on the internet: a blog, putting up a sandbox on github. I also started speaking at local user groups (god bless them for listening to my first talks and my horrible, horrendous presentation skills). ...

"By 'recruited into' I mean that not in the sense that either side used a recruiter. I mean I was approached through my network because of the effort I put into building the netowrk and the effort I put into building a personal brand (as slimy as that sounds, it is working). ...

"Actively working at networking has been wonderful. I can't recommend it enough. I was involved in starting a "tech breakfast" meeting that takes place 1x a month. The local groups (esp volunteering to speak), the breakfast sessions, and buying people lunch (an hour of interesting conversation is totally worth the $10, and every time it has come back to me) has gone a long way to building a local network._"

[1] <http://news.ycombinator.com/item?id=2832571>

</comment></comment><comment><USER11> As much as people like to deride #1 (here and elsewhere) it's one of the most useful filters (in terms of filter value for effort spent). It's not a positive filter (in that a candidate who passes won't necessarily be a great programmer) but it is a great negative filter (a candidate who fails almost certainly isn't).

#2 I have mixed feelings about. A lot of people work on things where the source code (even the product) isn't visible. Having an SO profile is semi- useful but lack of one doesn't really mean anything. Github only makes sense if you work on open source (and frankly I'm tired of the incredibly naive "Github is the new CV" postings that pop up every few weeks).

#5 is what I really object to. At least in this case you've gone through the initial filters. Some companies use an audition project as an initial filter before you've ever spoken to anyone (you know, to see if you'd be a cultural fit and so on). I have zero time for this.

The problem with an audition project is that anyone truly good won't have to jump through those kinds of hoops. They'll have their pick of offers as is. Job seeking through a traditional (non-network) route is relatively low percentage such that there's only so much time worth investing in any particular position.

I'm happy to prove to you know I have a solid enough foundation in data structures and algorithms, I can program my way out of a paper bag and I can problem solve and communicate effectively but as soon as you ask me to spend a week--even a _day_ \--on some audition project, forget it.

Honestly, hiring isn't that hard. You just need people who are good at hiring to do it. I've done 10 or so "lunch interviews" at Google this year. This isn't an interview per se. It's simply taking someone to lunch in between their onsite interviews. It's a chance for the candidate to unwind, ask some questions, etc. But there is no feedback element to the process.

Of the 10 after 10 minutes I predicted 8 wouldn't get hired, 1 would and 1 I wasn't sure about. Turns out the "yes" declined an offer and the "maybe" didn't get one and I was otherwise right. _And this is simply from going to lunch with them._

My formula is:

1\. Filter early. "Hello world" and other simple programming tests;

2\. Establish technical foundation and problem-solving ability (with one algorithm-related question that should be coded); and

3\. Otherwise ascertaining personality/cultural fit. This you should get just from talking to someone for 10-15 minutes.

It's really not that hard. You just need someone who can actually do it to do it.

<comment><USER12> _as soon as you ask me to spend a week--even a day--on some audition project, forget it._

Note that he proposes the audition project to be "a regular consulting gig with an hourly rate", spent on-site doing real work.

You don't have time to earn money doing real work? Then why are you applying?

And even for a "truly good" professional who has his pick of a dozen offers, I could see this as a good idea, since they have just as much reason to be interested in the company's "real" work environment than the company has to be interested in their "real" work performance.

<comment><USER13> _You don't have time to earn money doing real work? Then why are you applying?_

False dichotomy. I'm already earning money doing real work. I'm not applying so that you can cut into my family time. I'm applying because I want work that's more interesting or more money or who knows what. If you really want to know, ask, instead of assuming ;)

EDIT: Clarifying the "more interesting work" expression.

<comment><USER12> _I'm applying because I want work that's more interesting or more money or who knows what._

Apart from the money, such a "audition project" could help you a great deal in deciding whether this company actually meets your expectations.

You're of course right in that it will be difficult to do it like that for someone who already has a fulltime job.

</comment></comment></comment></comment><comment><USER14> Sounds good...if you are hiring 15-year olds.

If someone asked me to write a "Hello world" program in an interview I'd get up and leave (or hang up the phone). It's an insult. This would be very clear sign that I was talking to the wrong people.

A lot has to happen before a formal interview takes place. If you have to ask a guy (or gal) to write a "hello world" program it probably means that you have absolutely no clue who you are talking to and have done zero homework pre-interview.

You know what I want to see? Bring your laptop to the interview. Let's connect it to a projector and take me through some code that you've written.

Inside of 30 minutes I should know what kind of a programmer you are. In 60 minutes I probably have enough data to decode your DNA and tell you what you are going to die from.

What the hell are you going to learn from printf("Hello world")?

<comment><USER15> I have to disagree with you. This isn't supposed to insult you and it can be prior to the in person interview.

I did an interview once and asked them to interchange the value of two variables in any language they wanted. In the end maybe 2 out of the 20 applicants that past our HR dept checks got through this.

This one only one question, I there was much harder questions on my test but none that I or another person on the team couldn't answer in less than 1 minute. It was a disaster and I ended getting forced to hire someone from that pool anyway. That hire didn't mesh well at all.

<comment><USER14> I guess my point is that there has to be something wrong with the hiring process if 2 out of 20 applicants can't swap the values of two variables.

Either that or there's something very seriously wrong with CS programs. How can someone walk into an interview with a degree and fail something like that?

If the quality of candidates is that bad, then, OK, maybe I'm wrong about the "hello world" test. In my reality someone wouldn't even get an interview without evidence of prior non-trivial work. Hence my rejection of the "hello world" test.

I also recognize that if you are hiring massive numbers of people you need to mechanize things a bit. I couldn't see sitting down with someone, their laptop and a projector for an hour under those circumstances.

Thankfully that is not my world...at the moment.

<comment><USER15> I posit that some of it is just people lying. I had someone send in a huge perl script he claimed to be his own work yet failed that variable swapping test. Basically our setup was HR gets a bunch of resumes and scans for minimum requirements (degree, prior experience) then we get them. You get really good looking resumes that you need to prove somehow. That's where that basic litmus test comes in.

Things like Github improve this a bit although I'm not even a huge user of public github repos (something I'm working on fixing since I realize my online profile is a bit sparse at the moment). I don't it's perfect either as a lot of very good candidates don't have time or are shy to show they work in public. Heck I love working on my professional project in my spare time and can't show that code publicly most of the time.

</comment></comment></comment></comment><comment><USER16> I was about to scream about #5 until I saw this:

"This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement."

I interviewed with a YC company about a year ago and was asked to do #5 except without pay. It's a long story, but in short I let my guard down because it was a YC company only to find myself having wasted a week. The part that really pissed me off is that they came back _months_ later and pretended that no time had passed at all (obviously their hire didn't work out) and asked me to jump through more interviewing hoops. When I rightfully just told them to put money where mouth is they actually insulted me and the free work I had done (written in an email no less).

The point I'm making is that if you need this many hoops for a candidate to jump through you shouldn't be the one hiring. Find someone else with a business-tuned intuition and ability to judge character. If you act like you're the world's greatest company which people will waste hours and even days trying to impress you're going to miss the best people out there.

Also #2:

"Show me a Stack Overflow profile where I can see what kind of communicator and problem solver you are. Link me to an open-source code repository of your stuff."

Kinda cheesy for Jeff to say the first part. I absolutely agree with supporting both info sharing sites and open source. But as a self-taught programmer that ships products and does very well financially, I can tell you that there are effective people out there that don't rely on SO to get things done and therefore probably don't contribute to it.

I do absolutely support open source software but I also don't have a lot of free time. I've written a raster to vector conversion library that I'd love to clean up a bit and open source. But I literally don't have time to do so. Does that make me a second class programmer? Having hired many people over the years I know that I would look very seriously at someone who has shipped a lot of products but doesn't follow programmer community trends like SO. I guess it could mean they're truly horrible programmers with no knowledge to share. It could also mean they're too busy meeting their own (or some company's) targets. It could also mean they like to unplug once in a while and lead a normal life.

I understand why companies like Google take a hardline approach to hiring. They just deal with too many people. But if you're reading Jeff's essay on hiring you're not running Google. If you're a small company you need to look at the outliers first since that where you're likely to find overlooked talent. That's where you're going to find the people who don't jump through hoops but who actually get shit done on a daily basis.

<comment><USER17> #5 is still a bad rule. It eliminates anyone who currently has a job. That leaves you with people who don't have a job (for whatever reason) or are working as a freelancer.

Freelancers really don't want to work at a company, and in my experience, it doesn't work out. I'm thinking of one person in particular who was an amazing coder, got along great with everyone, and all that... But he wasn't happy there. He quit before his 3 months review came.

Last time I interviewed, 1 of the companies asked me to write a sample app that was useless, but would show I knew what I was doing. I had 48 hours to do it. So yeah, I lost a weekend (well, 16 hours of it) but they were able to know I was capable without a lot of craziness. I actually ended up taking a job somewhere else before my interview with them, though. I had found a better paying job at another company that didn't do any of that stuff. It was just a 1-on-1 interview and discussion of my past work. I'm still here a year later.

</comment></comment><comment><USER9> Frankly speaking I interviewed for a bigMegaCorp last year which is pretty famous. Can't give out the name of the company for obvious reasons.

They first had a telephonic round and checked around my skills. They talked of my last projects and make me write some code. It went well. Then they invited me to have some onsite interviews. It was the most pathetic interview experience any body could ever have.

They gave me a laptop and made me code. Which I did. The first day they had three 1.5 hours session coding session based interviews. Of which I missed only on one question. They went pretty fine. They told two days later I need to go through more interviews, It was a another two coding sessions plus a database and common design pattern based interview which I also did well.

But they called in a week later and said I needed to come again. Frankly speaking my patience had ran out. But nevertheless I still went. Only to find I had to go through another three rounds. This time the experience was pathetic. Its was full of puzzles and memorizing arcane facts of various bits and pieces of software which I bet no productive programmer will ever have time for. It was puzzles and fact quizzing galore like I had never seen before. Coupled by one Algorithm interview and I bet they asked mathematics I had never heard of before.

Another week later they told me I was rejected. Now this is what I have a problem with. You want somebody who can build quality software, who knows his trade. Programming languages, Databases, Tools, design patterns, Quality and other daily stuff.

How the hell does it matter the guy doesn't know facts and puzzles? Frankly speaking I can learn that too! If I spend 30 mins a day reading the career cup ebook and other internet puzzle forums I can very well game the algorithm and puzzle rounds. But what will this every say about my skills as a programmer?

All this 'Github as a resume' , and 'Stackoverflow profile as a resume' work fine only in forums like these. Otherwise every interview has a puzzle and algorithm quiz round which has absolutely no relevance to the daily work of a programmer.

Honestly all big web companies claiming to hire the best are definitely hiring the most _knowledgeable_ person. But none of them are hiring outliers, passionate and productive people who can do miracles. This also perfectly explains, why most of their innovation and growth happens through acquisitions and not in house innovations.

Because most companies have people who know a lot, but not necessarily who can do a lot.

</comment><comment><USER18> These seem like mostly good ideas. I do see some problems with things like GitHub and SO rep becoming so important in the filtering/hiring process - <USER2> gives a huge advantage to those who work at companies with good open source policies. Open source contributions and contributions to community resources like SO can be useful, but I hope the lack of them doesn't cost too many people shots at interviews - there are a lot of good developers with no presence on SO or GitHub.

I do, however, have a bigger problem with #5. It seems fine at first glance, provided the company is being honest about it, but from the perspective of the potential employee, it is hard to know if performing well on the 'audition' is really all that is standing between you and the job.

About 8 years or so ago, I was applying for a new job. The interviews all went pretty well, and I was given an audition project that was aligned with this companies product very tightly. I spent several evenings (probably ~8 hours total) working on it and submitted what I thought was a pretty good project. After I followed up with them a while later, I was told that while my submission was the best one they'd seen, they weren't going to be extending me an offer.

I sort of wondered if they were using applicants to build their product, but it seems like it was a lot of overhead on their part. Either way, I wasn't pleased that I'd been given a project to work on even though I apparently wasn't going to get hired anyway.

</comment><comment><USER19> One thing I've really struggled with since coming to San Francisco is that every company seems happy to take extensive time out of a programmer for an interview, including an audition project.

Yet if you ask this of a designer, you get shot down immediately for soliciting spec work.

<comment><USER20> Jeff's suggestion - perhaps not followed by everyone who does an "audition project" - is that the project be _paid_. (Spec work, of course, isn't guaranteed to be).

<comment><USER19> I understand, and applaud Jeff for that, but most companies don't pay for their interview process, many of which can be multiple full day affairs.

I can't imagine a company not getting backlash holding a design competition to 'interview' designers.

</comment></comment></comment><comment><USER21> In any technical domain, it's hard to identify the right people, even you base your hiring process on recommondation letters as it is done over here in Germany. These letters, and CVs and degrees as far as that is concerned, only get you so far.

After thinking about it (and deleting my first comment), I see it as some good basic advice for first time employers. What I don't really get is the point with the trial project... Do start-ups and highly qualified experts (supposed you actually want experts) really have that much time to waste? I don't think so.

One important point mentioned in the comments was culture, and yes it is paramount. Especially in disruptive, small companies where you cannot afford to have the average well-adopted worker drone around you usually get from HR in bigger companies, ideally the founders are around to communicate the culture themselves. Ouliers actually are a good place to start looking if don't already know your candidates.

Personally, I like interviews whith people who actually have a say in the hiring, only HR usually sucks. Added benfit: people knowing their job usually can tell after professional discussions (and some tests that can be done in a couple of minutes to identify the liers) if the prospective employee knows his job or not.

Disclaimer: Non-american non-programmer commenting, so please be kind :-)

p.s.: Treat them with respect, because if you don't you'll only get the desperate and they tend to be desperate for a reason.

</comment><comment><USER22> I don't really agree with this, as usual. If you follow these directions, you might end up ok but you can definitely miss a lot of good people, and yes I'm aware of the meme about being happy to miss Knuth in order to avoid any blubs.

I also think it's not practical for a lot of companies. As well, I know around these parts it is almost sacrosanct that one should have a Github, possibly blog, etc but there are many great programmers that do not have such a portfolio. I mean, many of these programmers are very good, deeply technical, and work on quite serious things.

As far as #5, you will definitely miss out on people there. Many people with real talent actually have bills to pay and companies willing to pay them without some trial project. I understand the reasoning here, I mean, wouldn't it be great if we could go a step further and get someone to work for free for a year before we start paying them, just to make sure they are in it for the "long haul."

#6, I have no problems with; it's quite reasonable.

Honestly, I have followed Atwood for years, how many of these things would he actually pass, besides the thing about being very public? - no ad hominem, purely tangential.

<comment><USER23> I'd probably be at most risk of not passing the phone screen, depending on how anal the interviewer is (read: whether they are a hard-core C programmer type). E.g. particularly if they asked coding questions about pointers and so forth. I've always hated C, ever since I tried to learn it in high school back in 1986 or so. The big picture stuff about bits and bytes and data structures I think I'd do OK on.

</comment></comment><comment><USER13> Okay, to get this out of the way first: I completely agree with Jeff that hiring programmers is hard and that the way a lot of companies go about doing it is about as effective as Russian Roulette. I've seen it and felt some of the dismal consequences. As a matter of fact, I still have to work with lots of those people that should have been filtered out in step 1. So yeah, I agree with the idea.

Having said that, his process, taken together, is ridiculously one-sided. The message it sends comes across as "Of course you want to work for us, regardless of all the hassle we're putting you through, who wouldn't? Only someone out of their mind, that's who! And we don't want people like that here."

Think about it, Jeff. You are asking for someone who:

1) is highly skilled

2) has an attractive portfolio

3) is mature enough to communicate well

A lot of people like that already have jobs. If you want them to do #5 -- which might be something they're forbidden by their current employment contract, by the way -- and you also want them to prepare a presentation for #6, you must be the sexiest employer on the Earth.

In short, what do you propose to balance things out?

<comment><USER24> I'd wager that someone who is highly skilled can afford to take several days off work.

<comment><USER13> This is simply unreasonable. Those days off work come from somewhere, usually paid or unpaid vacation time. In other words, you're either cutting into the time reserved for your family/social life or you're paying out of your pocket.

To put it simply: your approach doesn't scale.

</comment></comment></comment><comment><USER25> Why do an audition project when you can fire candidates who do not work out within the first three months?

My advice is to trust yourself and hire people you like. Take a leap of faith. If things do not work out - be quick to pull the trigger.

<comment><USER26> >Why do an audition project when you can fire candidates who do not work out within the first three months?

Because then good people won't come work for you.

I would not interview at a company that had a reputation of firing a significant portion of its employees within 3 months. Not just because of the obvious career and financial risk. But because a company that treats its employees as disposable is likely not to be a good place to work in general. And I doubt I'm the only one who feels this way.

<comment><USER25> Well, if you end up firing a lot of people, give recruiting to someone who's a better judge of character.

Firing when things do not work out is an honest act. What does it have to do with disposability? Both parties will be better off moving in separate directions.

Also, I don't see how an audition will improve anything.

Life changes are the biggest risk to employees performance. No matter what you do, you are not going to predict life changes during the interview.

<comment><USER26> >Well, if you end up firing a lot of people, give recruiting to someone who's a better judge of character.

It's not just about judging character. It's about the amount of effort an employer puts into the interviewing and hiring process. Interviewing people well takes effort. But if you're willing to fire someone easily, well, why put in the effort?

In my experience, this feeds back on itself. The more comfortable the employer gets with firing, the sloppier the hiring process gets. Soon good people start avoiding the company, which means mediocre people get interviewed. So the interview standards need to drop further, otherwise no one would get hired at all (and besides, you can just fire them if it doesn't work out, so what's the harm?). Pretty soon you're one of those companies with constant churn, where no one seems to last longer than a year.

>Firing when things do not work out is an honest act. What does it have to do with disposability?

It's not about honesty, it's about empathy. A good employer empathizes enough with the employee enough so that they find firing to be painful, even if the firing is justified. But an employer who cannot, or will not, empathize with their employee basically treats their employee as a thing. And if they treat employees as things when it comes to firing, they'll treat them as things all the time. Which is an excellent way to create a terrible work environment.

<comment><USER25> But how an audition will improve anything? The marginal improvement in the new hire quality that you get from doing an audition is not worth the time and money spent on auditions plus the cost of lost candidates who took offers that did not require auditions.

<comment><USER26> Actually, I'm not advocating auditions. I'm also really not a fan of the StackOverflow/GitHub/you-shouldn't-have-a-life-outside-of-coding approach either. But just because that approach is overkill doesn't mean that interviews should be be treated lightly (and I think treating interviews lightly is unavoidable if an employer considers firing to be a routine tool).

</comment></comment></comment></comment></comment></comment><comment><USER27> Just a minor point about hiring young developers.

I was first employee in a start up before I even finished high school. A real start up, with backing from a top VC and an amazing founding team.

On the interview I looked eager to start getting shit done. I was super enthusiastic, asked hard questions, trash talked technologies - I looked like I actually knew what I was doing!

Then I went home and started to learn all those three letter acronyms they talked about.

You have to check that people can actually code. I'm not talking about algorithms, I'm talking about string truncation, url shortening service, time_ago_in_words - some programmers do know how to oversell themselves.

</comment><comment><USER28> Once you work at a few places and go through this process many times you get sick of it and create your own startup :P

</comment><comment><USER29> Though I'm not saying there aren't good points here, there are many, I think it's interesting to consider the usual impact of discussions on this subject - typically a great deal of insecurity/defensiveness (I feel it too), which I don't mean to say in a negative light, in fact I think it's quite natural.

It's worth quoting Steve Yegge's fantastic 'get that job at google' [1]:-

'Me: blah blah blah, I like asking question X in interviews, blah blah blah...

You: Question X? Oh man, I haven't heard about X since college! I've never needed it for my job! He asks that in interviews? But that means someone out there thinks it's important to know, and, and... I don't know it! If they detect my ignorance, not only will I be summarily fired for incompetence without so much as a thank-you, I will also be unemployable by people who ask question X! If people listen to Stevey, that will be everyone! I will become homeless and destitute! For not knowing something I've never needed before! This is horrible! I would attack X itself, except that I do not want to pick up a book and figure enough out about it to discredit it. Clearly I must yell a lot about how stupid Stevey is so that nobody will listen to him!'

[1]:[http://steve-yegge.blogspot.com/2008/03/get-that-job-at- goog...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html)

</comment><comment><USER30> The problem with stack overflow is that I ask for more questions than I answer.

There's a few reasons for this.

1) Finding time, although I can easily justify asking questions on SO at work it doesn't seem quite right using my employers time to answer somebodies (probably coursework) question and it's something I'd have a hard time justifying to the MBA types when there is other work that I could be doing. So my only option would be to go back home and specifically go on to answer questions.

2) Finding good questions to answer can be difficult since I only use a relatively small toolbox of software that is not particularly popular and I usually have more luck discussing it on google groups than on SO.

So that only leaves me with the easy lowest common denominator questions that have either already been answered or don't look terribly impressive to answer just as a way to earn points.

I would rather write a case study of developing something and problems that I solved along the way and publish this on a blog, of course I would have to be careful doing this about work things as well.

</comment><comment><USER31> These 5 phone screen questions are lifted almost directly from Steve Yegge's "Five essential phone screen questions" post - [https://sites.google.com/site/steveyegge2/five-essential- pho...](https://sites.google.com/site/steveyegge2/five-essential-phone-screen- questions)

      1) Coding. The candidate has to write some simple code, with correct syntax, in C, C++, or Java.
      2) OO design. The candidate has to define basic OO concepts, and come up with classes to model a simple problem.
      3) Scripting and regexes. The candidate has to describe how to find the phone numbers in 50,000 HTML pages.
      4) Data structures. The candidate has to demonstrate basic knowledge of the most common data structures.
      5) Bits and bytes. The candidate has to answer simple questions about bits, bytes, and binary numbers.

They even use the same regex example. He attributes other things to Steve, so maybe this is just an oversight, but I'd like to see another link.

</comment><comment><USER32> 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.

<comment><USER33> > 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.

<comment><USER32> 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.

</comment></comment></comment><comment><USER34> I see posts like this regularly on HN (lists of stuff you should do to hire that top 1% of talent). What I don't recall seeing, though, is a post more along the lines of employment branding. I understand how for very small start- ups that may just be a waste of time but when you get to a certain point it seems like you're going to want to do _something_. That might just be having a labs.yourCompany.com blog, or releasing an open-source project once in a while. I think that great devs want to work places where they know the work is interesting/fun/whatever. It's a lot easier for you to get the word out via say a blog, rather than have a 1-1 conversation with someone over the phone to communicate the cool stuff you're doing. Just my 2 cents.

</comment><comment><USER35> Totally agree with judging people based on their portfolio, however a lack of StackOverflow achievement currency or github commits doesn't signal much.

</comment><comment><USER36> I can see all sorts of ways that this will give you false negatives.

This is what I would recommend:

1\. Via an online test: check if they can code something very very simple. (This is your threshold that simply exists to not waste so much time.)

2\. In their CV: Look for public-facing indicators of skill: github account, stackoverflow account, blog posts, etc. (Bias towards candidates with these indicators, but do not discriminate against those without. These are indicators of true positives and not true negatives.)

3\. In a phone interview: ask about and then assess their breadth of knowledge. Find out their passion.

4\. In a phone interview: test the depth of their knowledge in a relevant category of knowledge. If they are struggling then attempt a question in something they're passionate about. (This is the point where you detect true negatives.)

5\. In the interview room: give them a choice of hard problems -- the sort you would want them to work on if they joined. (This is where you detect true positives.)

6\. In the interview room: find out whether they're the right cultural fit for your company. (This is where you filter out any true negatives that remain.)

</comment><comment><USER37> > Instead, I have my own theory about how we should interview programmers: > have the candidate give a 15 minute presentation on their area of expertise. > ... The one thing every programmer should know, per Steve Yegge, is how to > market yourself, your code, and your project. I wholeheartedly agree. Now > pitch me!

Yikes!

This really looks like an anti-test. I'd rather work with people who don't know how to market themselves -- that marketing skill would distort every technical discussion I had with them.

Even if that is a skill you want, a programmer who's really bad will almost certainly know how to bluff for 15 minutes -- they've been practicing their entire career! -- whereas a good programmer hit with that will probably wobble a bit looking for a topic.

Even if you have a extraordinary bullshit detector, it's still a poor signal. It won't tell you what the candidate is weak at -- and that's often the most important thing to determine.

</comment><comment><USER38> Actually this is entirely how I would expect to go about it.

I recently looked into the way my alma mater hires IT folks and they give you a set of around 6 essay questions. Things like "Please tell me about two projects which best define your ability in terms of X." X might be network engineer, web developer, etc. For grins and giggles (and to help me figure out my hiring process) I went ahead and filled it out. The result was essentially the sort of portfolio that they were asking about.

I do agree that you want to see someone's work but I don't think it needs to be an audition project. Even a properly done portfolio takes a bit of time to put together.

</comment><comment><USER39> Also worth reading: [http://www.deserettechnology.com/journal/writing-a-good- job-...](http://www.deserettechnology.com/journal/writing-a-good-job-ad-for-a- programmer), by HN's very own cookiecaper.

</comment><comment><USER40> It's funny to see a similar blog do exactly the kind of SEO targeting I've been doing: <http://gun.io/blog/how-to-hire-a-programmer/> Same title and everything. Hooray Google Keyword Tool! (The content is different, this is about full time employees and not freelancers.)

I'm glad to see that he recommends _actually paying_ the programmer doing the trial period! I see this kind of article a lot, the advice is always the same, but often they suggest the trial be unpaid.

</comment><comment><USER8> Interview is a two-way process. The company must know who are their good interviewers and who are not. A not-so-good interviewer may not only give false-positive feedbacks but also contributes to pass really good candidates. To be worse, a lousy interviewer may produce a negative image to the company and actually drive a good candidate away.

I think many people may have the experience that an interviewer was so rude and arrogant that no way would you join the company and work with the interviewer.

</comment><comment><USER41> #2 in addition to seeing their portfolio they should also give you a code review and explain what the code does.This avoids code plagiarism.

</comment><comment><USER42> I have issues with both #2 and #5, having just gone through the getting hired process myself. I think a portfolio is good, but I can't stand this "let's look at Github and Stack Overflow" attitude. To my interviews I brought four projects that I plan to sell one day and one project that I worked on but wasn't mine, so these projects are not open source and I don't like this trend of employers expecting all this open source code. I have real working programs in my portfolio, that should be good enough, if I show you the code you would just nitpick on it anyways.

Give them an audition project: Just no. The suggestions in the article definitely help, but audition projects as I've seen them are horrible, and even with the suggestions, you still need tons of time that you probably don't have unless you are unemployed. Maybe if it's an hour test-like thing, I had a good test project with a company that was an hour long, it tested me on a programming language I had never used, I guess it was more similar to a hello world programming example than anything else.

However my other experience with audition projects was the week type. It was two questions, given BEFORE the first interview as a pre-screen. The first was a 2 page single spaced paper on an economic question. This was about 10% the length of the major research paper I had to do around the same time, all I could think of was how much better my time would be spent doing that.

The coding question was far worse, something about triangulating a trapped miner using his cell phone records. There were so many things not explained that I would need, like the API of the cell phone records or how the data was stored that I felt like either I would have to ask the guy for more information than he would give or that it would be totally fake. Oh, and on top of all that, they gave me a deadline of the work week, not even a weekend. I was in school at that time and only had a few hours on weekday nights.

From my personal experience (which very well may be colored by the one example above), I would have to say that projects as part of a hiring process are for desperate candidates. It will screen out the dumb or lazy ones, but it will also screen out the skilled ones because they will figure it's not worth their time trying to do tons of work for a company that very well may not give them a job, and that the time would be better spent doing something REAL (and not unpaid work for the company either), maybe even a project to put in a portfolio and show off to all companies they are interviewing for.

</comment><comment><USER43> Why doesn't short-term contract to hire work? Seems like it would save a lot of time, with very little risk.

<comment><USER44> If you don't already have a job, there is little risk. However, if you have to quit your job to "try out" another job, you most likely want a little more assurance that you'll still have a job in a few months.

</comment></comment><comment><USER45> I always see these kind of hiring practices put into place and enforced AFTER I'm already hired and working. (no, I don't conjure up hiring practices like these.) Simply put - I wouldn't have gotten my own job if I had to conform to these standards.

</comment><comment> johnx123-up My personal favorite: How to interview a candidate/programmer [http://rajeshanbiah.blogspot.com/2009/01/how-to-interview- ca...](http://rajeshanbiah.blogspot.com/2009/01/how-to-interview- candidate.html)</comment>


Facebook failed to break into hardware: The untold story of Building 8 - <AUTHOR> https://www.cnbc.com/2019/08/02/facebooks-flop-in-hardware-the-untold-story-of-building-8.html <comment><USER2> Really fascinating article, and once again a reminder that hardware and software are two different animals with different timelines and processes.

2 humorous tidbits and 1 scary: >>The eight in Building 8 represented the number of letters in Facebook. Its physical location was inside Building 59 on Facebook's main campus in Menlo Park, California.

So the Building 8 team is not actually at a building called Building 8, but Building 59?

>>The exclusive invitations had arrived in the form of stainless steel slabs. To get into the event, attendees handed their invitation to a staffer, who put the slabs onto a machine programmed to cut the metal into a bottle opener. The staffer then handed back the bottle opener, along with a beer.

Just... peak Silicon Valley.

>>In early 2018, the remaining research projects were moved to Oculus Research, which has since been rebranded as Facebook Reality Labs, based in Redmond, Washington. That's where the company is working on a brain-reading interface — a noninvasive wearable device that will allow people to type using their thoughts.

The implications of this type of technology (especially used by FB) make me really uncomfortable. The ability to access, store, and analyze user thoughts is something that has the potential to be used in very wrong ways. Just another way to get even more specific and targeted user information, potentially information that I never intended on sharing with Facebook. What do other people think about this technology? Am I crazy?</comment>


Finish what you start - <AUTHOR>

I have big problem, and I have a feeling I'm not alone on this. I get an idea, I get super excited, work on it like crazy and then I either get burned out, or loose interest and eventually move onto something else. I've started 5 web apps, 4 iPhone apps, 1 hardware project, a blog. Out of all of those, I released one of the iPhone apps, which made me about $70 bucks (6 months), two web apps, one of which has had about 7k visits over the year (2 weeks) and another that just fizzled right away(2-3 years) and my blog which has had couple hundred visits over the year (ongoing).
Now I know those aren't very big numbers, but I've noticed something....you have to release and release early!!!! A  crappy project that gets released, fizzles and dies is still better by leaps and bounds, than a project thats been worked on for 2 years and never sees the light of day. Now I know this is all common sense and I know that everyone and their mom spews the release early mantra, but it's the truth. You need the positive feedback loop to keep you excited about working on something, otherwise it will die. What's even funnier is that the web app that took me the least amount of time to make, 2 weeks, is the one that succeeded the most in terms popularity and the one that took me the longest, 2-3 years, did the worst and I almost pulled the hair out of my head working on it. Life's funny like that...
Your thoughts? <comment><USER2> So you've learned about procrastination, and K.I.S.S.? ;)</comment>


Pager Turns Your Facebook Pages into Full-Fledged Websites - <AUTHOR> http://techcrunch.com/2015/05/03/pager-turns-your-facebook-pages-into-full-fledged-websites/?ncid=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29 <comment><USER2> Wow, all small businesses that turned their online presence into Facebook pages can now have the webpage back.

(The rule with the evolution never going backwards seemingly doesn't apply here.)</comment>