4 ms·

> Your interviewer is only open to solving the problem ONE way Haha, I've happily been in the "interviewer" side of this two times: One time, as part of a Dev

> Your interviewer is only open to solving the problem ONE way Haha, I've happily been in the "interviewer" side of this two times: One time, as part of a DevOps interview I asked the candidate to run something in a POSIX OS every 15 seconds using a cronjob (that was the general idea). Crontab granularity is only in minutes, so you have to use your head or Google to get a Cronjob answer. The interviewee however told me about the 1 minute granularity of CronJob, and offered instead to create a small service on init.d. with a while/sleep 15. I loved his response :-) The other was someone who, while solving a binary search problem without a ceiling integer value, used the fact that his language of choice C++ has an INT_MAX macro defined to set the limit of the search... TOUCHE. As an interviewer I personally love when these sort of things happen because it shown the interviewee is really thinking about the problem.

user5994461 6y ago
That's the first thing I thought reading your sentence, cron cannot do seconds granularity (I think the lowest was 1 hour on the last OS I was working with). Why would you ask questions which you know are impossible? That's setting up the candidate to fail.
- twinkletwinkle_ 6y ago
  It's not "impossible", just not natively obvious. The solution I remember using is 0 * * * * foo() 0 * * * * sleep 30; foo() It's not the prettiest but is a reasonable imitation of a 30 second cron.
  - xtracto 6y ago
    You got it! the main idea is for it to be a "solve the problem" thing with certain framework. I've got guys that just google it, others that do a script and sleep within the script, and the guy that suggested the while. All of them are "right" answers for me... I don't really care about how they do it, but the process perform while doing it. Fact is, during the life of a DevOps, they will need to solve things that they don't know how to, so they'll need to be able to at least Google-fu themselves out of the problem.
user5994461 6y ago
For reference, that init.d solution is extremely dangerous, speaking from experience ;) init scripts are run sequentially, each init scripts MUST terminate quickly AND leave no child process, otherwise the init sequence is frozen. If there is a while() loop in an init script, it will freeze the init sequence. If an init script starts another program without daemonizing, it will freeze the init sequence. High chances are that you missed either or both of that in the solution. The init script will work fine while you test locally in the shell but it will blow up startup on the next reboot.
boring_twenties 6y ago
INT_MAX is from C and so not the best answer in C++, the ideal candidate would use std::numeric_limits<int>::max(), or choose C instead of C++ in the first place :)

user5994461 6y ago

That's the first thing I thought reading your sentence, cron cannot do seconds granularity (I think the lowest was 1 hour on the last OS I was working with). Why would you ask questions which you know are impossible? That's setting up the candidate to fail.

twinkletwinkle_ 6y ago
It's not "impossible", just not natively obvious. The solution I remember using is 0 * * * * foo() 0 * * * * sleep 30; foo() It's not the prettiest but is a reasonable imitation of a 30 second cron.
- xtracto 6y ago
  You got it! the main idea is for it to be a "solve the problem" thing with certain framework. I've got guys that just google it, others that do a script and sleep within the script, and the guy that suggested the while. All of them are "right" answers for me... I don't really care about how they do it, but the process perform while doing it. Fact is, during the life of a DevOps, they will need to solve things that they don't know how to, so they'll need to be able to at least Google-fu themselves out of the problem.

user5994461 6y ago

For reference, that init.d solution is extremely dangerous, speaking from experience ;) init scripts are run sequentially, each init scripts MUST terminate quickly AND leave no child process, otherwise the init sequence is frozen. If there is a while() loop in an init script, it will freeze the init sequence. If an init script starts another program without daemonizing, it will freeze the init sequence. High chances are that you missed either or both of that in the solution. The init script will work fine while you test locally in the shell but it will blow up startup on the next reboot.

boring_twenties 6y ago

INT_MAX is from C and so not the best answer in C++, the ideal candidate would use std::numeric_limits<int>::max(), or choose C instead of C++ in the first place :)