tanaypratap

Dear Recruiter,

First of all thanks for contacting me for the role which you have in mind. Let me tell you that I am extremely happy and contented at my current workplace. It provides a competing salary, a challenging environment and world class culture.

However, I am always open to better opportunities. But finding a time to get on a call for every inMail/message/opportunity is tough. So, let's continue this async form of communication where you give me details of the job and let me decide if I want to pursue it further.

Few details which I am looking for:

• Salary range Kindly do not ask my current CTC as I am not supposed to tell you that. As a recruiter, you're very much aware of the competing salary ranges in my domain with relevant experience. If the recruitment process requires the knowledge of my current CTC, I am sorry but I won't be further interested into that.
• Company Name If not an extremely famous brand, then please provide company's URL and background.
• Profile I do not pe

RobertAKARobin

Python is not a great programming language.

It's great for beginners. Then it turns into a mess.

• What's good
• What should be good
• What's "meh"
• What's bad
• What's bad about the culture

jeanlucaslima

Remote Jobs general guideline

This is something I compiled during the last weeks while job hunting. If you miss something in this list, please fork or tell me on twitter and I'll add what's missing.

1. Be careful with jobs that are not clear they hire outside US
2. Look for job in niches (like SaaS job boards, language-specific communities, country-focused, and so on)
3. Avoid Upwork (pay to work, no guaranteed results, often bad contracts) and Remote.com
4. Remote.co is not Remote.com, remote.co is ok.
5. There are companies that hire and act as a guild, but only pay as freelancer (X-team, Gun.io, and so on)
6. Not really focused on freelancing, as it is to me more like a one-person business

swyxio

4. Specialize in the New

You already know the value of a niche - you go up in market value the more specialized you are in anything. So what do you specialize in?

There are many schools of thought, including ones where you could be a generalist that doesn't specialize in anything. I find one rule to be simplest and most effective above all: Specialize in the New.

Didn't we just agree to avoid FOMO? Well yes, thats an important distinction - don't specialize in everything new. Specializing means you have to say no to a lot of things. Just pick something new that fascinates you, and hopefully many others as well. Since you're learning in public, you'll know when you hit on a real nerve. Budget in the idea that you'll fail a few times before you find Your Thing.

Then the other big objection: There are plenty of jobs/money/etc in (fill in the blank older technology) too! This is usually followed by some big numbers and anecdata. "My brother's cousin's roommate's friend took this COBOL job and now he's ear

swyxio

3. Clone Open Source Apps

You already know you should be making projects to learn things and potentially add to your portfolio. You've read your Malcolm Gladwell, you know that you need 10,000 hours of deliberate practice. Given you're just starting out, I have a slightly contentious suggestion for you: DON'T make anything new.

Your decision-making is a scarce resource. You start every day with a full tank, and as you make decisions through the day you gradually run low. We all know how good our late-late-night decisions are. Making a new app involves a thousand micro decisions - from what the app does, to how it should look, and everything in between. Decide now: Do you want to practice making technical decisions or product decisions?

Ok so you're coding. You know what involves making zero product decisions? Cloning things. Resist the urge to make your special snowflake (for now). Oh but then who would use yet another Hacker News clone? I've got news for you: No one was gonna use your thing anyway. You

vasanthk

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

1. Clarify and agree on the scope of the system

• User cases (description of sequences of events that, taken together, lead to a system doing something useful)
  • Who is going to use it?
  • How are they going to use it?