The whole truth about Google Summer of Code - part 1
Part 2
Part 3
Part 4
I think the topic is not new and everyone knows that over the summer a student can earn $ 5000. The Internet is full of stories about "how I dragged cool in the summer," but very few people talk about the wrong side of this event.
At first glance, everything is simple - submit a proposal and get a scholarship. But if everything was so simple, there were not so few Russian students. And they are really small. Having once rummaged in statistics, I found out that from my city I was generally the only student who ever participated in GSoC (for that year, now there are more of us now). And this is very bad, because I know a lot of people who are smarter than me and for some reason they did not participate or did not pass the selection.
')
1. How does it all start?
Somewhere in the middle of winter, Google makes the world happy with its decision to spend the summer of coding. Because the event has been held for more than a year, then the organizations are already at the ready. In February, the first stirrings on the topic “well, we should think up what we want us to do” begin in the mailings. In early March, organizations must already submit applications, i.e. There is already a draft list of ideas in the mailings. In mid-March, Google publishes a list of organizations. From this point you need to actively move.
Sheets with ideas are already appearing on community sites and you should start exploring them as soon as possible. There is very little time. Approximately, you have a week to choose from the organizations and projects for which you will apply. Then you should start working on the prozobalum.
Proposal (proposal) - the application for participation. Includes your profile and a detailed description of the project that you are going to code. You can submit several such applications, but you will work only one at a time.
Sign up, then subscribe to the mailing list for candidate students.
2. Who can?
All undergraduate and graduate students in any year of study, even in the last.
3. How to choose an organization?
The list of organizations will show key programmer skills. Usually in this graph programming languages. Consider that if an organization writes C ++, then you should know C ++ well and you should have at least some development experience in this language. There is such a special category of students who perceives these requirements as what they will learn in the course of the project. Nobody will teach you anything, this is a job, not an internship with a nanny.
Often, students run to popular organizations such as gnome, kde, apache, gimp, google, etc. It is clear that there are interesting projects there, but there will be a lot of those interested. Besides, the big question is - what prevented you from doing something for this community not within the framework of the summer of coding?
To weed out the people, organizations very often introduce additional rules. For example, the rule of one or two patches, or one year of contributing (i.e. you have been involved in development for a year). So, before clinging to the project you like, carefully read the additional rules, maybe your application will not even be considered.
What else do you need to know?
Also, your organization may have a bunch of other rules. For example, requirements for coding style or report forms. Usually such additional information is listed on the site. Carefully study it, and then suddenly some of the points contrary to your religion.
It would be nice to see the statistics of the organization’s participation over the past year - what projects were there, whether they ended successfully, whether the code was included in the release.
Selected, subscribe to the mailing list. Subscribed - fumble in the archive and read previous letters. Perhaps there will be information on your project.
4. Choose a project.
The most difficult thing is to choose a project. Even if you really like the topic and you just tremble at the thought of coding this project - you have to evaluate all the pros and cons very soberly. For some reason, none of the students think that in the summer the Mid-term evaluations deadline may not pass and fly out of the project.
All projects are divided into two types - research and routine. You must understand that if the organization itself is not engaged in the development of something, then for good reason.
1. Too difficult - you need to read a lot and study this issue.
2. Too boring - rewriting a module, encoding on a dock, or other routine and uninteresting work.
3. Too incomprehensible - the organization knows what should be on the way out, but how exactly to implement it does not know. no one from the team has the appropriate knowledge.
If you read the Russian newsletter and the list of accepted projects, then it seems that our students are gigantic. Almost all Russian-speaking programmers choose research projects directly related to their dissertations or diplomas. Just rewriting a piece of code is usually not comme il faut. My opinion is that the easiest way to fly out of these projects is because at the initial stage of development there is still no exact idea of ​​the complexity of implementation. It’s one thing when you’ve done something like this, and another when you’re just going. If you have a choice between a boring implementation of something simple and research, choose a routine. You do not have experience and you still do not know how to plan, and with research you can dig for a longer period than the summer lasts.
Never for anything.
Once, in one year, there was an organization that offered students to implement very complex research projects. The level of research is a Ph.D., and not a domestic one. According to my estimates, decent research (not even implementation) takes half a year. And the implementation of such a project may take a year. For whom such tasks were designed, for me a riddle. Perhaps it was a “blank” for its students who have already conducted research and started developing. Perhaps someone was hoping to get cheap someone else's work. In general - unrealistic projects you should avoid in any case.
5. We write propozal.
After selecting a project, you should write a propozal. Officially, you should post your suggestions in early April. Not officially - by this date the organization already has a draft list of accepted students.
Proposals are written in the period of communication with mentors, i.e. you write, communicate and append. During this period, the mentors get to know you and decide whether you can work with or not. But you can not communicate - from the first time, post the perfect propozal and answer a couple of small questions in the comments (this is a joke, if that).
Propozal - your implementation plan, you can say TK (who has reached the senior courses - knows what it is). When GSoC only spun, the organizers demanded that students write proof of the need for the project. It looked very funny - the organizers put out ideas, and then you argued to them that they definitely wanted to implement them. Now, there is no such thing (only if you yourself propose an idea, and it’s also possible) and the students write point by point how they will still code. An organization can also include its own questions in proposal, for example, ask to write a brief about yourself, your development experience, links to your projects, etc.
General description.
First you write about what you have to do, i.e. entrance and exit. And you must understand exactly what you are implementing and what result you guarantee by the end of August. Describe the problem and how to solve it. You can add links to articles or other resources that you will use when working.
Technical description.
General technical description. Those. "I implement such and such a function in such a module." In this part you have to show that you have understood the source well, were able to compile and run everything. It would be nice to create a brunch and make a couple of commits.
Timeline
You must divide your project into subtasks and write out when and what you will code. A very important point to proposal. If it seems to you that you code the entire project in 2 weeks, then you will have time to implement it in 3 months. If it seems to you that you have time in the butt - you will not have time at all. Your optimism is your worst enemy. If reading this text, you think that you’ll certainly drag it away, and at night you are fine, and you can not sleep for 48 hours - go drink some water and take a few deep breaths, it can release. It is better to lay down a smaller amount of work in the plan, and then please your mentor with an additional code than skip the deadline. Write your plan is pessimistic - if you have a plug, you will not fly out, and if everything goes well, no one will accuse you of additional work.
The most important point is your first deadline. Those. The first date by which you promise to provide a piece of working code. Usually the beginning of June. If you have a routine project - add yourself a week, if research - add two. There is nothing worse than missing the first deadline. Let it be better that you have extra time and you will do more than promised, than you will start to fall behind from the very first days. In addition, at the initial stage of development, the project is always slower moving, the closer to the end, when you are already in the subject.
The most productive development time is two weeks before the midterm and three weeks after. Then you will get used to the code and you will understand the task well. Try to plan your time so that the bulk of the work falls on this time.
Plan your vacation. Rest is necessary for you, and there is nothing illegal here - you are entitled to a vacation. Plan your vacation for midterm time or after - so you can relax and you will not fall out of the project.
Do not split the project into too small subtasks - so you will not leave room for maneuver. It so happens that some subtasks have to be transferred to a later date, some to an earlier one.
Leave yourself a week after each major test task. Testing is your airbag in case you fail to do something. In addition, it is often impossible to plan in advance the entire scope of work, and so you will have extra time for force majeure.
Do not leave anything important for August. In mid-August, pencils down. So the week before this date is the final test. If you are still asked to write documentation or make any final changes, then it will take another week.
6. Quantity and quality.
Once upon a time, Google recommended students post a few proposals. At the time, this recommendation was relevant because the bulk of the students rushed to the known community, and very few applications were submitted to the unknown. But now the situation has changed - there are more students willing to participate, and people really appreciated their chances to go to gcc or to gnome.
I think it is better to choose 2 or 3 communities and start working with propozalami. If in some community work goes better than in others, then you need to throw all your strength on this proposal. There will be time - you can do the second. More, I think it will be difficult, because Without working with source code, good propozal will not make up.
7. Estimated period.
After you post your proposal, the mentors begin to evaluate it, even if the evaluation period has not yet begun. After posting, you should start a discussion about your project in the mailing list - make your message available to everyone and post a link to the mailing list. In some organizations, mentors talk to students via the newsletter or IRC, and not in the comments to propozalu. They have a democracy there, i.e. Everyone should give their own assessment, and not just the mentor of your project. If there are many projects, then a lot of time is needed for discussion. That is why proposals posted on the very last day have almost no chance of success.
When the evaluation period begins, the mentors already know who they will take. You may still be asked questions about the technical implementation, but only to make sure that you deserve a positive review. So, if you see a question not from your mentor in kamenta - do not be surprised and do not fool. If interested, then they will vote for you.
Collisions.
If the same student passes through two projects, then his fate is decided in the second week of the evaluation period. It seems that you should set the priority of projects, but I don’t know how exactly this mechanism works now. Previously, everything was decided through the chat. Those. Mentors contacted the main and reserve students and everything was decided online.
There were still cases when a student who was in two organizations did not end up with any of them. So if you have 2 good tips, it’s better to tell the developers right away that in the event of a collision you want them.
Google bugs.
I don’t know why, but almost every year Google delights students with sending out preliminary results. Not everyone gets on the newsletter, and no one knows why this happens. Somehow (like even more than once, in 2011 exactly this was) the students were sent not only preliminary results, but also assessments of mentors - “garbage”, “complete garbage”, “it is better not to watch”. I was lucky to get into the newsletter only once. 4 days before the announcement of the results, a letter without text came up with the topic congratulations. In 9 out of 10 these results can be trusted, but not in cases of collisions. So one mentor was very indignant about the congratulations of the student when he was still in conflict.
8. How are we chosen?
There are a lot of tips on the internet: what to do to be chosen. In my experience and that of my friends, I can say that there are no such rules. Each organization acts on the basis of its own experience, their beliefs, preferences, the current situation with propozalami, etc.
The first advice that you are given is to communicate directly with the mentor. My opinion is not very good and not democratic. By the way, the idea of ​​democracy runs in a thick red line through the whole GSoC. Not all mentors like private discussion. First, they have a democracy and the decision about your admission must be approved by the rest. Secondly, other students may also be interested in this project and the mentor is easier to answer in the mailing list, rather than privately. For the same reason, it’s not very good to discuss a project in IRC. Thirdly, not in all organizations a mentor is appointed immediately. Happens, you learn precisely with whom you work only after announcement of results.
Communication in the IRC. Yes, they love IRC, because this is the best way to get to know you better. But there are several drawbacks - the time difference, the language barrier and the current employment. All the same, the mailing is better, because Any member of the community can join the conversation at any time. But if the organization wants and the mentor insists, there will be a lot of chat. You can say this is a good sign - they are ready to spend a lot of time on you, which means they will most likely take it.
Dirty khaki.
No, of course, you can take some actions that greatly increase your chances of success, but there is only one way - to go on increasing.
More patches. You are asked to make a couple of patches, so make 3 or 4. So you stand out among other candidates.
Early application. As a rule, applications (good applications) submitted earlier have a better chance of success. But there is another aspect - other students. If a student looks through the list of ideas and finds that several applications have already been submitted for this project, then he may refuse it, even if he is well suited for this development. Your task is to submit your application as early as possible, to make its public and throw it into the newsletter. So you "mark" the territory and start a discussion with the mentors. Then you can rewrite the proposal, add more details - in general, do everything to show the community that you can work with you, and other students, that the place is taken.
Project ID. Add a piece of your project's working code to your message. And do it quickly, so that the rest of the students will not apply for your project and you would not be compared with anyone. Yes, even if served. They will promise that the whole of May will read the docks and deal with the source code, and you have already read everything and partially encoded it. So you go around the patch rule and provide a sample code.
Increase the complexity. If you are able to write a piece of project code as a patch, then you can promise to do more than they want from you. A small expansion of the idea will be very profitable to look at against the background of other applications. Sometimes the community indicates in advance in the description of the idea several levels of complexity, i.e. You can make the feature “a”, but also the feature “b”, and if you make another “c”, it will be absolutely cool. So they are trying to get a student who will do as much as possible for Google money.
Unconditioned project. Sometimes in large organizations (well, in small ones too, but less often) there are projects that affect some section of Computer Science. If this is not artificial intelligence in the game and not a search, then there will be few people willing to search for anything or no one at all. In short, a tasty morsel for a Russian student. It will not be a pity for a large organization to give you a slot - for the sake of diversity, but you will do your research project.
Portfolio. Candidates who can provide links to the code of their own project in the repository, look more profitable than others. Sometimes this requirement is mandatory, since Mentors want to look at an example of your code. So, if you have your own small project, then it's time to comb it and put it in the repository.
9. Volunteering.
Sometimes the organization offers volunteering, i.e. all the same, only without a scholarship. If your project was not accepted (there were not enough slots, or you posted your message very late, or some other reason) and you have the opportunity to become a volunteer - agree. — ; — , , , . — .
Part 3
Part 4
I think the topic is not new and everyone knows that over the summer a student can earn $ 5000. The Internet is full of stories about "how I dragged cool in the summer," but very few people talk about the wrong side of this event.
At first glance, everything is simple - submit a proposal and get a scholarship. But if everything was so simple, there were not so few Russian students. And they are really small. Having once rummaged in statistics, I found out that from my city I was generally the only student who ever participated in GSoC (for that year, now there are more of us now). And this is very bad, because I know a lot of people who are smarter than me and for some reason they did not participate or did not pass the selection.
')
1. How does it all start?
Somewhere in the middle of winter, Google makes the world happy with its decision to spend the summer of coding. Because the event has been held for more than a year, then the organizations are already at the ready. In February, the first stirrings on the topic “well, we should think up what we want us to do” begin in the mailings. In early March, organizations must already submit applications, i.e. There is already a draft list of ideas in the mailings. In mid-March, Google publishes a list of organizations. From this point you need to actively move.
Sheets with ideas are already appearing on community sites and you should start exploring them as soon as possible. There is very little time. Approximately, you have a week to choose from the organizations and projects for which you will apply. Then you should start working on the prozobalum.
Proposal (proposal) - the application for participation. Includes your profile and a detailed description of the project that you are going to code. You can submit several such applications, but you will work only one at a time.
Sign up, then subscribe to the mailing list for candidate students.
2. Who can?
All undergraduate and graduate students in any year of study, even in the last.
3. How to choose an organization?
The list of organizations will show key programmer skills. Usually in this graph programming languages. Consider that if an organization writes C ++, then you should know C ++ well and you should have at least some development experience in this language. There is such a special category of students who perceives these requirements as what they will learn in the course of the project. Nobody will teach you anything, this is a job, not an internship with a nanny.
Often, students run to popular organizations such as gnome, kde, apache, gimp, google, etc. It is clear that there are interesting projects there, but there will be a lot of those interested. Besides, the big question is - what prevented you from doing something for this community not within the framework of the summer of coding?
To weed out the people, organizations very often introduce additional rules. For example, the rule of one or two patches, or one year of contributing (i.e. you have been involved in development for a year). So, before clinging to the project you like, carefully read the additional rules, maybe your application will not even be considered.
What else do you need to know?
Also, your organization may have a bunch of other rules. For example, requirements for coding style or report forms. Usually such additional information is listed on the site. Carefully study it, and then suddenly some of the points contrary to your religion.
It would be nice to see the statistics of the organization’s participation over the past year - what projects were there, whether they ended successfully, whether the code was included in the release.
Selected, subscribe to the mailing list. Subscribed - fumble in the archive and read previous letters. Perhaps there will be information on your project.
4. Choose a project.
The most difficult thing is to choose a project. Even if you really like the topic and you just tremble at the thought of coding this project - you have to evaluate all the pros and cons very soberly. For some reason, none of the students think that in the summer the Mid-term evaluations deadline may not pass and fly out of the project.
All projects are divided into two types - research and routine. You must understand that if the organization itself is not engaged in the development of something, then for good reason.
1. Too difficult - you need to read a lot and study this issue.
2. Too boring - rewriting a module, encoding on a dock, or other routine and uninteresting work.
3. Too incomprehensible - the organization knows what should be on the way out, but how exactly to implement it does not know. no one from the team has the appropriate knowledge.
If you read the Russian newsletter and the list of accepted projects, then it seems that our students are gigantic. Almost all Russian-speaking programmers choose research projects directly related to their dissertations or diplomas. Just rewriting a piece of code is usually not comme il faut. My opinion is that the easiest way to fly out of these projects is because at the initial stage of development there is still no exact idea of ​​the complexity of implementation. It’s one thing when you’ve done something like this, and another when you’re just going. If you have a choice between a boring implementation of something simple and research, choose a routine. You do not have experience and you still do not know how to plan, and with research you can dig for a longer period than the summer lasts.
Never for anything.
Once, in one year, there was an organization that offered students to implement very complex research projects. The level of research is a Ph.D., and not a domestic one. According to my estimates, decent research (not even implementation) takes half a year. And the implementation of such a project may take a year. For whom such tasks were designed, for me a riddle. Perhaps it was a “blank” for its students who have already conducted research and started developing. Perhaps someone was hoping to get cheap someone else's work. In general - unrealistic projects you should avoid in any case.
5. We write propozal.
After selecting a project, you should write a propozal. Officially, you should post your suggestions in early April. Not officially - by this date the organization already has a draft list of accepted students.
Proposals are written in the period of communication with mentors, i.e. you write, communicate and append. During this period, the mentors get to know you and decide whether you can work with or not. But you can not communicate - from the first time, post the perfect propozal and answer a couple of small questions in the comments (this is a joke, if that).
Propozal - your implementation plan, you can say TK (who has reached the senior courses - knows what it is). When GSoC only spun, the organizers demanded that students write proof of the need for the project. It looked very funny - the organizers put out ideas, and then you argued to them that they definitely wanted to implement them. Now, there is no such thing (only if you yourself propose an idea, and it’s also possible) and the students write point by point how they will still code. An organization can also include its own questions in proposal, for example, ask to write a brief about yourself, your development experience, links to your projects, etc.
General description.
First you write about what you have to do, i.e. entrance and exit. And you must understand exactly what you are implementing and what result you guarantee by the end of August. Describe the problem and how to solve it. You can add links to articles or other resources that you will use when working.
Technical description.
General technical description. Those. "I implement such and such a function in such a module." In this part you have to show that you have understood the source well, were able to compile and run everything. It would be nice to create a brunch and make a couple of commits.
Timeline
You must divide your project into subtasks and write out when and what you will code. A very important point to proposal. If it seems to you that you code the entire project in 2 weeks, then you will have time to implement it in 3 months. If it seems to you that you have time in the butt - you will not have time at all. Your optimism is your worst enemy. If reading this text, you think that you’ll certainly drag it away, and at night you are fine, and you can not sleep for 48 hours - go drink some water and take a few deep breaths, it can release. It is better to lay down a smaller amount of work in the plan, and then please your mentor with an additional code than skip the deadline. Write your plan is pessimistic - if you have a plug, you will not fly out, and if everything goes well, no one will accuse you of additional work.
The most important point is your first deadline. Those. The first date by which you promise to provide a piece of working code. Usually the beginning of June. If you have a routine project - add yourself a week, if research - add two. There is nothing worse than missing the first deadline. Let it be better that you have extra time and you will do more than promised, than you will start to fall behind from the very first days. In addition, at the initial stage of development, the project is always slower moving, the closer to the end, when you are already in the subject.
The most productive development time is two weeks before the midterm and three weeks after. Then you will get used to the code and you will understand the task well. Try to plan your time so that the bulk of the work falls on this time.
Plan your vacation. Rest is necessary for you, and there is nothing illegal here - you are entitled to a vacation. Plan your vacation for midterm time or after - so you can relax and you will not fall out of the project.
Do not split the project into too small subtasks - so you will not leave room for maneuver. It so happens that some subtasks have to be transferred to a later date, some to an earlier one.
Leave yourself a week after each major test task. Testing is your airbag in case you fail to do something. In addition, it is often impossible to plan in advance the entire scope of work, and so you will have extra time for force majeure.
Do not leave anything important for August. In mid-August, pencils down. So the week before this date is the final test. If you are still asked to write documentation or make any final changes, then it will take another week.
6. Quantity and quality.
Once upon a time, Google recommended students post a few proposals. At the time, this recommendation was relevant because the bulk of the students rushed to the known community, and very few applications were submitted to the unknown. But now the situation has changed - there are more students willing to participate, and people really appreciated their chances to go to gcc or to gnome.
I think it is better to choose 2 or 3 communities and start working with propozalami. If in some community work goes better than in others, then you need to throw all your strength on this proposal. There will be time - you can do the second. More, I think it will be difficult, because Without working with source code, good propozal will not make up.
7. Estimated period.
After you post your proposal, the mentors begin to evaluate it, even if the evaluation period has not yet begun. After posting, you should start a discussion about your project in the mailing list - make your message available to everyone and post a link to the mailing list. In some organizations, mentors talk to students via the newsletter or IRC, and not in the comments to propozalu. They have a democracy there, i.e. Everyone should give their own assessment, and not just the mentor of your project. If there are many projects, then a lot of time is needed for discussion. That is why proposals posted on the very last day have almost no chance of success.
When the evaluation period begins, the mentors already know who they will take. You may still be asked questions about the technical implementation, but only to make sure that you deserve a positive review. So, if you see a question not from your mentor in kamenta - do not be surprised and do not fool. If interested, then they will vote for you.
Collisions.
If the same student passes through two projects, then his fate is decided in the second week of the evaluation period. It seems that you should set the priority of projects, but I don’t know how exactly this mechanism works now. Previously, everything was decided through the chat. Those. Mentors contacted the main and reserve students and everything was decided online.
There were still cases when a student who was in two organizations did not end up with any of them. So if you have 2 good tips, it’s better to tell the developers right away that in the event of a collision you want them.
Google bugs.
I don’t know why, but almost every year Google delights students with sending out preliminary results. Not everyone gets on the newsletter, and no one knows why this happens. Somehow (like even more than once, in 2011 exactly this was) the students were sent not only preliminary results, but also assessments of mentors - “garbage”, “complete garbage”, “it is better not to watch”. I was lucky to get into the newsletter only once. 4 days before the announcement of the results, a letter without text came up with the topic congratulations. In 9 out of 10 these results can be trusted, but not in cases of collisions. So one mentor was very indignant about the congratulations of the student when he was still in conflict.
8. How are we chosen?
There are a lot of tips on the internet: what to do to be chosen. In my experience and that of my friends, I can say that there are no such rules. Each organization acts on the basis of its own experience, their beliefs, preferences, the current situation with propozalami, etc.
The first advice that you are given is to communicate directly with the mentor. My opinion is not very good and not democratic. By the way, the idea of ​​democracy runs in a thick red line through the whole GSoC. Not all mentors like private discussion. First, they have a democracy and the decision about your admission must be approved by the rest. Secondly, other students may also be interested in this project and the mentor is easier to answer in the mailing list, rather than privately. For the same reason, it’s not very good to discuss a project in IRC. Thirdly, not in all organizations a mentor is appointed immediately. Happens, you learn precisely with whom you work only after announcement of results.
Communication in the IRC. Yes, they love IRC, because this is the best way to get to know you better. But there are several drawbacks - the time difference, the language barrier and the current employment. All the same, the mailing is better, because Any member of the community can join the conversation at any time. But if the organization wants and the mentor insists, there will be a lot of chat. You can say this is a good sign - they are ready to spend a lot of time on you, which means they will most likely take it.
Dirty khaki.
No, of course, you can take some actions that greatly increase your chances of success, but there is only one way - to go on increasing.
More patches. You are asked to make a couple of patches, so make 3 or 4. So you stand out among other candidates.
Early application. As a rule, applications (good applications) submitted earlier have a better chance of success. But there is another aspect - other students. If a student looks through the list of ideas and finds that several applications have already been submitted for this project, then he may refuse it, even if he is well suited for this development. Your task is to submit your application as early as possible, to make its public and throw it into the newsletter. So you "mark" the territory and start a discussion with the mentors. Then you can rewrite the proposal, add more details - in general, do everything to show the community that you can work with you, and other students, that the place is taken.
Project ID. Add a piece of your project's working code to your message. And do it quickly, so that the rest of the students will not apply for your project and you would not be compared with anyone. Yes, even if served. They will promise that the whole of May will read the docks and deal with the source code, and you have already read everything and partially encoded it. So you go around the patch rule and provide a sample code.
Increase the complexity. If you are able to write a piece of project code as a patch, then you can promise to do more than they want from you. A small expansion of the idea will be very profitable to look at against the background of other applications. Sometimes the community indicates in advance in the description of the idea several levels of complexity, i.e. You can make the feature “a”, but also the feature “b”, and if you make another “c”, it will be absolutely cool. So they are trying to get a student who will do as much as possible for Google money.
Unconditioned project. Sometimes in large organizations (well, in small ones too, but less often) there are projects that affect some section of Computer Science. If this is not artificial intelligence in the game and not a search, then there will be few people willing to search for anything or no one at all. In short, a tasty morsel for a Russian student. It will not be a pity for a large organization to give you a slot - for the sake of diversity, but you will do your research project.
Portfolio. Candidates who can provide links to the code of their own project in the repository, look more profitable than others. Sometimes this requirement is mandatory, since Mentors want to look at an example of your code. So, if you have your own small project, then it's time to comb it and put it in the repository.
9. Volunteering.
Sometimes the organization offers volunteering, i.e. all the same, only without a scholarship. If your project was not accepted (there were not enough slots, or you posted your message very late, or some other reason) and you have the opportunity to become a volunteer - agree. — ; — , , , . — .
Source: https://habr.com/ru/post/149789/
All Articles