5 ms·

No, I wouldn't hire you as-is. Probably not a first-choice intern either. Some notes on why not: + Your web-sume looks rough. As pointed out by others, there

No, I wouldn't hire you as-is. Probably not a first-choice intern either. Some notes on why not: + Your web-sume looks rough. As pointed out by others, there are a number of typos (i.e: "and provide an opporunity") not to mention the design itself could use work. If you are GREAT at web design/UX you should spruce it up. Otherwise, kill it and move to a traditional resume. Knowing HTML5/CSS3 today is pretty meaningless, so showcasing that is sort of pointless. + There are tons of issues with your resume itself (i.e: "Excellent verbal and written communication skills." despite multiple typos and unclear flow) which need to be addressed. Cut the fluff, point to recent projects & address why they are cool/why anyone should care. Anything that you did 10+ years ago that isn't directly applicable to what you want to do in the near future has no place on the resume. + Your bitbucket projects are lackluster. You don't follow good git branching habits, your commits are non-atomic, your code is cumbersome and unfinished in many places. You also seem to use .py files as notes in non-standard ways, introducing weird artifacts and conventions to your projects. Some notes on how to improve: + Learn how to use git productively in a team environment (this means no more working directly out of master). This is a good resource to that end: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ + Learn better coding habits in whatever language(s) you are most comfortable with. Your bitbucket only has python code, so learn how to do things in more 'pythonic' ways. (i.e: Don't just stub notes inside .py files. Throw them inside a README.md or keep them in a secondary utility so you don't clutter the repo). + Sort of back to point #1 but deserves its own category: Learn how to use .gitignore. You have tons of artifacts in your repos that do not need to be/should not be there. If you address all of the above, you'll be in a much better position to start qualifying for entry level dev openings.

eldavido 12y ago
I disagree with a lot of this. The guy is junior, this is stuff that can be taught on the job.
- shayanjm 12y ago
  Most of it is stuff he would have to unlearn before he could then learn it on the job. I would rather hire someone who has no habits than one who has bad ones.
pnathan 12y ago
Personally, I don't care about usage of git/hg. That can be dealt with on the job, and is no worse than hiring someone from another shop. As a matter of fact and recommendation, I don't think atomic commits are a great practice to follow in general anyway.
- eldavido 12y ago
  I agree. I wasn't going to turn this into a general conversation about branching, but since others are going there... I really dislike gitflow for release-to-web projects. Any form of branching creates integration debt to be paid later. Maybe it's worth it, for instance, when discussing a new feature in its own branch. But gitflow's assumption of a heavyweight "release" process just isn't an accurate reflection of how the best companies work today. For a high-frequency deployment cadence (once/day or more), the level of ceremony required to get a release out is too much. And companies really do have to release that frequently, as high-priority bugs come up, integrations with third-party systems break, etc. github-flow or the "Continuous Development Flow" as we call it, is much better-suited for high-velocity web development. I'd be interested to hear what people are using for mobile projects. Maybe gitflow makes sense there, but I don't know that a "hotfix" ever happens, I think people just fix the bug and release a new version to the world?
  - shayanjm 12y ago
    Not here to say that one style is better than another, although I've used gitflow almost exclusively for a few years and it's served well. Pushed features/hotfixes/etc. out the door in a timely manner, and never felt held back by the 'ceremony' necessary to push to prod. CI handles most of that and with the 'git flow' plugin you can easily do a two command deploy while not compromising good branching/repo maintenance practices.
    - eldavido 12y ago
      How big is your team? I work in a company of about 20 developers with approx. 30 repos (lots of small services, "small program methodology") and trying to keep all of this in sync for a single release gets pretty tough. Right now, there's a lot of ceremony to create release branches on 20+ repos. At the end of our two-week agile sprint, there's always a ton of confusion about "is the release branch open", "should I commit to develop", people opening PRs for review targeting the wrong branch (e.g. trying to merge into release/ but they open feature/ against develop), then accidentally merging release into develop and vice versa...it's just kind of a mess. Maybe it's just my team that sucks at gitflow? Or our tooling could be better? It just seems like a lot of complexity to manage for a single person who isn't a full-time build/release engineer. Also, if you don't mind me asking, how frequently do you deploy? We're at once every two weeks but I'm trying hard to move the org toward once/day or more, it's pretty insane how much organizational resistance I have to fight because deployments = "change" = scary.
atmosx 12y ago
I'm impressed by your comments. Could take the time and make a similar assessment of my github[1] account? It's highly unlikely for me to ever work as a developer but I'd like to know what you think of it, nevertheless :-) [1] https://github.com/atmosx https://github.com/atmosx ps. In case you take the time to have a look at my repo... Well thanks for your time :-) (everyone else, feel free to drop a line or two about my repo if you like)
- jorgecastillo 12y ago
  >It's highly unlikely for me to ever work as a developer Maybe someday you can work as a developer for yourself. The good thing about a software business is that it's more about business than software. If you can code a working solution to fix some problem that exists everything else is irrelevant. The really hard thing is to identify a problem that's business worthy.
  - atmosx 12y ago
    Yes, I will try to create some sort of startup for sure in the next few years.
solomatov 12y ago
>+ Learn how to use git productively in a team environment (this means no more working directly out of master). This is a good resource to that end: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ But why everybody should use this kind of branching model? Branches have their overhead, namely time spent merging after several days of work.
- hamburglar 12y ago
  Saying a person doesn't know how to use git productively based on their personal github projects is simply ridiculous. Nearly everything I put on github is experimental wankery presented as a curiosity, not a release. It has nothing whatsoever to do with my ability to use git productively. I can only conclude that anybody who would make this criticism has a strong "everyone should be just like me" value and is probably not someone I'd want to work with.
  - solomatov 12y ago
    I completely agree with you.
  - jhildings 12y ago
    >Saying a person doesn't know how to use git productively based on their personal github projects is simply ridiculous. Nearly everything I put on github is experimental wankery presented as a curiosity, not a release. And also a method for quickly sharing code or projects with friends, instead of storing them on a server that requires FTP/SSH for access. Then everyone can just browse things in an easy way
  - gr3yh47 12y ago
    >Saying a person doesn't know how to use git productively based on their personal github projects is simply ridiculous. thank you. i agree.
    - shayanjm 12y ago
      If you have your personal projects listed in your resume - you'd better make damn sure they are at least 80% polished and _SHOW OFF_ your skills. If they are not/do not, don't list them in your resume or make them private.

eldavido 12y ago

I disagree with a lot of this. The guy is junior, this is stuff that can be taught on the job.

shayanjm 12y ago
Most of it is stuff he would have to unlearn before he could then learn it on the job. I would rather hire someone who has no habits than one who has bad ones.

pnathan 12y ago

Personally, I don't care about usage of git/hg. That can be dealt with on the job, and is no worse than hiring someone from another shop. As a matter of fact and recommendation, I don't think atomic commits are a great practice to follow in general anyway.

eldavido 12y ago
I agree. I wasn't going to turn this into a general conversation about branching, but since others are going there... I really dislike gitflow for release-to-web projects. Any form of branching creates integration debt to be paid later. Maybe it's worth it, for instance, when discussing a new feature in its own branch. But gitflow's assumption of a heavyweight "release" process just isn't an accurate reflection of how the best companies work today. For a high-frequency deployment cadence (once/day or more), the level of ceremony required to get a release out is too much. And companies really do have to release that frequently, as high-priority bugs come up, integrations with third-party systems break, etc. github-flow or the "Continuous Development Flow" as we call it, is much better-suited for high-velocity web development. I'd be interested to hear what people are using for mobile projects. Maybe gitflow makes sense there, but I don't know that a "hotfix" ever happens, I think people just fix the bug and release a new version to the world?
- shayanjm 12y ago
  Not here to say that one style is better than another, although I've used gitflow almost exclusively for a few years and it's served well. Pushed features/hotfixes/etc. out the door in a timely manner, and never felt held back by the 'ceremony' necessary to push to prod. CI handles most of that and with the 'git flow' plugin you can easily do a two command deploy while not compromising good branching/repo maintenance practices.
  - eldavido 12y ago
    How big is your team? I work in a company of about 20 developers with approx. 30 repos (lots of small services, "small program methodology") and trying to keep all of this in sync for a single release gets pretty tough. Right now, there's a lot of ceremony to create release branches on 20+ repos. At the end of our two-week agile sprint, there's always a ton of confusion about "is the release branch open", "should I commit to develop", people opening PRs for review targeting the wrong branch (e.g. trying to merge into release/ but they open feature/ against develop), then accidentally merging release into develop and vice versa...it's just kind of a mess. Maybe it's just my team that sucks at gitflow? Or our tooling could be better? It just seems like a lot of complexity to manage for a single person who isn't a full-time build/release engineer. Also, if you don't mind me asking, how frequently do you deploy? We're at once every two weeks but I'm trying hard to move the org toward once/day or more, it's pretty insane how much organizational resistance I have to fight because deployments = "change" = scary.

atmosx 12y ago

I'm impressed by your comments. Could take the time and make a similar assessment of my github[1] account? It's highly unlikely for me to ever work as a developer but I'd like to know what you think of it, nevertheless :-) [1] https://github.com/atmosx https://github.com/atmosx ps. In case you take the time to have a look at my repo... Well thanks for your time :-) (everyone else, feel free to drop a line or two about my repo if you like)

jorgecastillo 12y ago
>It's highly unlikely for me to ever work as a developer Maybe someday you can work as a developer for yourself. The good thing about a software business is that it's more about business than software. If you can code a working solution to fix some problem that exists everything else is irrelevant. The really hard thing is to identify a problem that's business worthy.
- atmosx 12y ago
  Yes, I will try to create some sort of startup for sure in the next few years.

solomatov 12y ago

>+ Learn how to use git productively in a team environment (this means no more working directly out of master). This is a good resource to that end: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ But why everybody should use this kind of branching model? Branches have their overhead, namely time spent merging after several days of work.

hamburglar 12y ago
Saying a person doesn't know how to use git productively based on their personal github projects is simply ridiculous. Nearly everything I put on github is experimental wankery presented as a curiosity, not a release. It has nothing whatsoever to do with my ability to use git productively. I can only conclude that anybody who would make this criticism has a strong "everyone should be just like me" value and is probably not someone I'd want to work with.
- solomatov 12y ago
  I completely agree with you.
- jhildings 12y ago
  >Saying a person doesn't know how to use git productively based on their personal github projects is simply ridiculous. Nearly everything I put on github is experimental wankery presented as a curiosity, not a release. And also a method for quickly sharing code or projects with friends, instead of storing them on a server that requires FTP/SSH for access. Then everyone can just browse things in an easy way
- gr3yh47 12y ago
  >Saying a person doesn't know how to use git productively based on their personal github projects is simply ridiculous. thank you. i agree.
  - shayanjm 12y ago
    If you have your personal projects listed in your resume - you'd better make damn sure they are at least 80% polished and _SHOW OFF_ your skills. If they are not/do not, don't list them in your resume or make them private.