[shayanjm]

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/

+ 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.

[solomatov]

>+ 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/

But why everybody should use this kind of branching model? Branches have their overhead, namely time spent merging after several days of work.

[hamburglar]

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.

[jhildings]

>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]

>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]

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.

[solomatov]

I completely agree with you.

[atmosx]

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

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]

>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]

Yes, I will try to create some sort of startup for sure in the next few years.

[pnathan]

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]

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?

[pnathan]

So if you're burping out a singular product with a singular release, rolling off master tends to make more sense. The complexity comes in when you're running multiple features and multiple products and multiple teams and having to do long running support of the older products/projects/teams all together.

Simpler is better; but when your actual code path of support looks like a network, that's the complexity you have to eat - I recommend eating it in your branching system (correspondingly, your versioned artifacts get some really funny version identifiers too. :) ).

[eldavido]

I've never encountered this but agree, that can lead to a real hell of branching. Do you dead-end your releases and then backport certain things from your mainline to previous release branches?

Sounds like a headache but probably the best way in certain domains.

[pnathan]

Yeah, each release might be, e.g, firmware version x.y.z.patchlevel, and then you backport fixes and release on patchlevel.

Some customers demand the absolute minimum amount of change - their interface is essentially fixed, all they want is fixes, no more improvements.

Besides firmware, I think this also get applicable when doing larger whitelabel software, each major customer might want to have a particular version they are focused on using.

[shayanjm]

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]

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.

[eldavido]

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

[shayanjm]

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.