---
# System prepended metadata

title: Pre-Practitioner Q&A
tags: [COTAI Teaching]

---

---
tags: COTAI Teaching
---

# Pre-Practitioner Q&A 

## Sesion 2

- Q1: Cho mình hỏi mảng tức là tên gọi chung list, tuple.. hôm trước có học phải không ạ? hôm qua không có bài tập cụ thể về xử lý datetime nên mình hơi k rõ cách làm bài tập chuyển mảng thành datetime lắm, mong mọi người hỗ trợ chia sẻ - Trương Hoàng Phúc.
- A1 by Tuyền: 
    - Python không có kiểu mảng (array), anh sẽ không tìm được khái niệm array trong tài liệu chính thống của Python đâu ạ. Python chỉ có kiểu danh sách (list), nó có chức năng tương đương kiểu mảng trong các ngôn ngữ lập trình khác.  Người dùng quen gọi danh sách của Python là mảng là do ảnh hưởng lớn từ cách hiểu của ngôn ngữ C mà ra.
    - Mảng (hay danh sách) là nó, không phải là tên gọi chung cho 3 kiểu dữ liệu theo tập còn lại của Python đâu ạ. List, tuple, set, dictionary là 4 kiểu dữ liệu khác hoàn toàn, có những tính chất và cách dùng khác hoàn toàn luôn. Anh xem lại phần phân biệt 4 kiểu này ở bài giảng session 1 ạ.
    - Bài tập chuyển mảng thành datetime:
        - Anh xem xem đề cho bao nhiêu phần tử của mảng.
        - Tìm cú pháp thích hợp chuyển sang định dạng của datetime. Thêm nữa là anh cần lưu ý phần chuyển sang cho đúng chỗ nào là ngày/tháng/giờ... do datetime theo định dạng ngày giờ chuẩn phương Tây nên có thể sẽ đọc ngược theo cách đọc của mình.
    - Trong bài giảng vừa rồi có 1 ví dụ tương tự bài trên hackerrank về cách chuyển mảng 6 phần tử thành datetime, anh xem lại và tự code lại để hiểu ạ. Ví dụ ở bài giảng là nhập sẵn thông số vào.
 `d1 = datetime.datetime(2015, 1, 1, 0, 0)`
 `d2 = datetime.datetime(2014, 1, 1, 0, 0)`
 `print(d1)`
 `print(d2)`
Còn hackerrank thì anh phải dùng index để chuyển thủ công từng phần tử từ trái sang phải vào.

## Hướng dẫn trao đổi trên slack (TA - học viên)

Tuyền: 
Góp ý xây dựng về Quy tắc trao đổi trên slack giữa học viên và đội ngũ giảng viên, TA:

1. Giảng viên và trợ giảng cập nhật username trên slack thêm đuôi -Instructor hoặc -TA vào cho học viên dễ nhận biết. Sau đó nên có một dòng thông báo trên slack tag tất cả Instructor và các TA vào để học viên biết là ta có một đội ngũ hùng hậu hỗ trợ. 
2. Nêu rõ rằng ta chỉ có một kênh trao đổi chung là slack, không dùng các kênh khác. Học viên làm bài tập Hackerrank có câu hỏi thì đưa lên slack, không đăng vào forum của Hackerrank.
3. Các học viên có câu hỏi thì bỏ vào kênh chung slack, không nhắn riêng cho giảng viên hoặc TA (trừ các thỏa thuận khác hoặc muốn trình bày các vấn đề riêng khác). Trong trường hợp đang rất gấp, muốn có liền câu trả lời thì tag tên của giảng viên hoặc TAs vào. Về phần giảng viên và TA thì sẽ sắp xếp hỗ trợ, trả lời ngay khi có thể.
4. Với mỗi câu hỏi, khi trả lời hoặc trao đổi sẽ mở thread lên tại câu hỏi đó để trả lời. Việc làm này hữu ích cho việc tổng hợp thông tin và tiện theo dõi.
5. Các bài tập cần học viên đưa code của mình lên cho giảng viên hoặc TA kiểm tra, tùy thuộc vào việc giảng viên hoặc TA nào nhận trả lời câu này thì học viên đó sẽ gửi riêng phần code cho người đó. Các trao đổi còn lại vẫn sẽ thực hiện ở kênh chung.
6. Code khi đưa lên slack bỏ trong 3 dấu ``` (An).

## Phản hồi từ lớp Pre02 và giải pháp

Tuyền soạn, call vs Thanh revise

> Học viên bảo bt quá khác so với lý thuyết, không áp dụng được.

Nhận xét này cảm tính và cá nhân quá. Nếu tầm tối thiểu 50% học viên trong lớp phản ánh như vậy thì ta nên xem xét

> Về lịch học 3 buôi/tuần

Học viên của ta đa phần là người đi làm và người ngoài ngành. Thời gian học tập và tốc độ tiếp thu có thể k nhanh, vậy nên có thể cân nhắc điều chỉnh thành 2 buổi/tuần nếu học viên có nguyện vọng này. Giảng viên đứng lớp sẽ chủ động lấy thông tin này và báo cáo lại cho bộ phận Operation của COTAI để bên COTAI làm việc vs bên VTCA về chuyện lịch học

> Xóa dòng `if __name__='__main__':` rồi nhấn submit vẫn báo `success`

Dĩ nhiên. Vì xoá đi và viết code k xài `if __name__='__main__':` thì code đó vẫn đúng syntax và thông dịch được bình thường. Đây là kiến thức lập trình python căn bản. Cái này mà giảng viên và trợ giảng k nắm là tán cho sấp mặt, yêu cầu về học lại, hoặc hỏi bạn bè cho ra ngô ra khoai. Học viên thắc mắc khúc này là một cơ hội tốt để giảng viên/trợ giảng lao vào giải thích (hoặc nhắc lại cho họ nhớ)

Lưu ý rằng: học viên khi nghe giảng họ sẽ k để ý, đó là chuyện bình thường, cùng lắm họ chỉ nhớ mại mại là từng gặp mà thôi. Vì lý do đó nên ta đã cố tình cài cắm dòng code đó vào bài giải để họ hỏi ta, để họ làm quen dần

> Hv phản ánh đối tượng tuyển sinh chưa phù hợp (khi tuyển sinh thì bảo tụi em sẽ dạy anh từ zero, nhưng khi vào học thấy không phải từ zero mà phải biết chút chút gì đó thì mới theo kịp).

Kinh nghiệm đi dạy và đi học nhiều lớp e thấy người dạy code hay có kiểu giảng bài chỉ thuần trên kinh nghiệm code. Tức là:
- Bản thân quen code thế thì mình giảng y chang thế ấy..
- Vì sao như vậy thì k biết, vì sao python nó thiết kế như thế cũng k biết, vì sao người ta dùng thế lọ thế chai cũng k biết, cái này cái kia có tác dụng gì cũng k nắm (chỉ biết code sao cho chạy chứ chả hiểu mấy)

Làm như vậy là k hiểu về code, mà cũng chẳng để tâm lên học viên. Vì học viên họ k có kinh nghiệm code như mình, nên lấy kinh nghiệm mình ra để áp lên họ, kiểu như đó giờ tui quen vầy quen vầy nên bà con cứ làm vầy làm vầy đi là họ k hiểu

Học viên đa phần k nắm rõ, họ k học đc thì quay ra tự trách bản thân. Nhưng gặp học viên xịn, họ nhìn họ biết ngay là người đứng giảng k có kỹ năng truyền đạt gì và dạy k để ý học viên. Lớp Pre này chính xác là để dạy cho người k biết gì về code cả. Việc để cho học viên có cảm giác phải biết chút chút mới theo kịp phần nhiều đến từ cách giảng của giảng viên. Trong quá trình đào tạo trainee, ta đã nhấn mạnh điểm này rất nhiều. Và giờ thì ta đang gặp thực. Giải pháp khả dĩ hiện tại gồm:

- Các bạn cần thực hành hướng dẫn cho ae trong công ty, kiếm người kém nhất mà dạy. Kiên nhẫn dạy được thì k sợ học viên nữa
- Bổ sung bài tập minh hoạ ngay trên lớp cho từng đầu mục kiến thức nhỏ nhất


> Bài giảng 10 nội dung thì bài tập chỉ ra 5-7 nội dung trong đó, còn lại vẫn phải search google. Học viên đề nghị chỉ cho bài tập sao mà họ nhìn vào bài giảng làm mà họ làm được thôi.

Nhắc lại đây là lớp Pre-Practitoner. Từ cái tên gọi thôi đã thể hiện mục đích của lớp này. Đây là lớp chuẩn bị các kiến thức code python sẽ dùng cho khoá Practitioner. Vậy nên:
- Lớp Pre k có tham vọng dạy hết về ngôn ngữ python. Chỉ tập trung vào các kỹ thuật sẽ dùng nhiều trong khoá Practitoner sau đó
- Lớp Pre sẽ giới thiệu tất cả kỹ thuật sẽ cần trong lớp Practitioner. Học viên có thể k rành, nhưng cần được biết trước để sau này vào lớp Practitioner khỏi bỡ ngỡ. Bài tập đã ra cho lớp Pre đã thiết kế để học viên đảm bảo quen tay vs python, vậy nên bài giảng khó 10 (là để giới thiệu kiến thức) nhưng bài tập chỉ khó 5-7 mà thôi. Và con số mà học viên cảm nhận cũng chính xác bằng con số mà đội ngũ biên soạn bài giảng, bài tập cho lớp Pre đã ước lượng: 7/10

> Bài tập không có solution, cái học viên cần đang là hiểu bài, áp dụng kiến thức từ lý thuyết vào bài tập, cái họ học được nhiều nhất là từ những bài sai, thì mình cần cho họ biết họ sai thế nào và sửa sao cho đúng

Đồng ý:
- Nên bổ sung solution mẫu và công bố cho học viên sau bữa học kế tiếp.
- Viết comment code từng dòng vào các ví dụ ở file solution.
- Viết comment code từng dòng vào các ví dụ ở file bài giảng.
- Gửi lại mid-term solution cho học viên.

E (Ngọc Tuyền) sẽ lead phần này: viết hướng dẫn thực thi, giao task và review.

> Hv phản ánh là kiểu như mình đang dạy cho biết, chứ không phải dạy để hiểu

1. Cần xem lại cách truyền đạt của giảng viên/trợ giảng trên lớp
2. Nếu cái học viên đòi hỏi là code quen tay thì họ cần làm đi làm lại bài tập nhiều lần và kiên nhẫn chờ đến tuần thứ 3 để cảm nhận kết quả. 

> Lấy thang 10 để đo trình độ học viên: 0 là zero, 10 là những hv đã biết lập trình, đã code qua những ngôn ngữ khác. Thì chương trình mình đang dạy rơi đâu vào đoạn giữa từ 4-7 gì đó. Không thể đáp ứng được kỳ vọng của 2 nhóm học viên trong khoảng 0-3 và 7-10.

- Mục đích của việc có trợ giảng trong lớp là để hỗ trợ nhóm 0-3. Nếu giảng viên đứng ở trên mà diễn đạt được tốt thì có thể làm chương trình đáp ứng được đoạn 2-8. Giảng viên giảng k đạt, chỉ thuần kinh nghiệm thì coi chừng chỉ hợp cho khoảng 6-7
- Học viên trong khoảng 9-10 k phải là đối tượng của lớp Pre này, chắc chắn nên bị loại ra từ đầu và đưa thẳng vào chương trình Practitioner!

> Việc dạy phân cấp trong python thực sự quan trọng, đến buổi thứ 4 mà vẫn có học viên viết thế này là có vấn đề rất nặng trong tư duy code:
> ```
> if __name__ == '__main__':
> print()
> ```

Trong số các ngôn ngữ phổ biến thì chắc chỉ có python chơi trò này. Đó là cái hay cũng là cái dở của python. Có cách để làm học viên thấy dễ hiểu. Chỉ sợ người giảng cũng k biết nguồn gốc của cách viết này trong python nên chẳng biết giải thích sao cho học viên


> Mình đang đi dạy quá nhiều thứ phức tạp không cần thiết, như là viết hàm `lambda`, viết code trên một dòng `[i for i in ds if i%2==0 else break]`. Có thể hiểu là mình đang chỉ ra quá nhiều đường đi cho học viên mà không nhấn mạnh đâu là đường nhanh nhất, an toàn nhất

1. Mấy thứ này phức tạp thì đúng. Nhưng nó cần thiết! Vì ngoài việc tự viết code, ta cũng cần đọc code mà nhiều người khác viết trong quá trình ta học và làm. Họ viết như vậy đó, giờ đọc hiểu k được thì học tiếp thế nào?
2. K có cách viết nào nhanh nhất và an toàn nhất cho mọi tình huống, vậy nên người ta mới tạo ra nhiều kiểu viết như vậy để thích ứng vs các đoạn code trong thực tế. Giảng viên/trợ giảng cần kiếm các ví dụ thuyết phục và bổ sung vào bải giảng để học viên hiểu

> Những kiến thức như tại sao lại có `if __name__='__main__'` hoặc là `__init__(self)` không nên giải thích, vì:
> - [Mạnh Hưng-TA] Giải thích mà không biết đúng hay sai thì học viên sẽ bắt bẻ.
> - Nếu hv mà cần giải thích những thứ như trên thì họ không thể học lớp này, họ đã ở tầm cao thủ rồi.

Giờ này mà Giảng viên/trợ giảng còn k biết mình đang giải thích cái trên đúng hay sai là lôi ra tán sấp mặt ngay và luôn. Đề nghị về nhà học lại. Người chịu trách nhiệm khoá học Pre có thể sắp xếp để ôn tập, chuẩn hoá kiến thức một lượt cho các giảng viên/trợ giảng.

Mấy thứ trên là cơ bản của ngôn ngữ python và vào lớp Practitioner k thôi là đã đụng rồi. K có gì cao thủ ở đây hết. Nó ít xài k có nghĩa rằng nó khó, mà chỉ vì người ta chưa đụng tới trường hợp để xài mà thôi. Mà thường là do code lụi, code tay ngang, code cốt cho chạy mà k để ý đến hiệu suất, trình bày, cấu trúc... này kia nên mới bị. Học viên có thể k cần rành tới mức tự code chuẩn, nhưng ít nhất phải đọc hiểu được.

Về Mạnh Hưng, (again) nếu không tự ý thức được mình cần nói những gì với học viên thì khi nghe phản hồi nên chỉ im lặng nghe, rồi đưa câu hỏi đó cho giảng viên đứng lớp, hoặc tốt nhất là hỏi trên kênh slack nội bộ. Câu trên là Hưng lên tiếng thảo luận, gật gù với anh Chinh. Tuyền đã phản hồi, nhưng nếu còn lặp lại một lần nữa (only one) thì sẽ bàn cách để xử phạt (đã cảnh cáo đến bạn như vậy).


> Khi hỏi anh thấy bài giảng hồi nãy giờ như thế nào thì anh chỉ ra hiệu "kill me" và theo sau là câu "Em thử hỏi những anh yếu khác đi, cũng như anh thôi".

Giảng viên giảng thì phải để ý học viên, cứ một đoạn, cần đảm bảo là họ nắm rồi mới đi tiếp. Chứ kiểu bài giảng cứ chạy, học viên hiểu hay k kệ mẹ họ thì cẩn thận đến cuối buổi sẽ bị thế này. 

Cho nên cần giảng thật kỹ qua từng điểm kiến thức, dừng lại, cho ví dụ, giảng viên phải quan sát nét mặt, năng lượng lớp học mà cảm nhận được rằng học viên đã chắc chưa, đã nắm được chưa. Thì mới đi tiếp được. Giảng viên cũng cần đồng điệu năng lượng và tốc độ hiểu với học viên. Thấy lớp có vẻ nghệch ra thì cần giảm tốc độ nói, chỉnh sửa lại câu chữ, có thể dành khoảng 30 giây đến 1 phút để tự detect vấn đề rồi hẵng tiếp tục.

Việc đặt câu hỏi, tạo một cuộc tranh luận nhỏ cũng là cách để kéo học viên vào. Khi lớp thảo luận, giảng viên có thể làm vai trò điều tiết, chốt cuối, hoặc giả bộ ngờ nghệch một tý để học viên có cơ hội "thể hiện". Điều này có thể làm tăng năng lượng tập trung của lớp.

Ngoài ra, các buổi tiền đề mà dạy k tốt, rất dễ dồn ý về sau, và giảng viên của các buổi sau hốt shit k có nổi thì cũng sẽ gặp tình trạng này

Giải pháp tạm: bổ sung thêm buổi ôn tập cho học viên



## Meeting với học viên Pre02


1. Thiếu bt thực hành tại lớp:

Chinh: 
nd ko dàn trải, quan trọng, nhưng do mình ko giảng cho bạn biết là nó chưa quan trọng, giảng giải thêm

cho thêm ví dụ, hướng dẫn kỹ thuật ngữ, đưa thuật ngữ thì nên giải thích, sắp xếp thế nào đó để cho hv hiểu mạch lạc hơn.

Sĩ:
bt về nhà làm khó hơn trên lớp, tạo áp lực cho mng làm btvn

Vinh:
vd hàm def thì to-do trên lớp ứng dụng đc, nhưng btvn thì lồng thêm nhiều phần trước đó, khó hơn (chắc bị hỏng kiến thức từ nhiều phần trước rồi)

a Hưng:
trên lớp có ví dụ và to-do

a Minh:
ủng hộ việc có thêm to-do
btvn có thêm nhiều thuật ngữ sâu hơn để tìm kiếm, hv gặp khó khăn

a Huy:
btvn thiếu tính thực tiễn, 

a Hưng:
sẽ cho thêm code mẫu và to-do trên lớp, kèm bài giải về nhà


===> đồng ý thêm to-do trên lớp kèm bài giải lấy từ btvn.

Chinh:

thiết kế bài tập mở rộng code lên. nên đưa bt cơ bản về lý thuyết mục này trước. sau đó tăng dần lên kết hợp những lý thuyết phần trước

Giang:
muốn có thêm hình minh họa, ví dụ cho câu lệnh if else

2. Dàn trải, nhiều thuật ngữ, ko liên quan đến AI

a Hưng:
có những cái cơ bản đưa AI vào thì gượng ép, các bạn đặt mình vào context để hiểu


Chinh:
có kiến thức quan trọng nhưng nói là bài thi ko cho ra, làm hv mất focus

a Hưng:
nói "nó ko trực tiếp liên quan đến AI nhưng nó giúp định hình mindset về computational thinking, về tư duy tính toán"

a Lộc:
cho ít nd lại, nhiều quá ko tập trung đc, nên cho vừa đủ nd và focus vào.

a Huy:

cá nhân: làm sau dịch tới 18h, muốn giảm số buổi, tăng ví dụ trong bài giảng lên

3. cas ko hiện output của bài code như trên hackerrank (a Huy): ghi nhận lại


4. a Minh: dạy ko đúng đối tượng, hv yếu thì TA lại nói cái này đã giảng rồi mà a ko nhớ à


5. a Huy: nên nói về big picture, computational thinking (a hưng nhắc) là gì


a Sĩ:
đi làm có thể có buổi vắng 1-2 buổ thì sao? 
a Hưng: báo lại để xem clip khóa học, cần xem qua outline để biết trước, 


## Meeting với Vân vtca 01/10 (sau SS7)
- cách dạy còn mơ hồ: phản hồi của Linh và Long (về kiến thức học ở đây so với kiến thức đã đc học trước đó)
- các bạn chuẩn bị gởi email và ngày mai có lẽ cũng có meeting nữa
    - ta chốt giải pháp support trước 30', rồi nếu hv gởi mail thì Vân trả lời 
- nhóm anh sĩ, anh lộc, anh minh, huy, tân, a cương: điểm khá thấp - anh lộc gọi cho Vân (đại diện nhóm này feedback)
    - đề nghị được support 30' trước giờ học (ok với Vân)
        - học viên cần list ra cụ thể gởi trước 12h, và có làm bài tập
        - Vân làm form và đăng trên slack (lưu ý học viên cần commit)
- liên quan đến quiz (để đánh giá hv học đc lâu)
    - cần xem lại tasklist và phản hồi với Vân
- plan cho feedback về support:
    - Vân đề xuất sau 3 buổi thì sẽ cho các bạn học viên đc support làm khảo sát
- Vân cũng muốn đc xem kết wả HW của hv để kịp đôn thúc
    - Trinh ok, sẽ share cho bạn
- có đề cập với Vân về buổi support trước final exam, nhưng để ngỏ là chưa chốt
- có đề cập với bạn về Quy chế đào tạo mà các sếp VTC chưa cho ban hành