Ph.D. Guideline

Last updated: May 31, 2025 (Revised documents and advice)

What is a Ph.D. Program

Before discussing how to be successful in a Ph.D. program, we need to understand what it is. What is the objective of it? There may be various interpretations, but I think the objective of a Ph.D. program is to prepare you to be a real scholar and an engineer. Then, what is a scholar or an engineer? What is the difference between them? Before we start talking about this, I want you to be familiar with this situation: a question involves other questions repeatedly. This endless chain of questions would be the most painful and intriguing part of your Ph.D. life (or your whole life as an engineer).

Researchers contribute to the community by investigating new questions, providing valualbe insights, developing innovative approaches, and offering solutions (or directions to solutions) for the problems. Their impact depends on the significance of the problems, the novelty of the observations, and the effectiveness of the solutions. However, the most important thing is to communicate the research to the community. If the research is not communicated well, the impact would be limited by that. Thus, the research paper should be written well, and the findings should be presented clearly and concisely. In this sense, the research is not only about the technical aspects but also communication and marketing.

On the other hand, engineering aims to provide a cost-efficient solution to the problems and make a stable improvement in the system. While novelty can be valuable, the primary focus lies in identifying the correct problems and delivering the most efficient solutions, which should be reliable. In other words, engineering emphasizes practicality and resource management. Although engineers do not need to write papers, communication skills are still crucial. If you are the only one who understands what you have done, you will end up working alone, and it must be extremely inefficient. Therefore, effective communication and documentation skills are essential in engineering as well.

A Ph.D. program is about both research and engineering. You should be able to find meaningful problems, provide innovative observations, offer effective solutions, make meaningful progress daily, and communicate the results clearly to the community. Frankly, you could not be able to be a great-great scholar or engineer within a Ph.D. program since many components come from luck and the environment. However, you can prepare yourself to be a promising scholar or engineer by developing the skills and knowledge that are helpful for your future career. As you expect, communication skills are the most important among them.

This article will talk about various things, mainly how to communicate well. Why should we be good at English? Because we need to explain our ideas in English. Why do we need to know the basic structure of papers? Because it is the essence of know-how to deliver your idea well. Should we learn how to speak in a collaborative language? Yes, for sure.

English

If you are a native English speaker or if you are proficient in, congratulations! That is a great privilege. However, if you are not, listen to me. As you know, English is important because most papers and documents are written in English. However, we often forget that the goal of studying English is not to be a native speaker. Nobody expects you to be a native speaker. The goal is to communicate effectively. You should be able to read a paper quickly (or deeply), write a paper clearly, speak your opinion precisely, present your idea convincingly, and listen to others talk critically. The following is the list of what I did to improve my English skills.

Reading

In my opinion, if you are a well-trained Ph.D. student, you should be able to read 300~350 words per minute (WPM, average adults in America have 220 to 350 WPM). Test it. If you are not, you should improve your reading speed and understanding skills. This fundamental should be considered first before you begin your research. The best way to improve a reading skill is to read a lot. I will frequently mention the concept of the quantity-quality transition (QQT); a quantitative increase in substance can result in a qualitative state transformation. Read a lot of papers, books, and articles.

Nietzsche’s concept of the “Three Metamorphoses of the Spirit”—how the spirit becomes a camel, then a lion, and finally a child—offers a clear framework for reading a paper. First, approaching the material with the acceptance and supportive understanding of the camel. Read the paper like your role model writes it. Second, critically examining and challenging it with the spirit of the lion. Imagine that you are reading a paper written by someone you hate. Finally, like the child, creatively generate new insights by considering counter-arguments, further research, or related works. Keep in mind that you must write a novel paper to graduate. Thus, I would recommend reading a paper at least three times if you find well-written papers to delve into. Note that the order is important; You cannot be a lion without being a camel or a child without being a lion.

In addition, to enhance your analysis, consider using the three-spirits on the highlighting system. Assign yellow to the paper’s most significant statements (the “camel” - carrying the core ideas), red to its weaknesses or limitations (the “lion” - areas to challenge or critically assess), and blue to potential future actions or applications based on the research (the “child” - new beginnings or developments). This framework can transform a simple reading process into a more critical and productive exercise, prompting deeper engagement with your brain.

Writing

If you are a well-trained Ph.D. student, you should be able to write one or two pages within a day, provided that you have the contents in your mind. Keep in mind that the most important thing is to write a paper clearly and easily. Moreover, there is a well-organized structure of a paper, section, paragraph, and sentence for academic writing (visit this article for overall academic writing). Stand on the shoulders of giants. Learn and use them. I will discuss effective writing later in Paper Structure.

Listening & Speaking

Note that there are many useful lectures and talks on YouTube, more than you expected, such as these (1, 2, 3, and 4). Watch the lectures and talks as your pastime and connect the content to your research. Understanding and using knowledge are the most important things in improving listening skills (this concept can also be applied to reading).

If you want to improve your speaking skills, you should speak a lot, SIMPLE. ChatGPT is a good tool for practicing speaking. You can talk to the AI, and the AI will respond to you. Explain your research to the AI. This will also help you develop the research idea in depth. I will discuss this in Useful Services.

Programming

Road-map

I studied computer architecture (engineering), not computer science. Thus, I thought that programming skills were not important to me. Yes, it is not the most important thing to be a good computer architect. However, you will spend an enormous amount of time implementing and evaluating your ideas if you are not good at programming, which is not the most important thing in your research. Thus, you should at least be a decent programmer. The following is the road map to study programming.

• Basic syntax and standard libraries: YouTube lecture and examples
• Programming practice: LeetCode (visit this video) and Codewars
• Toy projects: Project-based learning repo
• Design patterns: Refactoring Guru Also, it is important to understand the benchmarks and workloads used in your research. Once a reviewer recognizes that you don’t understand the benchmarks, you could lose your chance of being accepted.

A Good Programmer is A Good Researcher

Here is a great article about the programming skill. Note that these principles are also applicable to research. For example, “Don’t allow surprises,” you should write your paper in an expectable way.

Pseudo-Code

As a computer architect, writing perfectly optimized code is not that important. However, writing reasonable code that is easy to understand is important. Thus, you should be good at writing a pseudo-code [1][2][3][4], a technique used to describe the distinct steps of an algorithm in a way that’s easy for anyone with basic programming knowledge to understand. In addition, the ability to write a pseudo-code is becoming increasingly important due to the advance of AI/ML coding assistants. If you have your own pseudo-code, GitHub Copilot will write the code for you.

Pseudo-Code - Basic constructs

• SEQUENCE: represents linear tasks sequentially performed one after the other.
  • Goal, Input, Output, READ, GET, SET, PRINT
• WHILE: a loop with a condition at its beginning.
• DO-WHILE: a loop with a condition at the bottom.
• FOR: another way of looping.
• IF-THEN-ELSE: a conditional statement changing the flow of the algorithm.
• CASE: the generalization form of IF-THEN-ELSE.

Pseudo-Code - Examples

// Goal: Traverse the graph in BFS manner
// Input: graph, starting node of the graph (startNode)
// Output: set of visited nodes (visited)
BFS(graph, startNode)
1   SET queue.push(startNode)
2   SET visited = set()
3   WHILE queue is not empty
4       SET currentNode = queue.pop()
5       visited.add(currentNode)
6       FOR each neighbor of currentNode in graph
7           IF neighbor not in visited and neighbor not in queue
8               queue.append(neighbor)
9   RETURN visited

// Goal: Sort a list of numbers
// Input: number list (list)
// Output: sorted list (list)
sortList(list)
1   IF list's length is 0 or 1
2       RETURN list
3   SET pivot = list[0]
4   SET sublist1 = []
5   SET sublist2 = []
6   FOR item in list[1:]
7       IF item less than or equal to pivot
8           sublist1.append(item)
9       ELSE
10          sublist2.append(item)
11  SET sortedSublist1 = sortList(sublist1)
12  SET sortedSublist2 = sortLIst(sublist2)
13  RETURN sortedSublist1 + [pivot] + sortedSublist2

Commenting

Commenting is essential to writing readable code. Here are some tips on writing comments.

1. Focus on explaining the “why” rather than the “what.” Good code should be self-explanatory in terms of what it does, so comments should provide context on why certain decisions were made or approaches taken.
2. Comment on functions to explain their purpose, if-else statement to describe the cases, and code block to elaborate on the task. This provides a helpful context where it’s most needed.
3. Use clear and concise language. Avoid jargon, slang, or overly complex vocabulary. Write comments that are easy for others to understand. Include reference links when relevant, especially for code sourced from elsewhere or external resources that provide helpful context.
4. Write comments at the same time as you write the code. This helps capture your thought process accurately. However, don’t use comments to explain complex flows across multiple files - use more appropriate documentation tools for that.
5. Use XXX, HACK, FIXME, BUG, and TODO tags sparingly and prefer creating actual issues/tickets for future work.

• XXX: Warning about possible pitfalls
• HACK: Not very well-written or malformed code to circumvent a problem/bug
• FIXME: This works, sort of, but it could be done better
• BUG: There is a problem here.
• TODO: No problem, but additional code needs to be written, usually when you are skipping something.

Time Management

When you become a Ph.D. student, you should do a lot of tasks: research, writing, coding, presentations, meetings, seminars, personal study, teaching assistant, classes, social life, and family. Thus, you should be able to manage your time effectively. The key is prioritizing the tasks and assigning your time to each project (this book can be helpful). A proper time management system could be different for individuals, but the following is the list of common rules to make it.

• The list should consist of action items, starting with an active verb. For example, instead of “Project proposal draft,” write “Draw the outline of the project proposal.”
• Make each action item time-bound, and evaluate the completion time for each one. This will improve your time management skills.
• Write down goal-oriented tasks. For example, it does not matter whether you add a new figure; the aim is to explain a concept that is hard to understand.
• Categorize them by type, place, or project. For example, I use chores, self-development, and research.
• Split a big task into smaller action items, which can be done within a day.
• Organize the task in priority. I chose the top three priorities that I need to focus on right now. I am using a variation of the Pomodoro technique, planning a day in the morning based on a 45-minute session (with Notion). In this system, I allocate time to each project based on priority. Also, I count the number of sessions I have completed in a day and for each project. Such statistics help me understand how many sessions I need to complete a certain task. This discipline can develop my metacognition, allowing more effective collaboration and planning. In my case, I need to spend four sessions to write a double-column page, eight sessions for paper review, 500 sessions to publish a four-page paper, and 1400 sessions to publish an 11-page full paper.

Research Process

There are many different ways to do research. For example, the Why-What-How approach is a good way to organize your research, making it convincing and easy to understand, and the basic scientific method (strong inference) is a good way to make your research concise, concrete, and clear. Fortunately, I have worked with a few great scholars who use these methods practically. What I have found is that these methods are not for everyone, and we should find our own way. They are too abstract/ideal sometimes or require a certain level of intuition, which cannot be developed by discipline. Thus, I have designed my own way, and here, I introduce mine to help you to make yours. 

Here is my thought process: Objective, As-Is (Why), To-Be (How), and What. Note that you do not need to follow this process. If you have any insight, start from that and go up/down to the other parts. All the intellectual processes are done in parallel, mixing top-down and bottom-up walkthroughs. However, at some point, you need to organize the flow of your proposal based on the order, starting from the objective. Usually, I start with an ideal case and investigate the related works for the objective and background. Then, I design the baseline model and clarify the limitation of the current system, which is As-Is. Finally, I search for solutions to resolve the limitations effectively.

Objective

An objective is the ultimate goal of the research, typically expressed in a single, concise sentence. It would be great if it indicated the key metric representing the performance, such as “Improving the end-to-end execution time of applications on GPUs by removing redundant computations.” How can we find this objective and check its significance? Remember QQT, that is the answer. If you want a shortcut, you can ask your advisor or other seniors. They will help you find a meaningful objective if you add their name to the paper Collaboration.

Background

Once you have identified an objective, begin searching the background. Note that there are three things you should set: baseline, alternative, and orthogonal techniques. The main purpose of this process is to establish a baseline model. By searching the related and prior works that address your objective or similar ones, you can draw a graph of papers. What is the common model that can group the papers in that graph? What is the state-of-the-art design? Which model do we need to use to delve into the problem? If there are any recent techniques, what are they addressing? This baseline model should be acceptable for most readers, making a consensus on the necessity of further development (This should be demonstrated in As-Is).

After setting up the baseline model, you can start looking into problems and insights. While doing this, you should clarify the two groups of backgrounds: alternative and orthogonal techniques. Alternative techniques can address the same objectives as ours, but they cannot be applied concurrently (or are inefficient). For example, we can utilize domain-specific accelerators instead of general-purpose devices, such as GPUs, to accelerate a specific application. We should compare the strengths and weaknesses or trade-offs between our and alternative techniques to convince the readers. This comparison is what you can see in the paper’s evaluation section.

Orthogonal techniques address the same or slightly different objectives, but we can apply them to a system with our proposal. For example, we can improve the hardware architecture of any system, and since the software stacks are often transparent to hardware, software-level optimization is orthogonal to the hardware one. As mentioned, this categorization and meta-analysis should provide a graph or a taxonomy table consisting of techniques and their differences, as well as the history of the objective. Note that this history will help you convince readers that you are expanding the community’s knowledge.

Note that this search process should continue until your paper is published. The other question is, “how many techniques do we need?” I think 23 alternatives and 510 orthogonal techniques are enough to start developing an idea.

As-Is (WHY)

Now, we should develop the As-Is part. I think this part will decide the novelty of your research. The purpose of this part is to make a taxonomy table like this (Note that this analysis is necessary even if we are not going to include the table in the paper):

First, we need to find and organize the observations (Ob. in the Table), which are succinct statements defining the problems, opportunities, or requirements. Each observation induces the corresponding functionalities (Func. in the table) that we need to support. For example, (Ob. 1) if input data loaded from global memory shows temporal locality, we need (Func. 1) an additional memory hierarchy between computing units and the global memory to store the data for a while. You should estimate the alternative techniques based on these observations.

Specifically, to organize the observations, we should clarify the statement and jog them down. Again, what is the problem, opportunity that the prior works missed, or requirements that we must consider? Then, we should build a quantitative hypothesis or collect supportive evidence from prior works for the statement. If we need an experiment, we need to think about the methodology. Simulation? Emulation? Or real implementation? Finally, what conclusion does the statement drive? The conclusion can be a function or insight that drives the solution to the other problem. What if the hypothesis is right? What should we do, or what should we look into next? These may produce the functionalities that will be the goals of the To-Be part. By repeating these, you will get a logical thought process from objective to several functionalities.

Okay, this still seems a bit abstract. You may be asking, “So, how can I come up with these?” My answer is QQT. If you read a lot, you will find some important questions and patterns that you can use. Holding these questions, read more and more. If you want a more practical methodology, here are mine:

• Use the five whys method. Start from baseline and alternatives. Why are they doing that? Why do they overlook this problem? Why did this problem happen? This can help you gain a deeper understanding of the current situation.
• Keep wondering about the ideal situation. This would help you set the upper bound for your performance improvement, which could hugely enrich the quality of the paper. Note that abstraction is the best tool for convincing someone.
• Use a hypothesis tree. First, make hypotheses as many as possible. Never deny any idea at this time. After stacking them enough, prune them. Finally, you will get a single thread that you should use. Why should we do this? Why should we follow such a complicated process to propose our idea? Can’t we show them that our implementation is good enough to be employed? This is because we want to deliver our idea to the community. We are proposing a way to solve the problem, not showing off our intelligence. Thus, we should clarify the position of our research among the proposed ones and tell them, “If you face this problem, you can solve it like this.” Additionally, note that in As-Is, avoid talking about the proposals. This part is all about why we need to do something, not how. How-part will be covered in To-Be.

To-Be (HOW)

Based on the functionality, we should design the proposal. How can we implement the defined functionality efficiently? What are the_ challenges and design spaces_ of that? The challenge is straightforward. What are the overheads? Are they acceptable? If not, how can we implement that efficiently? The design space is a set of variables we can adjust according to the system specifications. It would be great if you could test and analyze diverse design spaces. One more thing is the upper bound (ideal case), as mentioned. How much did we achieve compared to the upper bound (ideal case)? Organize such aspects based on the functionalities, using a divide-and-conquer approach.

Paper Structure

Before discussing the structure of a paper, we need to understand the convincing process. The best way to convince other people could be three steps: (1) provide an outline, (2) take questions from them, and (3) answer the questions with evidence. In short, make them curious and satisfy their curiosity with inductive presentation. Note that you could not make any person understand your paper 100%. Reviewers would understand your paper only 30~40%. Thus, listing the information that you have is the worst way to convince them because they would be just confused by such massive information. When people in the academic community read a paper, they have a common question and expected contents for each section. Since unexpectancy is the main enemy of understanding, the paper should follow a common structure. For example, in the introduction, you could put a question like “Is this problem important?” and then answer it in the motivation section with corresponding references or data. Below are common questions and the expected contents for each section.

Abstract

• What have you done (but I have only a minute to read this paper)?
• Okay, does this paper include the contents I am searching for? The purpose of abstraction is to provide a very brief summary of the paper. When you are searching for a certain topic to study or write a related work section, you may search for some keywords and read the abstract if it includes them. Hence, make sure that your abstract includes the keywords people are searching for and the problem the paper addresses.

Introduction

• Do I need to read this paper?
• What are the problems, the baselines, alternatives, and the limits of them?
• What are the observations to address the problems, and how do you use them? If people start to read the introduction, they are at least interested in the topic and want to know if it is good or not. Thus, we need to say, “you should read this long long paper because we are addressing the important and actual problems.” The easiest way to say this is to use the history of the problems. First, start with the advantage of using a baseline. Then, describe the problems of the current baseline. Second, explain how the state-of-the-art alternatives address the problem, elaborating on their limitation. Lastly, say that we have a novel observation to address such problems, briefly summarizing the proposed approaches. I would call this method positioning. Position your work among the state-of-the-art alternatives and say, “they have not touched this!” You can take another approach to sell your paper, such as presenting your innovative idea to attract the readers or arguing there is an unveiled problem in the system that nobody has addressed yet. Whatever way you take, the point is that you should provide _the reason for reading your paper _to readers.

Have you ever seen a paper that starts with the intuitive and insightful figure in the introduction? Isn’t it helpful? The clear and concise Figure 1 can be a good way to deliver the history. Figure 1 should display the limits of the baseline and alternatives and the remaining opportunities that we can address. Abstracting the model and providing a simple example can be a good way to draw a nice Figure 1.

Background

• Why do we need to look into the baseline?
• What do I need to know to understand the problem? The background section is the place to provide the necessary information to understand the problems, baselines, alternatives, and our proposal. In other words, you do not need to put every detail of the baseline and alternatives into the background section. Actually, having a long background section would be misleading or cause the readers to waste their concentration. Hence, it should provide compact information.

Motivation

• Do you have evidence supporting that the problems are actual ones?
• Okay, I understand the problems. So, what should we do? In this section, you should provide evidence that the problems of the baseline and alternatives are real by providing references, mathematical proofs, and experimental results. Now you can see that you just need to explain your As-Is here. Also, if you think the challenges in To-Be are important contributions to the paper, you can introduce them briefly. Below is a good example of starting the motivation part.

To motivate STR, this section estimates the performance improvements that may be possible if execution time is scaled proportionally with the length of the numerical representation. In more detail, this section shows: 1) most of the execution time in DNNs is taken by convolutional layers, which are the layers that STR targets, 2) the numerical precision needed varies across layers and networks, 3) significant performance potential exists if execution time could scale with precision, and 4) having execution time depend on precision enables further performance improvements provided that a loss in accuracy is acceptable. Section VI describes the experimental methodology.

• From [Stripes: Bit-serial deep neural network computing]

Proposal

• Is it easy to implement the proposed ideas in the baseline?
• What are the challenges and design space of the proposed approaches? This is the To-Be part. You should provide instructions on how to implement the proposed functionalities in the baseline. Divide the functionalities or challenges into subsections and provide the solutions. The key point is that the solutions should be logically correct. If your solution is complicated, you could provide a simple example to help the readers understand it.

Evaluation

• How good are the proposed approaches compared to the baseline and alternatives?
• How does your proposal work in different design spaces? Display your evaluation results in order of significance. At the beginning, you have set your objective, so that should be the most important result. Show them how much you have achieved the objective. Next, show the comparison between ours, baseline, and alternatives. Summarize the results and provide elaborations on the outliers or unexpected results. You should cover the design spaces in this section. If you have a lot of design space, you can provide a table to summarize the results.

Related work

• Do you know these papers?
• Okay, have you referenced my papers? Tell them we know a bunch of related works, but we are focusing on different problems from them, or they are orthogonal with our proposal. The key point is to justify that we do not need to compare our performance with them. Also, show your respect for the related works or reviewers’ works 😟.

Conclusion

Simple. Just summarize the paper again with the words that you have used in the paper.

Paragraph Structure

Even if you include all the contents that should be in the paper, it is not easy to promote them with clear and concise writing. The good news is that technical writing has a fixed structure in each paragraph. Keep in mind Fact-to-conclusion. Fact is the observation or statement that you and the reader can agree on. That should be clear and interesting. Think about the point that the reader wonders about or wants to see at this point. The conclusion is the point that you want to make. That should be clear and concise. Thus, when you write a paragraph, you should start with the facts and conclusion. Then, you should write the transition between them. The transition should be concrete and logical. It could be helpful to think of the PREP method, connecting the facts and conclusions with reasons and examples (I would say FREC). If you have a figure, it is better to include it in the transition. The following is an example of the paragraph structure with the fact-to-conclusion.

The linear combinations can be detected by tracking the four types of variables in the instruction stream. In Figure 3, the computation result of the instruction at PC 0x030 is by in a linear combination of built-in indices. The by value is stored in the register %r1. If GPUs know how %r1 is represented with the linear combination, they can compute the result of the instruction at 0x040 as 16xby. Thus, the output of the instruction at 0x0a0 can be represented by 16*(P1+1)*by+(P1+1)*ty+tx+P1, which corresponds to the value of the index in Figure 2. With this observation, we argue that it is possible to detect linear combinations by analyzing instructions and exploiting their computation patterns.

Technical Writing/Figures and Graphs

Here is a basic guide for technical writing.

Here is a basic principle for good figures and graphs.

Review and Response

First, you should understand who your reviewers are (Visit this article.)

When you receive the reviews, you should respond to them in two forms: rebuttal and revision. Before writing the rebuttal and revision, you should read the reviews carefully and understand the reviewers’ concerns. Then, organize the concerns into two categories: common and individual concerns. The common concerns are the ones that more than a single reviewer mentions. This is the most important part of the response. Obviously, you should address the common concerns in this response period and the next submission. The individual reviews are the concerns that only one reviewer mentions. Basically, you should address all the concerns to avoid making the reviewers piss off. However, revisiting such concerns would be helpful since many reviewers do not have enough time to understand the paper well. If you think that the concern is not reasonable, you should not reflect it in your next submission. One more thing is that you would better focus on the reviewers who want to reject the paper.

Actually, what you should do in the response is simple: add data (DATA), elaborate on the points more (ELABORATE), and clarify the contents (CLARIFY). As you can see, DATA has the highest priority. If your reviewer asks for any data, you should add it. This will bring you the highest chance of being accepted. ELABORATE is the second priority. If your reviewer asks for any explanation that does not appear in the paper, you should add it. One more tip is that adding this in the introduction is better since reviewers are too lazy to read your 10-page paper again. CLARIFY is the last thing. Simple. Just add and highlight a few sentences to make the reviewer understand the contents.

If you need to write a cover letter or a rebuttal, include what you have done and where the modifications are. This will help the reviewers find the changes and why you have done that.

Presentation

I think everyone can make a good presentation if they prepare it well. Prepare, prepare, prepare, practice, practice, and practice. Here are a few tips that I learned:

• Outline on the first slide. This will help the audience set expectations about the presentation and guide them through it.
• Focus on As-Is. It is difficult to explain the whole contents of the paper in a short time. So, focus on the main problems and remain the rest for the audience to read your paper. The purpose of the talk is to promote your paper.
• Give some time to consume the information. Do not rush to the next slide. Stay on the slide for 30 to 60 seconds.
• Less text but more images. Presentation is not a paper. Think that you are making a guideline for the audiences who want to read your paper.
• Simple and easy examples. The best way to explain your paper is to give examples that the audience can easily understand. This is associated with the previous point.
• Punchlines for each slide. Put a punchline at the bottom of each slide. This will help the audience to understand the main point of the slide.
• We need a midterm test, not only the final test. You should summarize each chapter to ensure the audience understands the topic.
• Remember that you have a limited amount of time. Practice your presentation to ensure that you can fit everything in. I focus on conference presentations, but I think these tips are also applicable to other types of presentations.

Collaboration

Good collaboration is invaluable. You can learn a lot. You can publish your work faster. You can write a better paper. The most, it is fun. However, it would be best to understand that a good collaboration is always done in a win-win situation. Following is the list of the win-win situations that you can make.

• Senior-Junior: I think this is the best case for collaboration. From a senior’s perspective, you can write a paper with less work and expand your publication list. From a junior’s perspective, you can learn a lot from the senior directly and write a paper with a deeper understanding.
• Lab-lab: You can learn about other cultures and know-how. You can also expand your network. However, you should be careful about first authorship and also corresponding authorship. If you want to do this, you would better maximize the advantage of the collaboration. This is the most difficult collaboration.
• Senior-Senior: You can make papers faster, which is beneficial because you can discuss ideas intensively with the other seniors. However, who the first author is and how we participate in the paper should be carefully considered.
• Junior-Junior: Simple, you can do it together. However, you should be aware that this collaboration does not always produce a good result. I prefer to see further by standing on the shoulders of Giants. Keep in mind your role in the collaboration. For example, if you are a senior in senior-junior collaboration, you have a responsibility to teach everything you know to the junior.

Moreover, in collaboration, your attitude is important. We should keep in mind that we are discussing to find what is right or wrong, not who is. The following are a few tips for effective discussion.

1. Use the PREP method as well, but start with “Yes, and.”
2. Focus on the problem, not the people. Use what and how questions, not who and why. What can I do? What should I do? How can I make it happen?
3. If you do not know, say, “I do not know.” Be professional.
4. You need evidence (data or references) to convince someone. 
5. Discussion is not about who is right or wrong. The point is how we find the truth. “What evidence could change your mind?” is a better question than just “I don’t think so.”
6. Do not ask anything you would not do yourself.
7. Show your respect. Clarify that you understand what the other says.
8. Smile and have fun, which will make your work at least not boring.

Meeting

The purpose of meetings is to make a consensus within the team. We should check that we are moving in the same direction in the common direction. To achieve this, you should provide your past, present, and future. Past can be described by what you have planned in the last meeting. What are you supposed to do? Then, for the present status, you should explain two things: what you have accomplished and what trouble you are facing. For the troubles, you should provide the exact point of what makes it difficult and how difficult it is to solve. Maybe someone can provide a brilliant idea. So, provide them with a clear viewpoint on what they should look into. Last but not least, you should provide a plan telling them what you will do and provide at the next meeting.

• Previous plan: What was your plan in the last meeting?
• Accomplishment: What have you accomplished since the last meeting?
• Facing Issues: What is the trouble that you are delving into?
• Plan: What is the plan until the next meeting?

Coding Interview

You must have a job interview if you are in the job market. For a research talk, the interviewers will ask about your research based on the CV. Thus, all you need to do is prepare the research summary. However, for a technical interview, there are some rules and tips that you need to know [1] [2] [3]. The point is to show your thought process and collaborative attitude while solving the problem. Thus, do not be silent. Ask questions and help your interviewer. The important thing is to show that you want to know what the interviewer wants.

1. Repeat: Repeat the questions and clarify the requirements. Ask for data type, space/time limit, and boundary conditions. Ask again and again.
2. Example: Start from the examples and explain the workflow with it. If there is not, make your own example and explain the flow using it.
3. Approach: Start with a brute-force solution, think of a simpler version or example of the problem, and use some pseudo code or visualization. Use the breath-first-coding technique.
4. Code: Write down your code. The syntax does not matter. What is really essential is that you should be able to explain the code line by line.
5. Test: Test your code with some examples again, and ask if there is any optimal solution or edge cases. If there is, do it again from the first step. Lastly, manage your time efficiently; we only have 20 min per question.

If you get stuck in a coding interview, you can do the following: first, reiterate your thought process from the beginning to the point where you are stuck. This might help you to organize the question and come up with an idea to solve the question. If you still don’t know about that, you can gently ask for some hints. For example, “So, none of them are feasible since these reasons, am I making sense?”

The best practice is to do mock interviews, solving the LeetCode problems. However, if you do not have time, here are ten concepts that you should know before the interview:

1. Meaning of logarithm in O function
2. Graph traversal: data structure and visited one DFS and BFS
3. Binary search tree
4. Sliding window techniques: count majority, population, sum
5. Recursion function
6. Inverting the binary tree and reversing the linked list
7. Suffix Tree in string problem
8. Binary, many, max heaps
9. Dynamic programming
10. Quick and merge sort

Expectations for Ph.D. Student

1st year: Fundamentals

• You should be able to understand papers. 2nd year: Direction

• You should be able to write down your research interests and directions. 3rd year: Submit the first paper

• You should submit your first paper. 4th year: Publish the first paper, and prepare the second paper

• You should publish your first paper. 5th and 6th years: Do yourself

• You should prepare your next step after graduation.

Useful Services

• GitHub: Code version management tool. You should know how to use it for collaboration and version control. It is essential not only for Ph.D. but also for your future career. Additionally, you should check collaboration techniques, such as GitFlow workflow, which can be useful for developing collaboration skills as a team leader.
• GitHub Copilot: AI programming assistant. It is a new tool that can help you to write code or even paper (because it is trained with LaTex files also)! It is based on large-language models and auto-completes your code or text. It is a paid service, but it is worth to use.
• ChatGPT / Gemini: Writing and search assistance. It is also a large-language-model-based service that helps you write a paper or search for basic concepts. It is free to use, but I think it is worth it to subscribe to the premium version. In addition, you can use it as a wonderful tool for studying English and summarizing papers.
• Grammarly: Grammar checker. It is a paid service, but it is worth to use. You should check your grammar before submitting every piece of writing you write.
• ConnectedPapters: Related works search tool. It is a service that can make relationship graphs with academic papers. When I search papers with topics, I usually use Google Scholar first, then ConnectedPapters to find related works.
• Notion: All-in-one workspace app. If you need to organize your time spent, paper summaries, or TODOs, and you want to organize them in a single service, this service can be the best choice. Here is a tutorial.
• Speechify: Text-to-speech tool. It is a paid service, but I think it is worth using. You can listen to papers or textbooks at various speeds and voices. It is useful for measuring and enhancing your reading skills.
• Headway: Book summary service. You might wonder how I can read all the books that I provide in this blog. I haven’t read all of them. I use this service to get a summary of the books. I think the important thing in self-development is using and testing that knowledge in your life, not just reading books. So, if you like to develop yourself, this service can be useful.

Motto

Last but not least, I would like to introduce my motto:

💡 Festina Lente (by Gaius Julius Caesar Augustus)

Do not walk or rush. Jog. If so, you will see your shining achievement when you look back.