JS 网站上的招聘信息，
SWE Base 250K
Quant Base 300K
这都是NG 的职位
https://www.janestreet.com/join-jane-str...n=new-york

这个消息对波音公司是好是坏。如何影响股价
https://l.smartnews.com/p-Q5mCF/ZVQhYR
Boeing will lay off 10% of its employees as a strike by factory workers cripples airplane production

我最近给谷歌做个项目
和几个组开会。二十几口人。开二小时。最后我整明白了，在会的除了一个是谷歌正式员工，其他都是外包，contractors.
为省钱，解雇美国人，去印度外包。长此以往，死翘翘地啦。I heard Ackman sold all his google stake.
Meta, 疫情期间抢了不少AI人才，现在风生水起。这就是差别

工作市场竞争加剧是未来的常态，这种状态下的选校的思维
角度1：最强的孩子去哪儿都一样。这个可能对但未必全对。选校的目的不是证明自己多强，而是学校能否带来额外收益。一个不善于发挥软性资源的孩子，长期能走多远？所以答案恰恰是，越是强的孩子，越要考虑如何有选择性的领域，最好不要趋同。
角度2：名校是否有光环。肯定是有的，特别是对于中间部分的，名校加持的作用更明显。
角度3：行业退潮对什么部分影响最大。CS 的繁荣期（是个毕业生都有工作，而且收入大大超过其他行业）不可能永远这样。看看法学院，商学院的几十年的情况就清楚了，一线的学院还会很好，但后面的就业前景可能就非常一般了。所以竞争优势会向头部的集中。

### **Behavioral Question:**
**"Tell me about a time when you had to handle conflicting priorities on a project. How did you manage it, and what was the result?"**

### **Good Example Answer:**
"While leading a project to develop a new feature for our product, I encountered conflicting priorities from two different teams. The sales team wanted the feature to be delivered quickly to meet a client’s urgent request, while the engineering team was concerned about ensuring the feature was fully tested and met quality standards before release. Both priorities were valid, but they created tension regarding the timeline.

To address this, I first held meetings with both teams separately to fully understand their concerns and requirements. I realized that the sales team’s urgency was tied to a specific client demo, while the engineering team needed extra time for testing to ensure we wouldn’t introduce bugs. I brought both teams together for a joint meeting, where we discussed the constraints and came to a compromise.

We decided to prioritize a minimal viable version (MVP) of the feature for the client demo that would meet their core needs without overloading the development timeline. At the same time, we allocated time after the demo to complete additional testing and implement the full version of the feature. By clearly defining the scope and communicating openly with both teams, we were able to balance the conflicting priorities effectively.

The demo went well, and the client was happy with the MVP. The full feature was delivered two weeks later with all the necessary testing, and it was released without any major issues. The experience taught me the importance of facilitating collaboration, setting clear expectations, and finding a balanced solution when managing competing demands."

---

### **What You Should Not Say:**

1. **"I ignored the concerns of one team and focused solely on the more vocal team’s priorities."**
  - Demonstrates an inability to manage competing interests and risks alienating key stakeholders.

2. **"I tried to meet both demands without compromising, which led to an overstressed team and subpar results."**
  - Shows poor prioritization and lack of negotiation skills, leading to potential burnout and quality issues.

3. **"I didn’t consult with the teams and made a unilateral decision on my own."**
  - Reflects poor collaboration and decision-making, which could lead to friction and lack of team buy-in.

4. **"I delayed the project indefinitely because I couldn’t decide how to handle the conflicting priorities."**
  - Indicates indecisiveness and an inability to take action in a timely manner.

5. **"I compromised quality to meet the deadline, which caused issues after the feature was released."**
  - Suggests a short-term focus without considering the long-term impact of sacrificing quality.

### **Behavioral Question:**
**"Tell me about a time when you encountered a major roadblock in a project. How did you handle it, and what was the outcome?"**

### **Good Example Answer:**
"During a project to build a new feature for our platform, we hit a significant roadblock when a critical third-party API we were relying on became unreliable, causing data inconsistencies. The feature’s functionality depended heavily on this API, and without stable data, we couldn’t move forward. The project was already halfway through development, and deadlines were approaching.

I immediately convened a meeting with the team to assess the situation and explore potential solutions. Rather than halting the entire project, we decided to isolate the feature components that didn’t rely on the external API, allowing the rest of the development to continue while we figured out a way to handle the unreliable data source.

Next, I worked with the engineering team to create a caching mechanism to mitigate the impact of the API’s downtime. This allowed us to serve users previously fetched data while the API was unavailable, ensuring minimal disruption to the user experience. We also added more robust error handling to gracefully manage any API failures, giving the application a fallback system.

I made sure to keep stakeholders informed throughout the process, explaining the issue, the steps we were taking to resolve it, and how this affected the timeline. Once the caching system was implemented and tested, we were able to continue development and meet the original deadline with only a slight adjustment to our feature scope. In the end, the project was delivered on time, and the fallback system we implemented even improved the platform’s resilience against future third-party API issues. This experience taught me the importance of adaptability, creative problem-solving, and transparent communication when dealing with unexpected challenges."

---

### **What You Should Not Say:**

1. **"I waited for the third-party API to stabilize instead of trying to find a workaround."**
  - Suggests passivity and a lack of initiative in finding alternative solutions.

2. **"I didn’t communicate with the team or stakeholders and just tried to fix it on my own."**
  - Indicates poor collaboration and failure to keep key stakeholders informed, which can lead to confusion and frustration.

3. **"I focused solely on fixing the API issue and let the rest of the project stall."**
  - Reflects an inability to manage parallel tasks or find ways to keep the project moving forward despite roadblocks.

4. **"I blamed the third-party service for the delay and didn’t take ownership of the solution."**
  - Shows a lack of accountability and problem ownership, which is critical when facing external challenges.

5. **"I made changes to the system without fully testing the fallback, which caused more issues later."**
  - Highlights poor attention to detail and testing, which can lead to greater problems down the line.

### **Behavioral Question:**
**"Tell me about a time when you had to refactor or redesign a front-end component due to performance issues. How did you approach the problem, and what was the outcome?"**

### **Good Example Answer:**
"While working on a web application, we started receiving complaints from users that a key dashboard component was loading slowly, especially when handling large datasets. This component was crucial for users to analyze data, and the performance issues were affecting the overall user experience.

I began by profiling the application to identify performance bottlenecks. The main issue turned out to be inefficient rendering due to the way we were handling data updates—every time the data changed, the entire component re-rendered, even for minor updates. Additionally, the component wasn’t optimized for virtual scrolling, which led to heavy memory usage when large datasets were loaded.

To resolve this, I first refactored the component to implement React's `shouldComponentUpdate` and memoization techniques, ensuring that only the necessary parts of the UI re-rendered when data changed. I also introduced virtualized lists to handle large data more efficiently, allowing the dashboard to render only the visible rows instead of the entire dataset at once.

Next, I optimized the data fetching logic by implementing lazy loading, so that the dashboard only retrieved data when the user needed it, reducing initial load times. Throughout the process, I kept close communication with the design and backend teams to ensure that the changes didn’t break any existing features or APIs.

After these optimizations, we saw a 40% improvement in load times and smoother interaction with large datasets. User feedback was overwhelmingly positive, and the application became much more responsive, particularly for our power users who dealt with large data daily. The experience reinforced the importance of profiling performance issues early and leveraging techniques like memoization and virtualization to improve front-end efficiency."

---

### **What You Should Not Say:**

1. **"I decided to rebuild the entire component from scratch without analyzing the root cause of the issue."**
  - Shows a lack of problem-solving focus, opting for a complete rebuild instead of targeting the specific performance bottlenecks.

2. **"I didn’t bother profiling the application and just tried random fixes until something worked."**
  - Reflects a trial-and-error approach rather than a structured, data-driven approach to problem-solving.

3. **"I focused only on fixing the performance issue but didn’t test for any potential breakages or regressions."**
  - Suggests a lack of thoroughness, which could lead to new bugs or issues in other parts of the application.

4. **"I didn’t communicate with the backend or design teams, so I implemented changes that caused inconsistencies with other components."**
  - Demonstrates poor collaboration, which can result in misalignment and unexpected issues when integrating with other parts of the system.

5. **"I didn’t measure the performance improvements after making the changes, so I don’t know how effective they were."**
  - Indicates a lack of validation, which is crucial when solving performance issues to ensure the solution is impactful.

### **Behavioral Question:**
**"Tell me about a time when your machine learning model didn’t perform as expected after deployment. How did you handle the situation, and what changes did you make?"**

### **Good Example Answer:**
"While working on a fraud detection model for a financial services client, our model performed exceptionally well during development and testing, with high precision and recall metrics. However, after deploying the model into production, we began receiving feedback from the operations team that the model was generating a high number of false positives, flagging legitimate transactions as fraud. This caused frustration for both customers and internal teams.

I immediately gathered detailed logs from the production environment and compared them to our test data. One of the first things I noticed was that the distribution of transactions in the live data differed significantly from the data we used to train the model. This was likely due to changes in customer behavior and newer fraud patterns that weren’t present in the training data.

To address this, I collaborated with the data team to acquire more recent and representative data to retrain the model. I also introduced a more dynamic data pipeline that would refresh the training data periodically to keep it up-to-date with current transaction patterns. Additionally, I implemented an ensemble method combining the original model with a more interpretable rules-based system, which allowed us to catch complex fraud cases while giving the business team control over some decision-making thresholds.

Once these changes were implemented, we redeployed the model and closely monitored its performance. The false positive rate dropped by 30%, and customer complaints decreased significantly. This experience reinforced the importance of continuously monitoring and retraining models in production environments and ensuring that your training data is reflective of real-world conditions."

---

### **What You Should Not Say:**

1. **"I ignored the issue, thinking it was an anomaly and would resolve itself over time."**
  - Indicates a lack of ownership and failure to address production issues promptly.

2. **"I blamed the data team for providing outdated data without taking steps to resolve it myself."**
  - Reflects a lack of collaboration and problem ownership, which are critical for cross-functional projects.

3. **"I made quick tweaks to the model without gathering enough data or understanding the root cause."**
  - Demonstrates a short-sighted approach and failure to investigate the issue deeply, which can lead to recurring problems.

4. **"I didn’t update stakeholders or the operations team until after the issue was resolved."**
  - Shows poor communication and could lead to stakeholder frustration due to lack of transparency.

5. **"I replaced the model entirely instead of trying to fix it, which delayed the project significantly."**
  - Indicates a lack of problem-solving and troubleshooting skills, opting for drastic solutions instead of incremental fixes.

### **Behavioral Question:**
**"Tell me about a time when you had to redesign or rework a machine learning model due to unexpected challenges. How did you approach the situation, and what was the final outcome?"**

### **Good Example Answer:**
"During a project to build a recommendation engine for a retail client, we initially designed a collaborative filtering model based on user interaction data. However, after deployment, the model’s performance was lower than expected—particularly for users with sparse interaction history. This led to irrelevant recommendations for a significant portion of the user base.

I knew we needed a different approach, so I gathered the team to analyze the model’s performance and data patterns. We identified the cold-start problem as the key issue—new or less active users weren’t receiving meaningful recommendations. To address this, I proposed a hybrid model that combined collaborative filtering with content-based filtering, leveraging product metadata and user demographics to fill in the gaps for those users.

We set up an A/B testing framework to compare the performance of the new hybrid model against the original one. While doing this, I kept stakeholders informed about the change in strategy and adjusted the project timeline to accommodate the additional work. My team and I worked closely to fine-tune the feature engineering process, ensuring the content-based features were relevant and didn’t introduce noise into the system.

The hybrid model significantly improved the recommendation quality, especially for new users, and we saw a 15% increase in click-through rates during the A/B tests. This approach not only solved the immediate cold-start issue but also made the recommendation engine more robust to user variability. The project reinforced the importance of flexibility in model design and the need to constantly reassess assumptions based on real-world data."

---

### **What You Should Not Say:**

1. **"I stuck with the original model even though it wasn’t performing well and just tried to tweak the parameters."**
  - Shows resistance to adapting to new challenges and a lack of problem-solving creativity.

2. **"I didn’t analyze why the model wasn’t working and moved on to a new technique without understanding the root cause."**
  - Reflects poor troubleshooting skills and a failure to diagnose underlying issues.

3. **"I made changes to the model on my own without discussing with the team or getting input from stakeholders."**
  - Suggests poor collaboration and communication, which can lead to misaligned goals or unexpected issues down the road.

4. **"I didn’t test the new approach properly and deployed it without measuring performance improvements."**
  - Demonstrates a lack of attention to validation and testing, which is critical in machine learning workflows.

5. **"I didn’t keep the client or stakeholders informed about the changes and only updated them after the model was live."**
  - Fails to keep stakeholders in the loop, which can lead to dissatisfaction or misaligned expectations if the change doesn’t deliver results.

### **Behavioral Question:**
**"Describe a time when you had to implement a significant change in a project. How did you manage the change, and what was the outcome?"**

### **Good Example Answer:**
"While working on a product launch, we were halfway through development when the leadership team decided to pivot the project’s focus based on newly gathered customer insights. The original feature set we were building no longer aligned with customer needs, and we had to shift to a completely different set of features. This change required not only technical adjustments but also managing the team’s morale and keeping the stakeholders informed.

The first step I took was to gather the team and have an open discussion about the change. I made sure everyone understood the reason behind the pivot and how it would impact the project. Then, we reassessed the project timeline, identifying which parts of the original work could be salvaged and which tasks needed to be re-prioritized. I worked closely with the product manager to define the new scope and realistic deadlines.

To ensure a smooth transition, I introduced a phased implementation plan. This allowed us to release smaller increments of the new features without sacrificing quality or missing deadlines. I also made sure to provide regular updates to the stakeholders, particularly about any risks or challenges we encountered during the transition.

By maintaining close communication and breaking down the change into manageable steps, we were able to deliver the new feature set within the revised timeline. In the end, the pivot paid off, as customer feedback was overwhelmingly positive, and the product gained better traction in the market. The experience taught me the value of adaptability, structured planning, and keeping both the team and stakeholders aligned throughout significant changes."

---

### **What You Should Not Say:**

1. **"I didn’t agree with the change, so I kept pushing back and tried to continue with the original plan."**
  - Demonstrates resistance to change and a lack of adaptability, which is essential in dynamic environments.

2. **"I implemented the change without informing the team, thinking they’d figure it out along the way."**
  - Reflects poor communication and leadership, which can lead to confusion and team frustration.

3. **"I didn’t reassess the timeline or scope and tried to fit the new requirements into the original plan."**
  - Shows an inability to realistically plan, which could result in rushed work, missed deadlines, or poor-quality output.

4. **"I left the team to manage the change on their own and focused on handling stakeholder communication."**
  - Suggests a lack of involvement and support for the team during a challenging transition, which can hurt morale and productivity.

5. **"I was so focused on the change that I didn’t communicate with stakeholders until after it was completed."**
  - Highlights a failure to keep stakeholders informed, which could result in surprises, dissatisfaction, or even project delays due to unmet expectations.