150 karma · joined November 4, 2014
While I haven't donated labor on a project for a charity or non-profit, I wouldn't be opposed if the right project came my way when I had the availability.
Out of curiosity, when you say the assignment was completely irrelevant to the role, was the assignment more related to something else at the company?
The point was to encourage our fellow HN member to be open minded and try it for a short period of time. From there he can determine if the change has begun to yield any value or not.
1st Interview:
Lunch interview with my boss. Conversation was casual, covering my background & goals, the leadership's background, and the tech stack. After lunch we expanded a little on our conversation with a showcase of certain features of the company's product.
2nd Interview:
Met with the company's founder for about an hour, followed by individual meetings with a few engineers. During the meeting with the founder we exchanged some background information and I was shown some info on the company's performance thus far; this was huge personally as transparency had become a huge pain point with my previous employer. The engineering meetings went smooth; I'd consider them casual but the technical discussion was more in-depth than the 1st interview.
Code test:
After the 1st Interview I was given a take-home code test; building a simple card game using the MEAN stack (shuffle deck, deal cards, score game based on card's position relative to a brand new deck, store results & calculate ongoing average). It took me about 12 hours over the course of a week (evenings mostly - I was employed during this interview) to complete. Since our product has no relation to card games, IMO the code test sought to prove that:
1. I was capable of taking a spec to code completion
2. I was capable of working within the confines of the company's tech stack (MEAN)
It took my boss less than a day to review my submission before offering me a position on his team.
Aside from my best interview experience, I've had some not-so-great experiences, here's a few that I encourage avoiding:
- No call, no show. Be mindful of your schedule and if you can't keep the commitment, inform the candidate. Candidates hate wasting their time, especially if they're still employed since it usually means taking time off.
- Impromptu skill evaluations. If you tell a candidate that the 1st round interview is going to be non-technical, then they're going to prepare accordingly. Shotgun questioning is not well received.
- Surprises on code tests. If your code test is going to measure one's ability to work within your stack, make sure the technologies come up during the interview conversations prior to issuing the code test.
- starts as a pull request (we use git-flow strategy)
- Pull request is announced in our team slack channel via integration
- 2 devs must sign off before merge; 3 if branch is from our outsourced team in India.
- Github project wiki contains an outline of the type of criteria to keep an eye out for, mostly syntax & patterns not caught by our linter config
- All feedback is considered optional
- Devs are encouraged to take conversations offline if a comment thread takes off on a particular item
- Team leader handles the merge after devs signoff on PR
2. If you think a company is doing their hiring wrong, do you really want to work for them?
2. Even if your landlord does detect, what's he going to do? Kick you out? Probably not. He'll simply tell you that you can't unplug the system for insert reason here. Worst case, he'll charge you the cost of labor to fix what you've disabled.
2. I'll apologize for being so blunt, but the bullet points for your work experience suck. They're dry and could use additional context. Your work experience needs to tell a story of what you were doing so you come off as intriguing. What sounds better, "Designed graphics, maintained WordPress for company website" or "Developed & implemented new version of company website using Twitter Bootstrap."
3. Your more recent job title: get rid of the "what the job really was" in parenthesis. Call it what it was, and elaborate that you took the lead role when you reach the point of having a conversation.
4. Clark Strategic Partners Job - Strip the job title down to "Web Developer". You're not freelance if you're specifically defining them as an employer under your work experience, and naming whom it was for is redundant. If it was truly a freelance job, then rework that section with the focus of you working for yourself as a freelance dev and talk about what you did for CSP in the bullet points.
5. The last job on your resume, the advisor one: Move that to the top if it's still you're still presently in the role. Work Experience always goes what you're currently doing first, followed by what you've done recently.
6. Simplify your technical skills section. For you, this section should be nothing more than a comma separated list of technology keywords. Don't separate by experience levels - only put the ones on there you're confident enough behind to take a job/internship doing.
7. Your resume is too long, either trim content or tweak page margins/fonts/etc to get the resume to fit perfectly on a single page. You don't have enough overflow to justify having a second page.
On the flip side of things, I think developer is a better buzzword.
Word of advice: Double check that you're not infringing on any patents.