For years philosophers and religious icons have tried to tackle the great question, “What’s the meaning of life?” At the 2012 Silicon Valley Code Camp, I asked the incredibly geeky developers, “What’s the meaning of code?” Burn some incense and watch their answers.
There are three different types of dashboard design: strategic, tactical, and operational. As you move from strategic, to tactical, to operations, the level of detail in the dashboard goes up. Each serves a different purpose and a different audience, explained Lee Lukehart, Chief Data Visualist for SavvyData in his presentation “The Art of Dashboard Design” at the 2012 Silicon Valley Code Camp conference at Foothill College in Los Altos, California.
Lukehart outlined the purpose of the three types of dashboards.
Strategic dashboard: Designed for executives to monitor ongoing trends on a year-over-year basis. It’s often graphical. It’s not designed for real-time monitoring. For a dashboard to be strategic it needs a main metric you’re trying to meet, so that you can see if execution aligns with strategy.
Tactical dashboard: Built for managers to manage. Manage performance against preset target. It should be a tool to use for analysis and link results to actions. Plus the dashboard should help the manager discover problems and opportunities.
Operational dashboard: This is for the on-the-ground workers. It is where you see precise measurements in performance and other details. Information is often delivered in real time.
Avoid communications problems with effective data visualization
If not done right, dashboards can be confusing, boring, inaccurate, and worthless. Here’s how to avoid falling into that dashboard trap:
- Know when not to use a certain visualization: Pie charts are abused. They’re not efficient. In many cases, just presenting a number will be more efficient. A table or list is often more preferable.
- Know your data: Source the scope. Make sure your data is clean and complete. Avoid GIGO (garbage in garbage out).
- Consider your audience: Understand their needs, objectives, and their familiarity with the communications tools. What is their level of knowledge and experience?
- Determine the chart’s message or focus: Your dashboard is telling a story. Is it a ranking, a timeline, a category, proportion of whole, variance/deviation, distribution, correlation, or geospatial?
- Select best chart type for the message
- Construct data transforms as needed: Derive new data to tell the real story – aggregate, segment, factor, augment, find, and organize.
- Conduct pre-flight checklist: Make sure you’ve taken the following into account before you release your dashboard to the world. Consider human factors, data issues, scaling, labeling, chart type choice, visual formatting, creating an über chart, and chart titling.
Human factors in visual perception
Before you let a dashboard out the door, think about how it will be perceived. Is your dashboard creating skewed results or results certain people can’t understand?
For example, take into consideration normal human optical perception issues, such as color blindness. If you’re going to be using the color red and green to show negative and positive results, also add other indicators like maybe a plus or minus sign, or an arrow going up or down. Also, take advantage of tools within Photoshop that shows how your dashboard will look to a color blind person.
Don’t intentionally or accidentally lie with your charts. One way to misinterpret values is to not show the zero level. All charts should show the zero level so you can see appropriate relations.
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.
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.
“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.”
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:
- Dan Arkind (@danarkind), JobScore
- Aki Taha (@akitaha), Persona
- Jeff Winner, Cardspring
- Moderated by Pete Soderling (@petesoder), g33ktalk
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.
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.
If you’re a web developer, you’re already a Windows 8 developer, said Jeremy Foster, Developer Evangelist on Windows 8 for Microsoft.
“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.
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:
- You solve a problem.
- You get your name out in a very open and public place.
- You give something back. The next person won’t have the same awful experience you had.
Why do you participate in open source projects?
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.