Link to Original Source
Link to Original Source
> As a hiring manager, I can tell you that I almost never have the time to go dig through a prospective candidate's open source code
I also have had the responsibility for hiring people from time to time. And OMG you are hiring a *programmer*. This is the *primary* thing they are going to be doing after you hire them. Their code is their main work product. The information is available to you and you're just going to *ignore* it? Who cares how charming and articulate they are if their code is crappy?
You could assess these things in 15 minutes in a 13kLOC code base. Did they write clear and useful comments? Is the code well organized? Is the high-level structure obvious? It's an excellent second- or third-pass method, and I've always found it pretty weird that it's not a more common practice.
Okay, maybe you have some reason to doubt that they actually wrote it or whatever. And of course they will be showing you the awesomest, cleanest little gem they ever wrote. Weigh it appropriately. But don't weigh it at 0%!
I want programmers who can write code AND are articulate and charming. Someone who is articulate and charming but cannot write code should not be hired as a programmer.
OTOH someone who can write code but is not particularly charming can still be a great contributor if they are not a total asshole, and can explain their code clearly in comments or in small meetings.
Probably the reason most hiring managers don't want to review candidates' code is because they are not particularly skilled at reading code quickly and making a useful judgment about its quality. This just means that the hiring manager isn't qualified to judge the candidate on this critical dimension. They should admit this limitation and farm out the task to someone else in their company whom they trust. (If there is no such person in their company then their company is pretty well fucked anyway.)
> Not to mention, most of the time open repositories like that are blocked from my work network anyway
Okay, but this is not a statement about the objective predictive utility of a hiring process that involves code reviews. It's just a statement that your company is toopid.
> can the candidate speak, in detail, to their resume. Many can't, by the way
Totally agree with you on this point. It's amazing how many people just blatantly lie on their resume. In my experience it's, like, way more than half.
This makes it frustrating for people who are honest on their resumes, since managers have to take steps to weed out the significant population of liars out there.
"So what's the difference between TCP and UDP?"
"I have been writing network protocol stacks for 138 years. I sleep with a printed copy of the TCP state machine under my pillow, and all night little synsies and finsies dance through my dreams. I hang out with Vint Cerf every weekend. It says so right on my resume. Why don't you believe me?"
"Because 95% of people who say that cannot articulate a reasonable answer to my question.
I guess until we can get most people to stop lying on their resumes, that will just be a fact of life.
That's probably the best single post made on
It would have been even better if it were not wildly incorrect. You can't cancel an order once it has been executed. The grandparent sounds super confident, but is largely making stuff up.
And, as other people on this thread have already said: your habit of throwing stuff into production without testing it is similar to playing Russian Roulette with your company. Stop that. Stop that right now.
2. Actively inject fake higher prices into competing web pages' HTML as it flies through your local router. Customer thinks the price in your store is the best one.
To everybody here suggesting relational databases: you are on the wrong track here, I'm afraid to tell you. Relational databases handle large sets of completely homogenious data
Wrong. We're not on the wrong track. Databases don't only handle "homogeneous data" sets. You just don't know how to use them flexibly.
if you can be bothered to write software for all the I/O around them
Wrong. Databases abstract away I/O primitives and file formats, making creating/accessing your data much simpler than using (e.g.) flat text files.
nothing beats plain old ASCII text files!
Wrong. A great many things beat flat text files, under a great many use cases. The capabilities of (e.g.) a sqlite database are a strict (and much larger) superset of those of flat text files, while usually being *less* burdensome to their users.
how would you load the contents your database table into gnuplot
You can always dump your db contents to a flat ascii format if you need to (like to send the data to gnuplot).
Just because *you* don't know how to properly use a db doesn't mean you should shoot down the very idea in such broad strokes.
- 0. The basic idea here is that you are replacing this whole hierarchy of files and directories by a single file that will contain all your data from an experiment. You figure out ahead of time what data the database will hold and specify that to SQLite. Then you to create, update, read, and destroy records as you see fit--pretty much as many records as you want. (I personally have created billions of records in a single database, though I'm sure you could make more.) Once you have records in your database, you can with great flexibility define which result sets you want from the data. SQLite will compute the result sets for you.
- 1. SQLite is easy to learn and use properly. This is as opposed to other database management systems, which require you to do lots of computery things that are probably overkill for you.
- 2. Your entire data set sits in a single file. If you're not in the middle of using the file, you can back up the database by simply copying the file somewhere else.
- 3. Transactions. You can wrap a large set of updates into a single "transaction". These have some nice properties that you will want:
- 3.1. Atomic. A transaction either fully happens or (if e.g. there was some problem) fully does not happen.
- 3.2. Consistent. If you write some consistency rules into your database, then those consistency rules are always satisfied after a transaction (whether or not the transaction was successful).
- 3.3 Isolated. (Not likely to be important to you.) If you have two programs, one writing a transaction to the database file while the other reads it, then the reader will either see the WHOLE transaction or NONE of it, even if the writer and reader are operating concurrently.
- 3.4. Durable. Once SQLite tells you the transaction has happened, it never "un-happens".
- These properties hold even if your computer loses power in the middle of the transaction.
- 4. Excellent scripting APIs. You are a physical sciences researcher -- in my experience this means you have at least a little knowledge of basic programming. Depending on what you're doing, this might greatly help you to get what you need out of your data set. You may have a scripting language that you prefer -- if so, it likely has a nice interface to SQLite. If you don't already know a language, I personally recommend Tcl -- it's an extremely easy language to get going with, and has tremendous support directly from the SQLite developers.
Good luck and enjoy!
But with results like 2-1 it's pretty much down to $random circumstance of the day.
My god. What are the moderators thinking?
I've been playing the game for 23 years, was trained by world-class coaches, and I'm here to tell you that you don't know what you're talking about.
Because in 80% of the matches it makes fans go "If only..."
It's part of the joy of the game, part of the culture of the game to wish and hope for your team to win. But just because a fan thinks something doesn't make it so.
this is mostly luck
If that were true, a group of randomly-chosen people would have a similar chance of winning the world cup as e.g. Germany. Which is, of course, ridiculous.
Obviously the game has a lot of problems, and some of those topics are hot today. The game arguably needs to be refined in a couple ways.
But it is absolutely *not true* soccer "isn't about making the best team win" or that it's "mostly luck". The overwhelming majority of the time, the best team *does* win. It's just that when that happens, it isn't big news.
Update: 05/21 12:11 GMT by KD : And now add Twitter to the blocked list. This post claims that more than 1,000 sites are being blocked in Pakistan.
You already know people connected to the industry -- talk to them! Ask your profs if they know anybody in the industry. Ask your jobful friends to pass your resume along. Is there a famous prof at your uni? Did you take a class with them? Bring your chutzpah to their office and ask for a rec.
A referral from a trusted third party is thousands of times more likely to get your foot in the door than your resume, no matter how bloody sparkly the thing is.
Case in point, I graduated summa cum laude from an Ivy school, and no one really gave much of a shit. Until I knocked on my algo prof's door once during his office hours, asked him whether he knew someone in industry looking for a smart hard-working youngster. He gave me the name of his contact (the CEO of a tiny co). (I didn't even do that well in the Prof's class, slightly below median IIRC.)
Next thing I know the CEO's shaking my hand congratulating me on my new 50%-pay job. He's telling me "boy have you ever got a lot to learn, but Prof so-n-so says you're smart and you do seem to come off that way". Worked my arse off til it turned into a real job. And now there are *2* people out there who think I'm smart, so, you know, twice the network
If you don't have a network, make one. Think about doing an unpaid internship at a company that has a future. (Look into funding options from your uni for this kind of stuff.) Be careful with this one -- the network you create here must be valuable to justify the work and the resume gap.
I had the privilege once to speak with the former-CFO of Coke, and asked her (rather lamely) how one winds up being the CFO of Coke. She said, "If you really want a big-time job you gotta be aggressive and you gotta be charming."
Note that "qualified" is not a part of that sentence.
I can program!
Broken thinking. Getting hired isn't about being good at the job. It's about being good at getting hired, which is a largely orthogonal skill set.
Need new skill set = need to practice. Interviews are like first dates: they pretty much all suck, but get less nerve-wrecking with practice.
I should mention that once you have job 1, the network it creates (or doesn't create) will bear heavily on how your search for job 2 goes. So take good care of your network at job 1. I've seen a ton of smart people with amazing resumes, who are actually quite good programmers, who can't find jobs because they are huge pains in the ass. The days of the cranky-bitch-genius-programmer are limited (if not completely over), because there are plenty of pleasant-genius-programmers out there who need jobs too.
Approach your job like a pro: learn the politics and the people, be friendly, be polite but not stodgy. Choose very carefully which personal details to share with which people. Never express a negative emotion unless you've thought about it extremely thoroughly. Never write an email to/from a work account that you wouldn't want the CEO to read. Get people to like you: morally it shouldn't matter, but practically it makes a gigantic difference to how your career will go.
Finally and of course most importantly, work your ass off and get results. Nothing will make boss-man like you more than if you are generating two times the output as everyone else, with a smile and a joke handy at lunch time. It makes him look fabulous to his boss, and ten years from now when he's working at google (or whatever the "google" of 2020 will be, probably "google"), guess where you can ship an email and probably get a job.
So Microsoft secretly filed a suit against 27 unnamed individuals, and got a secret order taking 277 domain names away from them, all based on a mere accusation.
Oh, but since we're fighting spam, I guess that's okay.
Wait until Microsoft starts doing this to go after copyright violations. Will y'all be cheering then?
My fiancée IAL working in a federal district court. I have mod points, but I guess it's more illuminating to reply than mod down this ridiculous comment.
Stuff is filed under seal in court all the time. The idea is that you don't want the defendant you're pursuing to know you're pursuing them if there's a high chance they can cover their tracks. You can't just make a "mere accusation" and get a court to do whatever you want. That, of course, would be silly.
Most judges are really quite reasonable about the decision to keep things sealed. In any event, all the docs will become unsealed relatively quickly -- and if you think the court was *unreasonable*, that they abused their discretion somehow, you can take your complaint to the appellate court.
Court proceedings are slow, but some crooks (especially intelligent, well-funded crooks) can move fast. This is the balance we've found between thinking things through carefully, and satisfying the public's right to this information, while still prosecuting agile crooks.
In copyright infringement cases, the plaintiff would probably have a hard time convincing the judge that docs need to stay sealed.
Believe it or not, the system actually works pretty well sometimes.
Look, I'm all for an intelligent discussion of the shortcomings of the legal system, of which there are plenty. But you should really try to learn something about it before criticizing it. Otherwise you're just wasting everyone's time.
So I've been using this line in my crontab for a long time now without any problems (well no more problems than I usually experience with Flash under Linux):
* * * * * rm -fr
I think this solves the problem, but maybe I'm mistaken...?
That depends on your threat model. Your cron job might keep your kid brother from discovering your cookies. If you *really* don't want people to know what flash is caching, I'd s/rm -rf/shred -uf/ there for starters. Then I'd think about putting my whole OS on an encrypted partition (trivial these days with Fedora, not sure about other distribs).
Of course, you still have problem with sniffing and all manner of malware, all of which could defeat your goal of preventing people from knowing what kind of flash content you're downloading.
I hung out with Bruce Schneier for a 1-hour talk once. If you want to scale up your paranoia further, you can do what he does: never let your computer touch a network or another person's hands. He has no wireless card, never plugs an ethernet cord into the slot, and never gives his compy to anyone else. Very difficult to sniff traffic that doesn't exist (but not impossible).