I'm not so sure that's a bad thing? If you understand and work well enough, what's wrong with understanding through your own idioms, etc?
Of course we read a lot of people's code, but I'm not so sure it's something that needs to be actively practiced rather than done naturally over a career (which makes recommending people to read code pointless if it happens naturally).
Sure, if you happen to be exposed to a wide variety of code as a result of your work, then probably you'll be fine.
But if all you do at work is line of business apps in VB6 for years on end, then I would recommend reading the source code for some games, database servers, your OS kernel, your favorite text editor, or something unrelated to your job. The point is to expand the scope of the projects that you're capable of undertaking.
Because no man is an island. Your code will never be perfect. There will always be things you miss or do suboptimally -- even for concepts you think you understand.
I personally find it useful for more than recruiting, such as sales etc. Shaving a few minutes off finding an email compounded over a day can save quite a bit of time allowing you to focus on more important things.
I am still testing several accounts, more than 90% are legit accounts that didn't changed password yet. Among the accounts I did find companies such as Microsoft, General Electric, EpicGames and more.
Kind of off topic, but doesn't github and other big companies use a services that automatically emails the owner and/or resets their password when their account information shows up on pastebin?
I received emails from https://rbnhd.com/ & https://changepassword.nu/ and found those emails on my spam folder (gmail). The emails were saying that my password was leaked. I never subscribed on any of the above services.
Have a clear understanding (and be able to explain) how to design different systems. For instance, you should be able to walk through (and sketch on a whiteboard) how to design a web service like Pastebin, Imgur, Pingdom or other such services.
You should be able to solve many common algorithmic problem patterns. It sucks, but the only way to get a job these days is to do well on coding interviews that are heavy in algorithmic problems, so do a lot of practice. The best way to practice is with a pen and paper, don't type up the solution until you're done and you've walked through it yourself.
Have a basic sense for social skills and learn to tell the company what they want to hear and make them feel special.
If you can do all three of those steps you've got a job.
You can say "no" without saying "no". Try this, "We can do that, but I've got a lot on my plate this week. Shall we log the task for next week or shuffle some tasks around different sprints to make room for it?"
There you go, 9 times out of 10 they will shelve the idea.
Not a fan of passive-aggressive tactics. I trust my colleagues to be forthright in their answers so giving a convoluted yes when it is actually a no builds distrust and resentment on my end. Sometimes a question is just a question and deserves an honest, no fluff answer.
I'm interested in figuring out statistics as well and I would love if someone could share any resources they use. The best tool I've found is LinkedIn search queries. It's pretty general but it gives you an idea.
Some other sites I use when deciding some technical requirements:
You can search for people with a given title, or a company that is in a specific industry, etc. You can do boolean searches and do pretty complex searches depending on your LinkedIn account (free, business, etc.).
For instance, you could find out how many companies are in the day care business in a specific state or in the US as a whole, etc. You could search for professionals with "day care" or "care taker" listed somewhere in their title or profile and do some basic guesses from there.
Can you explain what you liked about The War of Art? I read it because I have seen it mentioned on this site many times, but I did not enjoy it at all. I found that the first two sections contained very little useful information, and the third got somewhat silly when it started evoking angels and muses. I could see it being a motivational read for some?
I find it strange that it's mentioned in the same context as your #1 and #3, which I think are absolutely essential.
What exactly do you not want to share? Is this solely a concern you will leak visible information on your desktop, browser, etc? Or do you have deeper concerns about the communication channel and security etc?
I'd suggest using an audio call (phone, Skype, Google Hangout) and a code pad that is synced in realtime (free ones exist like collabedit.com). In other words, don't share your screen, share your voice.
Create a "fake" Gmail account that is not linked to anything personal.
Use a fake name/alias. Sign up for something like Cloud9 (https://c9.io) or use another synced editor like collabedit or even Google Docs (make sure to use the fake gmail account and not your own).
Sign up for Skype with the fake gmail account and fill out the details like you did on the fake gmail account.
Then sync up with someone online using audio only and using the synced editor of your choice.
You will leak your IP information most likely so they could figure out in what vicinity you live, but you could setup a proxy if you wanted even more security to hide your location.
As long as you're not hiding from any three letter agencies this is probably more than enough.
I didn't see any mention on how to secure store the session id, only references to session data. It should be noted that information needs to be securely stored both on the client and server.
Of course we read a lot of people's code, but I'm not so sure it's something that needs to be actively practiced rather than done naturally over a career (which makes recommending people to read code pointless if it happens naturally).