Here’s a summary of my job search history:

What changed?

1. I focused on building real industry-level skills, not just pretending to have skills on my resume.
2. I simplified the styling on my resume for ATS friendliness, making it in Word with simple text and formatting.
3. I laser-focused my resume and removed all the unnecessary details. I took out experiences that weren't relevant to the jobs I was applying for, even though I was proud of them and wanted to keep them.
4. I built an awesome portfolio and used this opportunity to show that I can build!
5. I started posting on LinkedIn about things I know or learn. This showcased my technical skills and who I am as a person.
6. I focused on quality over quantity when applying for jobs. I only applied to positions I believed I was a good fit for. Then, I reached out to every person I could find within those companies (recruiters, developers, managers) and didn't settle until I got an interview call. I know I'm an excellent fit, and I won’t let them miss out on me.
7. It's easier to get interviews if you have some prior experience, so I sought out opportunities to gain experience, even if it meant working for free.

1. Be in a constant state of attracting. Believe that the job you're seeking is getting closer to you day by day. It's just around the corner.
2. Let every achievement be just a byproduct of your self-improvement. Don't make your life dependent on that new job. Remember, self-improvement is your ultimate goal.
3. Set a goal, tell yourself, and write it down every day: "You'll get your new job in the next 3 months!"

1. I focused 70% of my time on improving my technical skills in RoR and React.
2. I dedicated 20% of my time to applying for RoR-specific jobs and reaching out to people in those companies.
3. I spent 10% of my time writing blogs, posting on LinkedIn, and updating my resume and portfolio.
4. Always: Take care of yourself.

Key concepts in system design:

1. CDN (Content Delivery Network): A network of distributed servers that deliver web content to users based on their geographic location, improving load times, reliability, and availability by caching content closer to end-users.

• Message Queue (Kafka): A system that enables asynchronous communication between services by queuing messages until they can be processed, providing fault tolerance and decoupling services.
• Pub-Sub Model: A messaging pattern where messages are published to topics and subscribers receive those messages based on their interests, allowing for scalable and flexible communication between distributed systems.

Rough checklist to keep in mind when designing an API:

def get_profiles

get 'users/fetch_profiles', to: 'users#get_profile'

post 'users/update_profile', to: 'users#update_profile'

def verify_signature
    provided_signature = request.headers['X-Signature']
    payload = request.raw_post
    # Compute the HMAC digest based on the payload of the request
    computed_signature = OpenSSL::HMAC.hexdigest('sha256', SECRET_KEY, payload)
    unless ActiveSupport::SecurityUtils.secure_compare(computed_signature, provided_signature)
      render json: { error: 'Invalid signature' }, status: :unauthorized
    end
  end

def get_profile (int profile_id, char user_name, char location)

{
profile_id: 10,
user_name: 'Rushi Patel'
location: 'Canada'
settings: {mode: 'dark', zoom: 100, language: 'EN'}
}

query = query.limit(params[:limit] || 5000)

if !params[:limit].present? || params[:limit].to_i > 5000
      render(json: { error: 'Limit must be present and less than 5000' }, status: :bad_request) and return
end

get 'users/fetch_profiles/v2', to: 'users#get_profile_v2'

def get_profiles_v2

end

Learn abstraction to move fast. Learn fundamentals to innovate.

Users have crazy ways of finding workarounds.

The [End] tag was meant to act as a delimiter when a nurse moved from one patient to another and to separate patient-specific logs from general logs not meant for any patient. The app was supposed to segregate the 'Log' for each patient based on their name and the [End] tag, and save the entries in their respective profiles.

Even after watching some training videos, the purpose of the [End] tag was not clear to them, and they didn't realize they could enter multiple patients in one form. Instead, they created separate forms for each patient. Due to incorrect [End] tag placement, the log text was not being saved to the correct patient profile.

Notes on Setting Up Deployment with Dokku and Git:

Here's a fun comparison between STRIP, SQUEEZE, SQUISH with an example:

name = " Rushi   Patel "

name.strip
Output: "Rushi   Patel"

name.squeeze
Output: " Rushi Patel "

name.squish
Output: "Rushi Patel"

1. User experience trade-offs
2. Complexity

1. Open the post in a new page:

2. Stick to the popup we already have but:

•  Add the post_id in the URL, 
• auto-open the popup
• auto-scroll to that part of the screen

Comparative Analysis:

Let's make a decision by asking these questions:

1. Do I want to promote my site in the near future? No (not in the world of AI).
2. Is it just for my own documentation of progress? Yes!
3. Am I willing to compromise on disrupting the user's reading flow? No (I'm aware of how short viewers' attention spans are.)
4. How much time do I want to spend? MINIMAL

• Gather and understand all requirements
• Use analytics data to make informed decisions
• Determine the urgency of the feature
• Assess the budget
• Evaluate the team's capacity
• Discuss trade-offs

We don't want to build a sword to cut vegetables!

num = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
even = num.select(&:even?)
puts 'num:' + num.to_s
puts 'even:' + even.to_s

output:
num:[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
even:[2, 4, 6, 8, 10]

num = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
even = num.select!(&:even?)
puts 'num:' + num.to_s
puts 'even:' + even.to_s

output:
num:[2, 4, 6, 8, 10]
even:[2, 4, 6, 8, 10]

num = [2, 4, 6, 8, 10]
even = num.select!(&:even?)
puts 'num:' + num.to_s
puts 'even:' + even.to_s

output:
num:[2, 4, 6, 8, 10]
even:

Difference:

Use Includes over Join:

• when you want to eager load associated records to avoid N+1 query problems.
• when the data is small that won't overload the memory.
• when the data doesn't change very frequently or until an operation is performed on the data loaded into memory.

Use Join  over Includes:

• when you DO NOT need to load the entire associated records.
• when your query involves complex conditions that need to be applied to the associated models.
• when you just need to filter or perform calculations based on them.