We’re hiring a few backend developers, frontend developers, as well as data scientists (interns). The internship will start in January, last 4 months, and take place at our Markham, ON, Canada Software Lab location.

You must be enrolled in a Co-Op program at your university/college and be eligible to work in Canada to be considered for this position.

IBM internship positions

To apply, please use the following links:

• Backend Developer Intern
• Frontend Developer Intern
• Data Scientist Intern

You can apply for more than one position if you wish.

What to expect from our interview

Interviews are scary, amirite? Lucky for you, I perform the technical interview. I don’t ask brain teasers (i.e., how many useless interview questions are currently being asked in New York City?) or algorithmic questions.

I also do not ask you to solve anything on a virtual whiteboard, code anything on the fly, or expect you to remember specific details you can easily Google while performing your job.

Instead, we’ll have a technical conversation about your previous projects, and I will ask you more general questions that tend to reveal with greater accuracy your current understanding of software engineering (or data science).

For example, if you list REST APIs on your resume, I might ask you what’s the difference between 400s and 500s errors. I’m not going to ask you what a 413 error represents.

The most promising candidates will proceed to a second interview with me and my manager.

This second web interview has little to no technical questions and it’s just an opportunity to learn more about you and your ambitions, and for you to learn more about our team and ask questions.

At that point, we’ll decide who to hire. That’s it. No gruesome six rounds of interviews. Easy peasy.

This easy-going interviewing method has enabled us to hire great candidates with virtually no false positives.

What we value

It’s worth noting that we value cultural contribution over cultural fit. We don’t need clones of our existing team members, as excellent as they are. We need people who add something to the team and bring fresh new perspectives.

Also, don’t doubt yourself. If you are interested, apply. We value passion and attitude over raw experience. A bad hire is not someone who doesn’t know much but is willing to learn. A bad hire is someone who knows everything but can’t work in a team.

If you apply, feel free to email me your resume as well so that I can speed up the interview process.

Our interns tend to love the experience in the team and will often come back for another internship or as regular employees once they graduate.

Talk to you soon.

The post New IBM Internship Positions in My Team appeared first on Programming Zen.

I was reminded of it by Joel Spolsky’s announcement of HyperDev:

Notice what you DIDN’T do. You didn’t make an account. You didn’t use Git. Or any version control, really. You didn’t deal with name servers. […]

It’s effective marketing, but I like the approach far beyond its value in press releases or demos.

It’s the right mindset. We should ask ourselves, what kind of burden can I remove from my users? It might be a trivial obstacle, but can I somehow remove it? Automate it?

In my experience, asking the question is enough to shift the perception of what’s possible. Often we accept the status quo without questioning it, until we see someone else do it, only to realize that the old way was unnecessary.

What can I change that will allow me to say to my users, “Notice what you didn’t do”?

Whether it’s a tool for fellow developers, an API, or a program for end users, asking this kind of question will undoubtedly lead to better experiences and fewer artificial barriers to overcome.

The post Notice What You Didn’t Do appeared first on Programming Zen.

I’m deliberately using the generic word people instead of the more common users. In many cases the decision will indeed affect end-users, because designing a good user experience (UX) is fundamental to the production of quality software; however my point is to try to consider all the people who may be affected by a given decision.

For example, a choice you make might affect fellow developers in your team, testers, the person that will eventually write the manual for your software, co-founders who’ll have to present the project to prospective investors, or even the sales person that demos and sells the product.

Putting people first each step of the way, or taking a People Driven Development approach if you will, is in my experience a great way to ensure the quality of your product.

As developers it’s easy to be so bogged down in implementation details that the focus on what really matter is lost. What matters is people.

The post People Driven Development appeared first on Programming Zen.