Month: May 2019

Questions to Ask During a Software Developer Interview

During an interview you should not only try to sell yourself as the best candidate for the job. You should also make sure that the company is somewhere you want to work. Listed below are some questions to ask during your job interview so that you can make sure working at the company is going to be an enjoyable experience that allows you to grow.

What project methodology does the company use?

Does the team you’d be in use waterfall, scrum, kanban, or some other methodology? Knowing what methodology the team uses will let you know what you can expect from a planning side. You should also have follow up questions that are aimed at finding out how well they follow the methodology. The interviewer may say they follow scrum, but additional questions can help you figure out if they actually follow scrum, or just say they do. Some follow up questions could be:

  • How successful have you found the methodology to be?
  • What are problems you’ve faced or are currently facing with the methodology?
  • If they follow scrum, the do they have a scrum master?
  • How long is each sprint?
  • Do they track metrics, like velocity, capacity, or burndown? How do they use those metrics for planning for the future?

Does the company use Devops?

Having a CICD/devops pipeline set up allows for teams to work faster and produce higher quality code. The company’s use of devops can give you an idea of what the company values the most (speed, quality, long-term planning, automation).

You should ask for details to get an idea of how far along they are with devops. The company may have a build server who’s only function is to build the code, or the company may have an pipeline set up that takes the code a developer commits, runs tests against it, pushes it out to multiple environments, versions it, and/or makes the package ready for end-user consumption. If the interview says they have devops set up and they only have the former but you are expecting the latter, then you’ll be very disappointed when you start the job. Here are some more detailed questions you can ask.

  • What kind of build server do you use? Jenkins, TeamCity, Bamboo, Azure Devops?
  • Have the interviewer walk you through the pipeline. How does a commit from a developer make it to the end-user?
  • What can still be automated?
  • How has the pipeline helped your team?
  • Do developers maintain the pipeline or do you have a separate Devops team?
  • Do you use an artifact repository?

How is the code kept clean?

If the code isn’t clean, it’s hard to work with. No developer wants to work with spaghetti code. To that end, you should find out how they keep their code clean.

  • Are unit tests required? What about integration tests?
  • Is code coverage tracked?
  • Do they follow good coding principles, like SRP and DRY?
  • Do they use design patterns?
  • Do they have code reviews? What stops low-quality code from making it into the main branch?

How is developer input used for planning?

As a developer, you want to know how much influence you have on the planning process. Ask how deadlines are set. For example, if a client wants some feature, will your boss ask you and the other developers how long you think it will take? Or will he just set an arbitrary deadline? You should find out what factors are used to plan a feature’s deadline and priority.

How are efforts that don’t directly benefit the customer planned? If you and your team really want to start setting up a CICD pipeline, or refactor a part of the code, or write more automated tests, how is time for those efforts planned?

Questions like these don’t only let you know how your input influences planning. They can also give you some insight into how much your opinion in general matters. Will your boss listen to you if you explain the benefits of automation and testing? Will he listen when you explain how a feature is more complicated than he thinks? Your boss should not only listen to you, but also take action.

How do developers stay up-to-date?

The company you work for should help you continue to grow and learn as a developer. Not only you, but your coworkers should be open to continually learning. A coworker who is set in his ways and refuses to learn new technologies can be very difficult to deal with. You should ask how the company facilitates growth as a developer.

  • Will the company send you to conferences and/or workshops if you ask?
  • What websites or books does the interviewer and/or coworkers already working there recommend? They should be able to name a few.
  • How are new technologies and processes viewed in the company? Ask for specific examples.

What’s the career path for a developer?

Ask the interviewer what a developer’s advancement opportunities are. If you want to code for your whole career, but the company only offers advancement into management, then you may want to look elsewhere.

  • Do they have senior developer or architecture roles? What are the specific requirements for these roles?
  • If you want to advance into management, what are your options. If you want to stay technical, what are your options?

What’s the company’s view on work-life balance?

You should ask how many hours someone in the position you’re applying for works a week. Some companies expect their developers to work way more than 40 hours a week on average. Even if you’ll normally be working only 40 hours a week, crunch times happen. How often do they happen and how many hours does someone in your position work when they happen?

Are you free to work on hobby projects?

If you have hobby projects, such as an app, library, blog, or invention, then you’ll want to make sure that while you work at that company you maintain ownership over them. Some companies will have you sign an agreement that says anything you produce the company owns, even if it’s outside of working hours and doesn’t use any company resources.

Conclusion

The point of all these questions is to find out what your day-to-day experience will be like working at the company. You want to make sure you’ll be happy and respected while working there. Asking these questions can also demonstrate that you’ll be a valuable asset to the company.

3D Printed Wheel Hub Drive – Part 2

Part 1 is here.

In this article I’ll talk about some improvements I made to the wheel hub drive from the last article and some other designs I have tried since then.

The planetary gear I was using used 5 planets. You can see in Figure 1 that the planets are so close together that they actually touch each other. This was causing extra friction so I tried 4 planets instead, shown in Figure 2. This seemed to work better.

Figure 1: Helical planetary gear with 5 planets
Figure 2: Helical planetary gear with 4 planets and sleeve bearings

In Figure 2 you can also see that I inserted sleeve bearings. I hoped that the sleeve bearings would help decrease the friction caused by the planets spinning around the bolts that attach them to the Y carriage.

I ended up redoing the rear motor mount, shown in Figure 3. Also shown are the 3D printed bearings I used that go around the motor.

Figure 3: New rear motor attachment

To test the assembly’s strength I tied a rope around it and attached the other end to the ball transfer skateboards I made, as shown in Figure 4.

Figure 4: High load test

I stepped on the skateboard and turned the motor on to see if it could pull me (I weigh about 160 pounds). The results were disappointing. It was not able to pull me when I stood on the skateboard with the 3D printed ball transfers. It was able to pull me when I stood on the skateboard that had 5 ball transfers I bought from McMaster, but it took a lot of current to do so (I believe around 30 amps).

The planetary gear seemed to not be causing much friction once I went down to 4 planets and put the sleeve bearings in. I thought that maybe the bolts that go through the planets were being pulled to one side when under a heavy load, causing the planets to tilt a little. But after taking a video of the planets under load it looked like they were not being tilted.

I believe the problem is mainly with the 3D printed bearings shown in Figure 3 and discussed in part 1. I don’t think they can handle the load I’m trying to put them under. Since there is only one ring of BBs, and the motor and hub spin at different rates, the BBs probably do more sliding than rolling, causing friction. I may have to redesign the bearings to have 2 rings of BBs, one for spinning with the motor and one for spinning with the hub. The plastic parts may also flex under high load, causing more friction.

Other Motor Drive Designs

I created a few more designs that I hoped would be able to handle heavy loads. These designs focused on minimizing friction. The first is shown in Figure 5.

Figure 5: Small wheel design

This design drives a smaller wheel. I wanted to see if the motor could provide the torque needed to rotate the large gear I slid around it. I cut out the wood pieces on my CNC. The wheel was printed out of TPU and attached to the gear via 1/8″ steel rods, as shown in Figure 6 and 7. The tire tread was copied from here.

Figure 6: Wheel, gear, and 1/8″ steel rods unassembled

Figure 7: Wheel, gear, and 1/8″ steel rods assembled

I performed the same kind of load test as before, shown in Figure 8.

Figure 8: Small wheel motor drive being set up for testing

Disappointingly, the this motor drive was not able to pull me either, even when I used the skateboard that used the ball transfers I bought from McMaster.

The last design I tried is shown in Figure 9.

Figure 9: Gear train motor drive

This design used a simple gear train to get a gearing ratio of 4:1 between the motor and the longboard wheel. The wheel was attached to the gear using 1/8″ steel rods like the last design, as shown in Figures 10 and 11.

Figure 10: Wheel, gear, 1/8″ steel rods, and other parts unassembled

Figure 11: Wheel and gear assembled using 1/8″ steel rods

This design was tested like the others, as shown in Figure 12.

Figure 12: Testing the gear train design

This design actually worked! It was able to pull me when I put all my weight on both of the skateboards shown in Figure 12. The current it took to pull me is shown in Figures 13 and 14.

Figure 13: Current draw when the gear train design pulled my weight while I stood on the skateboard using my 3D printed ball transfers

Figure 13: Current draw when the gear train design pulled my weight while I stood on the skateboard using the ball transfers I bought from McMaster

You can see that the ball transfers from McMaster used less current. It takes more force to start pulling a load from a dead stop than to keep it going, so I believe that’s why the current is highest in the beginning (and the startup boost may be too high).

Conclusion

I’m going to move forward with the gear train design. I’ll improve the design in several ways. For example, I’ll try to redesign it so that the middle gear is supported on both sides and I’ll probably make the gears thicker.