Interview Questions & Answers

Bộ câu hỏi phỏng vấn comprehensive dựa trên kinh nghiệm thực tế từ các dự án.

Mục lục

Technical Questions by Project
System Design Questions
Backend Deep Dive
Behavioral Questions
Salary Negotiation

1. Technical Questions by Project

KF Project - Optimizely CMS

Q: Tích hợp Google Maps vào CMS như thế nào?

Context: Đây là câu hỏi core về dự án KF Project.

Câu trả lời mẫu (STAR method):

S (Situation): 
"Khách hàng cần CMS cho phép content editors quản lý locations với map visualization."

T (Task): 
"Tôi được giao thiết kế và implement Google Maps integration với yêu cầu:
- Editors có thể chọn location trên map
- Lưu tọa độ vào CMS
- Hiển thị store locator cho end users"

A (Action): 
"Tôi đã implement solution với các thành phần:

1. Backend API (.NET Core):
   - REST endpoints cho CRUD locations
   - Geocoding service với caching
   - Spatial queries với SQL Server

2. Frontend (React):
   - Google Maps React component
   - Interactive marker placement
   - Viewport-based lazy loading

3. Optimization:
   - Redis cache cho geocoding results
   - Batching cho bulk imports
   - CDN cho map tiles"

R (Result): 
"Kết quả:
- Page load time giảm từ 4.5s → 1.8s (60% faster)
- Map render time giảm từ 2.1s → 0.4s (81% faster)
- Content editors tiết kiệm 70% thời gian quản lý locations"

Code snippet để share (nếu có whiteboard):

// Location Service với caching
public class CachedLocationService
{
    public async Task<LocationDto> GetLocationAsync(int id)
    {
        var cacheKey = $"location:{id}";
        
        // Try cache first
        var cached = await _cache.GetAsync<LocationDto>(cacheKey);
        if (cached != null) return cached;
        
        // Cache miss - query database
        var location = await _repository.GetByIdAsync(id);
        
        // Cache for 30 minutes
        await _cache.SetAsync(cacheKey, location, TimeSpan.FromMinutes(30));
        
        return location;
    }
}

Q: Bạn xử lý concurrency trong CMS như thế nào?

"Tôi implement optimistic concurrency control với ETags:

1. Khi client GET resource, server trả về ETag header
2. Khi client PUT/PATCH, gửi ETag trong If-Match header
3. Server so sánh ETag với current version
4. Nếu mismatch → trả về 409 Conflict

Implementation:
- Optimizely tự động quản lý content versions
- Custom ETag calculation dựa trên content hash
- Conflict resolution UI cho editors

Kết quả: Zero data loss từ concurrent edits."

SKCC Project - Industrial Monitoring

Q: Thiết kế hệ thống real-time monitoring với hàng ngàn sensors?

Câu trả lời:

S: "Nhà máy cần monitoring system cho 5000+ sensors với update frequency 1-5 giây."

T: "Design system với yêu cầu:
- End-to-end latency < 2s
- Xử lý 10,000+ events/giây
- Real-time visualization
- Alert khi vượt thresholds"

A: "Architecture:

1. Data Ingestion:
   - .NET Core service nhận sensor data
   - Validate và transform data
   - Publish events lên Azure Service Bus

2. Data Storage:
   - ElasticSearch cho time-series data
   - Index rollover monthly
   - SQL Server cho metadata

3. Real-time Processing:
   - Alert service consume events
   - Check thresholds với rule engine
   - Trigger notifications qua webhooks

4. Visualization:
   - WPF client với SignalR connection
   - Chart downsampling (LTTB algorithm)
   - Data virtualization cho performance

5. Optimization:
   - Batch processing với Channel<T>
   - Connection pooling cho ElasticSearch
   - Circuit breaker cho webhook calls"

R: "Metrics:
- Event processing latency: 5.2s → 0.8s (85% faster)
- Chart render time: 3.5s → 0.3s (91% faster)
- Webhook success rate: 78% → 99.5%"

Q: ElasticSearch optimization techniques bạn đã dùng?

"Tôi đã apply các optimization techniques sau:

1. Index Design:
   - Index templates với proper mappings
   - Keyword fields cho exact match
   - Disable _source cho fields không cần

2. ILM (Index Lifecycle Management):
   - Hot phase: 30 days, 3 shards
   - Warm phase: Shrink to 1 shard
   - Delete after 2 years

3. Query Optimization:
   - Use filter context thay vì query context
   - search_after cho deep pagination
   - Aggregations thay vì fetch all docs

4. Write Performance:
   - Bulk indexing với batch size 1000
   - Refresh interval 5s (default 1s)
   - Translog async

5. Read Performance:
   - Request cache cho frequent queries
   - Shard allocation awareness
   - Force merge cho old indices"

PTG.PPPlus3 - Pension System

Q: Bạn đã optimize report generation như thế nào?

S: "Report generation mất 15-20 giây, users phải wait synchronous."

T: "Mục tiêu: Giảm xuống < 3s, improve user experience."

A: "Solution với 3 phases:

Phase 1 - Background Jobs:
- Move report generation khỏi request pipeline
- Azure Service Bus queues cho job scheduling
- SignalR cho real-time progress updates
- Users receive notification khi report ready

Phase 2 - Data Optimization:
- Batch queries thay vì N+1
- Include() để eager load
- Split large queries into chunks
- SqlBulkCopy cho intermediate storage

Phase 3 - Pre-generation:
- Generate JSON reports asynchronously
- Compress với GZip
- Store trong Azure Blob Storage
- Serve static files thay vì dynamic generation

Additional:
- Priority queues cho critical reports
- Retry policy với exponential backoff
- Dead letter queue cho failed jobs"

R: "Results:
- Report time: 15-20s → 2-3s (85% faster)
- Database CPU: 95% → 45% (53% reduction)
- User satisfaction: 3.2/5 → 4.6/5"

Q: Pre-calculation strategy cho pension calculations?

"Problem: Calculation phức tạp mất 5-10 giây cho mỗi member.

Solution - Event-driven Pre-calculation:

1. Trigger Events:
   - Salary update
   - Service year added
   - Rule changes
   - Year-end rollover

2. Calculation Scheduling:
   - Urgent events: Calculate within 5 minutes
   - Non-urgent: Batch at off-peak hours (2 AM)
   - Bulk recalculation: For rule changes

3. Caching:
   - Redis cache cho latest results
   - Cache TTL: 24 hours
   - Cache invalidation on new calculation

4. Storage:
   - Save calculation results với breakdown
   - Store input snapshot cho audit
   - Version control cho calculation rules

5. Consistency:
   - Transactional outbox pattern
   - Event sourcing cho audit trail
   - Idempotent calculation jobs

Result: Calculation time 5-10s → < 1s (cache hit)"

2. System Design Questions

Q: Design a URL Shortener

Gợi ý trả lời:

1. Requirements:
   - Functional: Shorten URL, redirect, analytics
   - Non-functional: High availability, low latency

2. Estimation:
   - 500M URLs/month → 200 RPS create, 20k RPS redirect
   - Storage: 250 GB/month

3. High-level Design:
   [Client] → [LB] → [App Server] → [DB]
                         ↓
                      [Cache]

4. Key Components:
   - Encoding: Base62 (62^7 combinations)
   - Storage: NoSQL với sharding
   - Cache: Redis cho popular URLs
   - Redirect: 301 permanent

5. Trade-offs:
   - Counter vs Hash encoding
   - SQL vs NoSQL storage
   - Cache consistency model

Q: Design a Rate Limiter

Gợi ý trả lời:

1. Requirements:
   - Limit 100 requests/minute per user
   - Distributed system

2. Algorithms:
   - Token Bucket: Flexible, allows bursts
   - Sliding Window: Accurate but complex
   - Fixed Window: Simple but boundary issues

3. Implementation với Redis:
```csharp
public class RateLimiter
{
    public async Task<bool> AllowRequestAsync(string userId, int limit)
    {
        var key = $"ratelimit:{userId}";
        var window = TimeSpan.FromMinutes(1);
        
        // Atomic increment với expiry
        var count = await _redis.StringIncrementAsync(key);
        if (count == 1)
        {
            await _redis.KeyExpireAsync(key, window);
        }
        
        return count <= limit;
    }
}

Distributed Considerations:
- Redis cluster cho scaling
- Sync rate limits across regions
- Handle Redis failures gracefully


### Q: Design a Background Job System

**Gợi ý trả lời**:

Requirements:
- Schedule and process jobs
- Retry failed jobs
- Priority queues
- Progress tracking
Architecture: [API] → [Job Queue] → [Workers] ↓ ↓ [Status DB] [Job Store]
Key Components:
- Queue: Azure Service Bus / RabbitMQ
- Scheduler: Hangfire / Quartz.NET
- Storage: SQL Server cho persistence
- Monitoring: Dashboard + alerts
Reliability:
- Idempotent jobs
- Exponential backoff retry
- Dead letter queue
- Circuit breaker pattern


---

## 3. Backend Deep Dive

### Message Queue Patterns

#### Q: Khi nào dùng Queue vs Topic?

**A**:

Queue (Point-to-Point):

Single consumer per message
Use case: Task distribution, load leveling
Example: Report generation jobs

Topic (Pub/Sub):

Multiple subscribers per message
Use case: Event broadcasting
Example: Member updated → multiple services react

Trong Pension System:

Queue: Report jobs (one worker processes each)
Topic: Domain events (Calculation, Payment, Audit all listen)


---

#### Q: Xử lý message failures như thế nào?

**A**:

Retry Policy:
- Immediate retry: 3 attempts với delay
- Exponential backoff: 1s, 10s, 60s
- Max retries: 3-5 tùy criticality
Dead Letter Queue:
- Move failed messages sau max retries
- Manual inspection và reprocessing
- Alert on DLQ size threshold
Idempotency:
- Unique message ID
- Check processed messages before handling
- Deduplication window (24 hours)
Monitoring:
- Track failure rate per queue
- Alert on sudden spikes
- Dashboard với queue depths


---

### Caching Strategies

#### Q: Cache invalidation strategies?

**A**:

Time-based (TTL):
- Simple, automatic
- Risk: Stale data within TTL
- Use: Frequently changing data
Event-based:
- Invalidate on data change
- More accurate
- Use: Critical data consistency
Write-through:
- Update cache and DB together
- Strong consistency
- Use: Read-heavy, write-rarely
Cache-aside (Lazy loading):
- Load on cache miss
- Simple implementation
- Use: General purpose

Trong projects:

Optimizely: TTL 30 minutes cho locations
Pension System: Event-based invalidation cho calculations


---

### Database Optimization

#### Q: Query optimization techniques?

**A**:

Indexing:
- Covering indexes (INCLUDE columns)
- Composite indexes (order matters!)
- Filtered indexes for subsets
Query Patterns:
- Avoid SELECT *
- Use EXISTS thay vì COUNT for existence checks
- Parameterized queries (plan caching)
Execution Plans:
- Look for table scans → add indexes
- Check join types (Nested Loop vs Hash Match)
- Statistics updates
Specific Examples:

-- Bad: N+1 query
SELECT * FROM Members;
-- Then for each member: SELECT * FROM SalaryHistory WHERE MemberId = ?

-- Good: Single query with JOIN
SELECT m.*, sh.*
FROM Members m
LEFT JOIN SalaryHistory sh ON m.Id = sh.MemberId
WHERE m.Status = 'Active';

-- Bad: Function on indexed column
WHERE YEAR(CreatedAt) = 2024

-- Good: SARGable
WHERE CreatedAt >= '2024-01-01' AND CreatedAt < '2025-01-01'

4. Behavioral Questions

Q: Tell me about a challenging technical problem you solved

Câu trả lời mẫu:

"The most challenging problem was optimizing the pension calculation system.

Challenge:
- Calculations took 5-10 seconds per member
- With 500,000 members, batch processing took days
- Users experienced slow UI when viewing benefits

My Approach:
1. First, I profiled the code to identify bottlenecks
   - Found 60% time in database queries
   - 30% in calculation logic
   - 10% in object mapping

2. Then I implemented a multi-phase solution:
   - Phase 1: Pre-calculation with event-driven updates
   - Phase 2: Multi-level caching (Redis + in-memory)
   - Phase 3: Batch processing optimization

3. Results:
   - Calculation time reduced by 90%
   - Database load reduced by 53%
   - User satisfaction improved from 3.2 to 4.6

Key Learnings:
- Always measure before optimizing
- Pre-computation is powerful for read-heavy workloads
- Communication with stakeholders about trade-offs is crucial"

Q: Describe a time you had a disagreement with your team

Câu trả lời mẫu:

"During the SKCC project, we had a debate about choosing ElasticSearch vs SQL Server for sensor data.

Situation:
- Team was split: half wanted SQL Server (familiar, ACID)
- Half (including me) advocated for ElasticSearch (time-series optimization)

My Approach:
1. I proposed a proof-of-concept to compare both
2. Created test datasets with 10M records
3. Ran benchmark queries for typical use cases

Results:
- ElasticSearch was 10x faster for time-range queries
- ElasticSearch had better aggregation performance
- SQL Server had better transaction support

Outcome:
- We chose ElasticSearch for sensor data, SQL Server for metadata
- The POC data convinced the skeptical team members
- Learned that data-driven discussions are more effective than opinions"

Q: How do you handle tight deadlines?

Câu trả lời mẫu:

"In the KF Project, we had a critical deadline for a client demo.

Situation:
- Demo was in 2 weeks
- Google Maps integration was only 50% complete
- Team was concerned about meeting deadline

My Approach:
1. Broke down remaining work into smallest tasks
2. Identified must-have vs nice-to-have features
3. Proposed MVP scope for demo, full features later
4. Worked with frontend dev in pair programming mode
5. Daily check-ins with stakeholder on progress

Actions:
- Focused on core flow: select location → save → display
- Deferred advanced features (clustering, bulk import)
- Used existing libraries instead of custom code
- Automated testing for critical paths

Result:
- Delivered MVP 2 days before demo
- Demo was successful, client approved
- Full features delivered 2 weeks later

Learning:
- Clear communication about scope trade-offs
- Focus on user value, not perfection"

5. Salary Negotiation

Research & Preparation

1. Market Research:
   - Check Glassdoor, Levels.fyi for role/level
   - Talk to recruiters about market rates
   - Consider location, company size, industry

2. Know Your Value:
   - List specific achievements with metrics
   - Quantify impact (revenue, cost savings, efficiency)
   - Unique skills you bring

3. Define Your Range:
   - Minimum acceptable (walk-away number)
   - Target (fair market value)
   - Stretch (optimistic scenario)

Negotiation Scripts

When asked about current salary:
"I'd prefer to focus on the value I can bring to this role. 
Based on my research and experience, I'm looking for a range of X-Y."

When given an offer below expectations:
"Thank you for the offer. I'm excited about the opportunity.
However, based on my experience with [specific achievements] 
and market research, I was expecting something closer to X.
Is there flexibility in the offer?"

When they ask about your expectations:
"Based on my research for similar roles in this market, 
and considering my experience with [relevant skills], 
I'm looking for a total compensation in the range of X-Y.
Of course, I'm open to discussing the full package."

Key Principles

1. Don't be the first to mention a number
2. Anchor high (but reasonable)
3. Negotiate total compensation, not just base salary
4. Get everything in writing
5. Be prepared to walk away
6. Maintain positive relationship throughout

6. Questions to Ask Interviewers

Technical Questions

“What does your typical deployment pipeline look like?”
“How do you handle technical debt?”
“What’s your approach to code reviews?”
“How do you monitor production systems?”

Team & Culture

“How is the team structured?”
“What does a typical sprint look like?”
“How do you handle knowledge sharing?”
“What opportunities are there for learning and growth?”

Project-Specific

“What are the biggest technical challenges the team is facing?”
“What does success look like in the first 90 days?”
“How do you prioritize technical work vs feature requests?”

7. Final Tips

Before Interview

Review your projects’ key metrics
Prepare 3-5 stories using STAR method
Practice coding problems (LeetCode, HackerRank)
Research company and role

During Interview

Think aloud when solving problems
Ask clarifying questions
Admit when you don’t know something
Show enthusiasm and curiosity

After Interview

Send thank-you email within 24 hours
Reflect on what went well / could improve
Follow up if you haven’t heard back

← PTG.PPPlus3 Project | Quay lại Work Experience

Keyboard shortcuts

Learning