Let Your Thoughts Speak in a Technical Interview

Posted on November 19th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=J_4KEasVSIw&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Have you frozen during a technical interview? Have you been stumped by a question during a technical interview? You’re not alone. In fact, you’re everyone that’s been through a technical interview.

“No one has ever gotten every question correct,” said David McCarter, who led a presentation at the 2012 Silicon Valley Code Camp entitled, “Surviving the Technical Interview.”

McCarter advises that you come prepared for an interview. It sounds obvious, but he’s amazed at the number of interviewees that don’t research the company, the job, or study technical questions.

While you can’t know everything, you still need to practice and there are tons of technical questions online to get your chops up. The purpose of the technical interview is to see where you fit into the company’s skill sets, said McCarter.

Vocalize your thoughts

“Know what you don’t know, and admit it,” said McCarter.

Being upfront about where your knowledge exists and doesn’t exist is something the interviewer looks for. So be truthful. Even when you don’t know the answer, you can still show your process in how you’d go about solving the problem, or explain that you’ve been reading up on the topic even though you haven’t done it yourself.

Don’t be stumped by silly logical questions. They aren’t meant to be answered correctly. They’re designed to see how you go about problem solving, said McCarter.

McCarter quoted a question from Microsoft that asks, “Why are manhole covers round?” The point of the question is not to get a correct answer, but rather to hear how you think. So don’t internalize your thoughts when asked such a question. Be expressive.

McCarter recognizes that developers sometimes have a hard time expressing their thoughts. If that’s your normal behavior, put it aside for the interview and think out loud.



.NET User Group Participation Critical for .NET Success

Posted on November 19th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=ZLYEiyN_YHc&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

“It’s sometimes lonely in front of the computer,” admitted Mathias Brandewinder, lead for the San Francisco chapter of Bay .NET, a Bay Area user group for .NET developers. We spoke at the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.

Brandewinder joined the group and eventually ran a chapter of Bay .NET because he wanted to be on the forefront of .NET’s cutting edge technologies, and he also wanted to meet other fellow developers. The Bay Area, said Brandewinder, is admittedly not the most Microsoft-friendly area and finding other local .NET developers is really important. Plus, having the weekly education (Bay .NET meets four times a month) is critical because the .NET framework is huge and it’s changing very fast. To maintain his .NET chops, it’s important for Brandewinder to keep up with what’s important and not important.

Brandewinder ended up a .NET developer accidentally seven years ago. As a kid he wanted to be an architect. Software development filled that desire to create, but at a higher level at an even more experimental level, said Brandewinder, who hasn’t had a problem finding work ever since he became a .NET developer.

“I think [software development] is one of the most human people-engaging jobs around,” said Brandewinder. “I love talking with people who are expressing what they do, and you have to understand what they do and give them a great solution. It’s a very exciting problem.”

Recruiting Hacks for Engineers

Posted on November 16th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=nOy-uGPVVok&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Whether you’re a recruiter or not, we will at one time eventually have to hire someone. To learn more how engineers can help with the recruiting process, I attended a panel discussion entitled “Recruiting Hacks for Engineers” at the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California.

On the panel were:

Here are some highlights of the hacks, tips, and issues that came up in the conversation:

  • Hiring managers and team managers recruit people. Recruiters just facilitate that process.
  • A huge percentage of your working hours are going to be the people you’re working with so you should invest in who you work with. It will play into your happiness.
  • If you want to start a company you need to show you can build a quality team to execute on the vision you have. Ideally you’ll have a history, but if you don’t you at least have to demonstrate an approach.
  • If you want to be part of the culture of your organization, you have to be involved in recruiting.
  • If you want to move into management, you have to show you know how to build a team.
  • Recruiting is about putting people around you that you can learn from.
  • You must make your company look attractive to other engineers. The goal is to attract them to you rather than having to compel them to come to you.
  • If you have a product then your customers can be your employees. For example, if you have an API, you’re marketing to engineers to use the API, and then you can recruit from those engineer customers.
  • A lot of engineering recruiting is about where you’re going, not where you are. You need a story that people are going to buy into as to where you’re going to go in the future.
  • Bait them with a cool project. When exciting projects come up, use them as bait to attract new talent. Don’t give this to existing people. But that can become an issue to keep great talent. That’s the VP of engineering’s problem. Don’t bait and switch. You must deliver.
  • It’s very difficult if not impossible to get engineers to give you referrals. Pose the referral request this way. Say that you have a particular project with this particular publisher. Do you have someone who would want to work on this?
  • Ask your team members, “When you talk to your friends about us, what aspect do they get excited about?” If they’re having a hard time telling the company story, help them craft that story to tell their friends.
  • Any good person your employees know, even if they just took another job, is a good referral.
  • If you have a lot of trust, you can go through their contacts with them. But you have to be wary from being ID’ed as a slimy recruiter guy.
  • All the best people you know and your colleagues know need to know your company’s story. When they become available, you want your company to be on their shortlist. That’s referral hiring.
  • Instead of saying, can you refer a hire, say I’m looking for a person I can talk to about this problem. That connection is referral hiring. It can be a far more effective way to approach the problem.
  • Most people ask the question, “What do you do?” Make sure your staff is comfortable with your stories. Situations pop up when you’re out and about.
  • Recruiting takes a long time. There is no way to do recruiting that requires no effort. It requires effort and diligence.
  • Half of the process of recruiting is that person is dying to work at your company. Engineers are trying to determine whether you’re a good enough coder to do the job.
  • Pair coding in the interview process takes a lot of work. Sessions can be as long as three hours. That’s more important than all the other coding and technical questions. Ask if they have a github project. Then come over and work on their project with them. You learn a lot when you do pair coding. You learn what the potential hire is like to work with. You can see how they respond when they get frustrated. You can see their thought process and how they interact when they’re working.
  • Beware of assessing an outside engineer about your knowledge. Figure out something that levels the playing field, rather than your specific knowledge. Don’t interview engineers to see if they know what you know. You’ll fail. That’s not an effective way to recruit people. You want to see if they know what they know really well. Will they be able to contribute and add value to your environment?
  • The reason people get stressed out in an interview is they don’t know what’s going to happen. Instead, tell them what you’re going to do, so you get a relaxed person to assess.
  • If you don’t get enthusiasm back on your vision, that’s a complete rejection. And if you do hire that person, the team will reject that person.
  • What questions would you ask if you wanted a hard worker? What would you ask yourself?
  • The way you recruit someone nobody knows is very different than recruiting someone that you or a team member knows well.
  • Most important thing you can do is provide detailed written feedback after an interview. If you write things down you’ll be way ahead of others.
  • Not everyone requires a long interview. Ask a series of binary (yes/no) questions to determine if they can go to the next level. If they answer no to all of them, move on. Higher speed and higher volume recruiting happens if you create a lot of knockout questions.
  • No one who is talented will fill out a job application or a form online.
  • If you find significant dishonesty on a resume, then become very wary.
  • If you’re worried about something in a given interview, make sure you write that down and communicate it to the next person who is doing the interviewing. You want any of your worries dealt with in the interview process instead of the end when you’re all discussing the problem.
  • Are you “open” to learning or do you want to learn? There’s a big difference.
  • You can’t hire an OK person. It may be ok to lose the requirement. Just don’t hire someone if you don’t think they’ll be able to accomplish the task. It’ll set you up for failure as a manager.
  • Highly favor people that have projects of their own, like their own GitHub project.

Learn Design Fundamentals and Then Break Them

Posted on November 16th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=hjtwmXITzuo&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

When you’re crafting a user interface (UI) you need to keep in mind that you’re trying to help users complete a daily task, said Uday Gajendar, Principal Product Designer for Citrix in our conversation at the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California.

There are some very basic do and don’t design fundamentals, said Gajendar. Don’t clutter up the screen with extraneous information and buttons, and do organize content through prioritization, hierarchy, color, typography, grid, and image elements that will help a user accomplish the tasks.

I asked Gajendar about a design philosophy that I’ve heard that says you should follow the rules of design and then break one rule severely. The rule should be broken so harshly that it’s obvious and the user readily sees it.

Gajendar agrees with that philosophy, but only after you understand design fundamentals. You must establish a baseline first. Once you understand, then you’ll know what rules to break.

The fundamentals of UI design is like a language, said Gajendar. You learn the grammar first, and then once you’ve mastered it you learn how to break the rules and create your own style.

Gajendar is all for breaking the rules. Just make sure you get the fundamentals right.

Web Developers are Automatically Windows 8 Developers

Posted on November 16th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=Q01tZrQ6bfU&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

If you’re a web developer, you’re already a Windows 8 developer, said Jeremy Foster, Developer Evangelist on Windows 8 for Microsoft.

All your classic web development skills, such as HTML, CSS, and Javascript that you use to make an application can be used in the Windows 8 environment. There is a native element to it as well. You still will need to interact with elements of the device, and that’s where native programming comes in, but it’s all within your web development, said Foster.

To learn more, you can head to the Windows Dev site or to Foster’s blog, codefoster, and click on the “resources” tab.

Software Architecture Must Accommodate Change

Posted on November 16th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=PsH_Nn9p1Uk&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

“The hallmark of a bad design is when the design has to change to accommodate the change in a requirement,” said Juval Löwy, President and Chief Architect of IDesign. Good architecture is built with change in mind. It encapsulates that change by creating functionality where and when you integrate with system volatility.

Löwy led sessions on architecture and process at the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.

For Löwy’s other session he explained how to orient your process to accommodate the highly modular nature of modern software systems. The act of project planning is actually an engineering task. The architecture may not allow the process to go too fast, but how can you create a plan that prevents it from slowing down, asked Löwy.

Benefits of Participating in Open Source Projects

Posted on November 16th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=QzZftDdPYI4&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Silicon Valley Code Camp is a weekend long event of 200+ sessions on anything that would be of interest to a developer. It’s also purely a volunteer event, and Ixchel Ruiz, an engineer with Griffon, loves coming to these events and participating.

Back in her homeland of Switzerland, she participates in Hacker Garden, a space where coders and developers work on open source projects and contribute back to the community.

I asked Ruiz why she likes working on open source and she said it all comes out of frustration. You work on some project and you begin complaining that it’s not working the way you expect it. Instead of complaining, Ruiz just connects with people who are having the same problem. It’s often an issue that she has to deal with every single day, so she quickly becomes very passionate about it.

For Ruiz, she sees three benefits of working on open source projects:

  1. You solve a problem.
  2. You get your name out in a very open and public place.
  3. You give something back. The next person won’t have the same awful experience you had.

Why do you participate in open source projects?

Tips to Crack the Coding Interview with Gayle Laakmann McDowell

Posted on November 12th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=BN0B4mOtwX0&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Surviving a coding interview was top of mind of the more than 2500+ developers that attended the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.

It was such a prevalent topic that Gayle Laakmann McDowell’s session, “Cracking the Coding Interview,” also the title of her book, was the most popular session at the conference. McDowell is also the author of The Google Resume, and founder of CareerCup, a website that hosts more than 8,000 interview questions for software engineers.

Be prepared to write on a whiteboard

McDowell’s first piece of advice for a coding interview is be ready to write out your code by hand. You won’t have a compiler in front of you, so practice writing and debugging on paper. She invites developers to look at the questions on her site, CareerCup.

Make sure you get all your semicolons in place as pseudo-code won’t fly, said McDowell.

Coding interview algorithms

McDowell recommends these mental tricks to help you work through questions for which you don’t readily know the answer:

Pattern matching: Think about what interview questions are similar to the one you can’t solve. Approach the solution to the problem with the version you do know.

Simplify and generalize: If the problem is too complex for you to wrap your head around, simplify it or tweak some of the constraints so you can at least solve a simplified version of the problem. Then generalize to the regular problem that you see.

Base case and build: Solve the problem for the n=0 and n=1 case and see if you can use solutions from prior problems to solve for n=2 and n=3, and then build up from there.

How to really blow a coding interview

When I was in college I admitted to really blowing a coding interview. Honestly, I just froze, mostly because I didn’t know the answer right off the top of my head. McDowell said this is one of the grand misconceptions of the coding interview. Developers think that they can just hear a problem and then belt out the right answer. That’s not how it works. The interviewer really wants to know how you think about the problem and how are you going to approach it. So be calm and don’t get flustered. Don’t expect you need to know the right answer. It can take the absolute best candidates 30 minutes or longer to work through a coding interview, said McDowell.

The Most Technology-Enabled Car Ever?

Posted on November 12th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=xjy0M6igu0E&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

Hanging out on the lawn of Foothill College at the 2012 Silicon Valley Code Camp in Los Altos, California was Project Detroit, Microsoft’s attempt to create the most technology-enabled car. With the body of a 1967 Mustang and a whole load of technology from Microsoft, this car took the guys from West Coast Customs eight weeks to build along with four members of the Microsoft Coding for Fun group. This car is not rolling off the line anywhere in Detroit, but if you can afford all that, you can afford this car. Here’s what’s inside:

  • Two laptops running all the systems in the car.
  • An XBOX360 for tailgating.
  • Rear projection screen with messages displayed on back window.
  • Three Kinect devices that allow you to see what the car sees.
  • Car PA system.
  • Controllable RGB LEDs all over as car accents. Change the color to whatever you want.
  • Digital dashboard that can change to different styles of dashboards.
  • GPS system (of course).
  • Windows 8 Slate for passenger side.
  • All different systems can be controlled or viewed from the Windows mobile phone. Control elements such as the LEDs, the custom messages on the back screen, and announcements. Plus you can view the dashboard or see video from the car.
  • The car is a cloud-enabled device. All engine information such as your speed, RPMs, etc. are pushed to the cloud so you can do data crunching later.

Five Factors that Produce High Performing Product Teams

Posted on November 9th, 2012 by David Spark

[youtube http://www.youtube.com/watch?v=SFep82v423M&wmode=window&w=605&h=350]

Here is some of my coverage of the 2012 Silicon Valley Code Camp at Foothill College in Los Altos, California where I was reporting for Dice and Dice News.

You’ve got a team, and it’s got some quirks. That may be OK if it’s got these following factors that make up a high performing product team.

The “five factors of high performing product teams” is the result of a study performed by Actuation Consulting. You can request a full copy of the study here, but above is our interview with the President of Actuation Consulting, Greg Geracie at the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.

High performing product teams need the following:

  1. High degrees of executive involvement: Instead of just having one executive in place, there is more than one executive that engages with the product team.
  2. Managing the transition from development into ongoing support and launch: If there is a single person that has accountability, there is a higher likelihood that the team will succeed.
  3. Onboarding new employees to the product team: Geracie underappreciated this at the beginning. If you don’t sink enough resources into this you’ll fail.
  4. Make sure the product team is aligned with the company’s overall goals and objectives: Fifteen percent of product teams have a portfolio plan in place and only 14 percent have multi-year strategies. Absence of these is an indicator that you’re not performing at a high level. And even those organizations that do have those plans in place, only 50 percent of their respondents say they do it effectively.
  5. Make sure you have the right people on the team: Forty two percent of respondents said they had the right people on the team. This breaks down when you look at the actual launch process because it’s typically under-resourced and it doesn’t have the appropriate parties on the team.

The biggest surprise from the study, said Geracie, was that the majority of organizations are using blended methodologies to produce their products. If you listen to industry buzz it’s agile that’s getting the marketing noise, but they found that 53 percent are actually using some combination of agile and waterfall.